Le scénario de l’approche développée dans [MS03] consiste, pour un documentt et une requête Q, en deux étapes :
1. Analyse statique de la requêteQ qui consiste à extraire les chemins qui sont exprimés dans Q et qui permettent de déterminer la partie du document t nécessaire à son évaluation ; 2. Elagage du documentt, lors de sont chargement, en utilisant les chemins extraits de Q. 3. Evaluation de la requêteQ sur la projection t′obtenue à l’issue de l’étape 2.
L’analyse statique proposée dans [MS03] est correcte et garantit que l’évaluation de la requête Q sur le document projeté retourne le même résultat que l’évaluation sur le document original, i.e. Q(t)=Q(t′).
Le but de cette section est de présenter d’abord la technique d’extraction des chemins dévelop- pée dans [MS03]. Nous discutons des limitations de cette approche ensuite.
3.2.1 L’extraction des chemins à partir des requêtes
L’extraction des chemins pour les requêtes tient compte de la forme générale de celles-ci présen- tée dans le chapitre 2. Les requêtes sont principalement construites à partir de chemins qui assurent la navigation dans le document interrogé. Ces chemins sont utilisés pour exprimer des conditions et bien plus important encore, pour spécifier les résultats retournés par les requêtes. Afin de tenir
compte des différents rôles joués par les chemins au sein des requêtes et afin de permettre de dé- terminer avec précision les noeuds devant être gardés dans la projection, la technique d’extraction des chemins développée par [MS03] distingue deux types de chemins : les chemins returned cor- respondant aux chemins qui spécifient les résultats retournés par les requêtes et les chemins used correspondant aux autres chemins exprimés dans les requêtes et qui permettent soit la navigation, soit la construction de résultats intermédiaires. Le but de cette distinction est de permettre, lors de l’étape d’élagage, de différencier les noeuds devant être projetés seuls parce qu’utilisés seulement pour naviguer dans le document des noeuds devant être projetés avec leurs descendants parce qu’ils sont les racines des réponses aux requêtes.
Exemple 23. Considérons l’exemple de la Figure 3.1(a) pour illustrer les deux catégories de che- mins. A partir de la la requêteQ sont génèrés deux chemins used :
– self :: Solar/planet qui est utilisé pour naviguer dans les éléments – self :: Solar/planet/name/text() qui sert à exprimer une condition. et un chemin returned qui est
– self :: Solar/planet/satellite
La projection à partir de ces chemins, illustrée dans la Figure 3.1(b), montre bien que les noeuds qui sont projetés sont ceux traversés par l’un des chemins extraits deQ, c’est à dire, les noeuds étiquetésSolar, planet, name, satellite ou les noeuds descendants du chemin returned de Q qui sont les noeuds étiquetésname et note. Dans cet exemple name est à la fois utilisé et retourné par
Q.
La technique d’extraction développée dans [MS03] permet d’analyser des requêtes complexes construites par imbrication ou composition d’autres requêtes. Les aspects les plus importants de cette extraction sont présentés à l’aide de la Table 3.1. Les fonctionsUse(Γ, q) et Ret(Γ, q) per- mettent de capturer l’extraction des chemins used, returned à partir de la requête q en présence de l’environnement statique Γ. Le rôle de l’environnement statique dans l’extraction des che- mins est analogue au rôle que joue l’environnement dynamique dans l’évaluation des expressions for x in qctxtreturn qresoulet x=qctxtreturn qres(cf. Chapitre 2) et consiste à garder trace
des liaisons entre la variablex et le résultat de l’évaluation de la requête contextuelle qctxt. Dans
le cas de l’analyse statique, l’environnementΓ utilisé pour garder trace des liaisons impliquant la variablex est l’ensemble des chemins returned extraits à partir de qctxt. L’enrichissement d’un en-
vironnement statiqueΓ par une liaison entre une variable x et un ensemble de chemins P est noté Γ · x7→P.
Nous commentons le principe d’extraction de chaque requête rapportée dans la Table 3.1.
Les variables La première ligne de la Table 3.1 correspond au traitement d’une variablex en tant que chemin ou composant d’un chemin (par exemplex/P ), l’extraction utilise l’environnement statique construit jusqu’alors. Cet environnement contient normalement une liaisonx7→P pour la variable x où P est un ensemble de chemins {P1, . . . , Pn} signifiant, évidemment, que x peut
"valoir"P1, ouP2, ... ouPn.
Les chemins La deuxième ligne de la Table 3.1 correspond au cas d’une requête réduite a un chemin. Le traitement de ce cas consiste à considérer le chemin comme étant returned.
Variables Use(Γ, x) = ∅
Ret(Γ, x) = {P ∈P | x7→P ∈ Γ}
Chemins Use(Γ, P ) = ∅ Ret(Γ, P ) = {P }
Composition Use(Γ, (q1, q2)) = Use(Γ, q1) ∪ Use(Γ, q2) Ret(Γ, (q1, q2)) = Ret(Γ, q1) ∪ Ret(Γ, q2)
FLWR Use(Γ, for x in qctxtreturn qres) =
Use(Γ, qctxt) ∪ Ret(Γ, qctxt) ∪ Use(Γctxt, qres) Ret(Γ, for x in qctxtreturn qres) = Ret(Γctxt, qres)
oùΓctxt= Γ · x7→Ret(Γ, qctxt)
TABLE3.1 – Extraction des chemins à partir des requêtes [MS03].
La composition séquentielle L’extraction des chemins pour la requête q1, q2 est simple. Elle
consiste à cumuler les chemins extraits séparément à partir deq1 et deq2.
Les requêtes FLWR Nous donnons uniquement la règle de l’extraction des chemins pour l’itéra- tionfor x in qctxt return qres. Le traitement des requêtes de bindinglet x=qctxtreturn qres
et des requêtes conditionnelles if qctxtthen qres0else qres1suit le même principe.
La requête d’itération est composée d’une partie contextuelleqctxt et d’une partie résultatqres.
La partie contextuelle va générer exclusivement des chemins used puisqu’elle sert à la navigation dans le document et à l’expression de conditions avec éventuellement le calcul de résultats inter- médiaires. La requête résultat va générer des chemins used et des chemins returned pour la requête itérative et ceci de manière directe.
Exemple 24. Le but de cet exemple est d’illustrer l’extraction des chemins pour la requêteQ de la Figure 3.2. Cette requête est de la formefor x in qctxt return qres et suit donc la règle donnée
dans la Table 3.1.
L’extraction des chemins à partir de la requête contextuelleqctxts’effectue à partir de l’environne-
ment statiqueΓ=∅. Elle retourne le path self :: Solar/planet/name/text() comme used car il est dans la condition du where et le pathself :: Solar/planet comme returned.
L’extraction des chemins pour la requête résultatqress’effectue à partir de l’environnement statique Γ1 contenant la liaison x7→self :: Solar/planet parce que self :: Solar/planet est le seul path
returned deqres. Elle retourne comme chemins used
– self :: Solar/planet en raison du "let $y := $x" et de la liaison pour la variable x, et – self :: Solar/planet/diameter qui figure dans la condition where de qres.
Elle retourne le chemin returned self :: Solar/planet/satellite qui va générer le seul chemin
returned deQ.
3.2.2 Limites d’utilisation
L’approche de [MS03] est confrontée aux problèmes de l’évaluation au vol des chemins XPath étudié dans [BYFJ04, GN11, Gau09]. D’après ces travaux seul le fragment exprimant les axes avant (child et desc) peut être évalué au vol en temps linéaire en la taille du chemin et en espace linéaire en la profondeur du document interrogé. Les chemins exprimant les axes arrière (parent et
for$x in self :: Solar/planet where$x/name/text()=’Mars’ qctxt return let $y := $x where $y/diameter return $y/satellite qres
(a) La requête analyséeQ
Γ = ∅ Use(Γ,Q)
self :: Solar/planet/name/text() self :: Solar/planet
self :: Solar/planet/diameter Ret(Γ,Q) self :: Solar/planet/satellite
Γ = ∅
Use(Γ,qctxt) self :: Solar/planet/name/text()
Ret(Γ,qctxt) self :: Solar/planet
ΓC = x7→{self :: Solar/planet} Use(ΓC,qres) self :: Solar/planet
self :: Solar/planet/diameter Ret(ΓC,qres) self :: Solar/planet/satellite (b) L’extraction des paths deQ
FIGURE3.2 – Illustration du mécanisme d’extraction de chemins de [MS03]
ancs) nécessitent quant à eux le stockage en mémoire tampon d’une partie du document interrogé et ne peuvent donc pas être évalués au vol. D’autre part, d’après [Olt07] la réécriture des axes arrière en axes avant ne peut être envisagée en pratique : elle peut produire des chemins d’une taille exponentielle en la taille des chemins en entrée. L’évaluation des chemins exprimant des conditions (prédicats) nécessite elle aussi de stocker en mémoire tampon une partie du document interrogé puisqu’une condition peut contenir par exemple un chemin absolu. La technique de projection de [MS03] se limite donc à la fois aux chemins qui ne contiennent pas d’axes arrière et qui n’expriment pas de conditions.
Cette technique présente un autre inconvénient lié au traitement des chemins exprimant l’axe desc-or-self(//). L’évaluation de tels chemins nécessite d’examiner un nombre important de noeuds du document interrogé. Considérons le document de la Figure 3.1(b) l’évaluation du chemin self :: Solar//name/text(). Cette évaluation nécessite l’examen de tous les noeuds du
document alors que seuls les élémentsplanet sont pertinents puisqu’ils sont les seuls à contenir les noeudsname traversés par le chemin. Cet exemple montre le rôle que pourrait jouer l’information concernant la structure du document dans l’accélération de l’étape d’élagage. En effet, si une telle information était disponible, le cheminself :: Solar//name/text() pourrait être réécrit en self :: Solar/planet/name/text() permettant ainsi de guider la navigation dans le document t en lui indiquant qu’elle doit nécessairement passer par le noeudplanet pour aboutir au noeud name. Il serait alors possible d’éviter d’examiner des éléments qui ne contiennent pas de noeud name tels que les élémentsgalaxy, star ou comet de notre exemple.
L’autre limitation de cette technique concerne son imprécision lorsque les conditions sont utui- lisées. Cette technique ne permet pas d’analyser les conditions dans les cheminsce qui peut conduire à projeter plus de noeuds que nécessaire. L’élagage du document t de la Figure 3.1(b) en utilisant le chemin self :: Solar//node()[note]/satellite conduit à retourner tout le document puisque la condition [note] n’est pas exploitée pour restreindre les noeuds projetés à ceux dont les descen- dants possèdent un noeud filsnote.