Re: [sdx-developers] Relations entre les documents

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

> Depuis SDX 1, un document XML indexé peut avoir des documents attachés.
> Il y a une relation entre ces deux documents, relation que SDX exploite
> d'une seule façon : il détruit les documents attachés si le document XML
> est détruit.

Mmmh... d'après le code, ça va plus loin car il semble que l'on peut 
*partager* des documents attachés. On n'efface donc que quand le 
compteur de références passe à 0. J'en profite pour dire que c'est un 
excellent concept :-)

> On peut voir ces fragments comme des relations : un document <fait
> partie> d'un autre document, ou inversement un document <contient> un
> autre document. Ainsi, dans l'exemple, je pense que l'on peut dire que A
> contient B, C et D. On peut aussi dire que B contient C. Donc en plus
> d'une relation "est attaché à", on aurait une relation "fait partie de".

Tout à fait d'accord.

> Ayant deux relations possibles, on peut se poser la question : doit-on
> rendre le concept générique? C'est-à-dire permettre tout type de
> relation? On pourrait penser que je suis en faveur, puisque tout ou
> presque est générique dans SDX, mais là je suis contre... Principalement
> parce que ça cause un problème d'implantation.

Mmmh. Quel serait-il ? Il est possible que je manque de recul, mais dans 
l'état actuel des choses, l'utilisation du fameux troisième index 
pourrait selon moi être rendue possible en une cinquantaine de lignes... 
et je suis volontaire pour les rédiger !

> Je suis aussi contre parce que je n'arrive pas à y trouver un intérêt
> immédiat.

Les exemples cités ne sont-ils pas des démonstrations de cet intérêt ?

> Si le développeur veut ses propres relations, il n'a qu'à les
> définir par des champs (on le fait souvent).

C'est là où je coince. Pour l'instant, on stocke dans l'entrée de lookup 
 du document *propriétaire* (quel deviendra ce concept avec des 
documents fragmentés ?) un truc du genre :

ID_DOCUMENT_ATTACHE:1
ID_DOCUMENT_ATTACHE:2
ID_DOCUMENT_ATTACHE:3

Ca fonctionne, tant qu'on n'a qu'un seul champ. Mais si je veux, par 
exemple, stocker le repository (cf. autre thread) :

ID_DOCUMENT_ATTACHE:1
ID_DOCUMENT_ATTACHE:2
ID_DOCUMENT_ATTACHE:3
REPOSITORY_DOCUMENT_ATTACHE:A
REPOSITORY_DOCUMENT_ATTACHE:B
REPOSITORY_DOCUMENT_ATTACHE:C

comment je fais la nécessaire relation A1, B2, C3 ?

> Cette réflexion aurait même tendance à me faire dire qu'on a un
> seul type de relation, documents attachés ou fragment de documents. 

Pour les documents fragmentés, tu as un point *en plus* qui me paraît 
primordial : la relation d'ordre. Pour reprendre l'exemple précédent, 
avec un degré supplémentaire (qui n'est d'ailleurs pas ultime) de 
complexité cette fois, on a :

ID_DOCUMENT_ATTACHE:1
ID_DOCUMENT_ATTACHE:2
ID_DOCUMENT_ATTACHE:3
REPOSITORY_DOCUMENT_ATTACHE:A
REPOSITORY_DOCUMENT_ATTACHE:B
REPOSITORY_DOCUMENT_ATTACHE:C
SEQUENCE_DOCUMENT_ATTACHE:1
SEQUENCE_DOCUMENT_ATTACHE:2
SEQUENCE_DOCUMENT_ATTACHE:3

qui stocke les relations (ordonnées) : A/1, B/2, C/3.

Mais peut-être as-tu une idée sur ce point qui serait radicalement 
différente de la mienne ? Je serais très heureux de me tromper sur ce 
point : de plus, c'est la période ;-)

J'ajoute que ça crée une grosse différence entre les entrées de lookup 
des documents indexés et les entrées de lookup des autres (documents 
documents attachés et... document originaux qui, eux aussi, pourraient 
bénéficier des raltions), mais ça, c'est marginal.

A bientôt.

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden