Bonjour chers lecteurs. Ce post se concentrera sur les applications légèrement non standard d'un formalisme aussi connu que XPath. Tout le monde sait qu'il est très pratique d'extraire des informations à partir de XML ou HTML ou d'autres documents * ML (à la fois du texte brut et des documents virtuels, qui sont la couche supérieure de la représentation de toute information complexe), puis il y a afin de poser ces documents des questions. Cependant, on sait que mieux la question est formulée, plus elle contient déjà une partie de la réponse. Par conséquent, une pensée simple se suggère: est-il possible d'utiliser des expressions écrites dans XPath comme affirmant, c'est-à-dire de construire un document pour que cette expression XPath soit vraie? Je pense que c'est possible, et c'est la première chose qui sera discutée ici. Et le second - si nous apprenons à créer directement de nouveaux éléments dans un document en utilisant directement XPath, est-il possible de transformer XPath en un langage de programmation algorithmique simple? En fait, il sait accéder aux données, il sait créer des données. Il est facile d'imaginer comment décrire la séquence d'opérateurs et l'opérateur de branche sur elle, il reste à penser aux cycles qu'elle contient et aux fonctions. C'est intéressant, du moins théoriquement. Et cela sera également discuté.

Construire XPath

Ainsi, XPath ordinaire décrit une séquence d'étapes pour se déplacer dans une arborescence de documents, et une condition de filtre peut être imposée à chaque étape (un prédicat écrit entre crochets). En conséquence, nous obtenons un ensemble fini de nœuds ou un nombre ou une chaîne ou une valeur logique. Nous nous intéressons principalement au cas des nœuds multiples. XPath normal produit des nœuds qui existent déjà dans le document. Considérons une hypothétique construction XPath qui non seulement renverra des nœuds existants, mais construira également de nouveaux nœuds de manière à ce qu'ils correspondent pleinement à la requête.

L'idée est très simple - à l'étape suivante de la requête XPath, nous analyserons le prédicat de filtre et compilerons les variantes de données qui relèvent de ce filtre. Et puis nous vérifierons laquelle de ces options existe déjà et terminerons la construction de celles qui n'existent pas.

Par exemple, voici une requête:

/OBJS/Var[@A=1 and @B=1 or @A=2 or @A=3]/X 

Si nous le considérons comme une construction, nous allons tout d'abord vérifier si l'élément racine <OBJS> existe, et sinon, le créer. Vient ensuite l'étape Var avec un filtre. Je ne décrirai pas les règles selon lesquelles le filtre de prédicat est traité afin de ne pas compliquer la présentation, je dirai seulement que ce filtre décrit clairement les trois ensembles de données sur lesquels il est vrai:

1. <Var A = ”1” B = ”1” />
2. <Var A = ”2” />
3. <Var A = ”3” />

Nous devons donc nous assurer que l'élément <OBJS> a des éléments enfants <Var> avec de telles données. Et, enfin, l'étape suivante est X sans condition - cela signifie qu'il est nécessaire que chaque élément Var ait un élément enfant <X>.

Donc, tout est simple. À la suite de l'application d'un tel XPath de construction, par exemple, à un document

 <OBJS> <Var A=”2” /> </OBJS> 

on obtient le document de sortie:

 <OBJS> <Var A=”2”> <X/> </Var> <Var A=”1” B=”1”> <X/> </Var> <Var A=”3”> <X/> </Var> </OBJS> 

Et en même temps, nous avons géré exclusivement avec XPath, sans XSL ou quelque chose comme ça.

XPath algorithmique

Nous avons donc appris à XPath comment créer des données. Maintenant, apprenez-lui (un peu) à les traiter de façon algorithmique.

La séquence d'opérateurs peut être décrite par une expression ET logique habituelle. Il est calculé strictement de gauche à droite, c'est ce dont vous avez besoin. S'il doit être entièrement implémenté, il vous suffit de vous assurer que tous ses éléments renvoient une véritable expression.

 A and B and C … and Z 

Un opérateur conditionnel de la forme if (A) puis B else C , bien sûr (et je ne dirai rien de nouveau ici), peut être décrit par une expression logique

 A and B or C 

Tout est un peu plus compliqué avec la boucle. Je ne voulais tout simplement pas l'introduire comme ça, alors j'ai décidé de simplement introduire le concept d'une fonction XPath, qui peut être récursive. Et puis tout cycle peut être représenté comme une chaîne d'appels récursifs avec vérification de la condition de fin.

En principe, c'est presque tout (dans la version minimale). Même les variables ne sont pas nécessaires - elles sont remplacées par des éléments du document actuel. Seuls les arguments de fonction nommés sont requis.

Je vais vous donner un exemple. Supposons que nous ayons un document contenant deux listes de nombres décrites par une série d'éléments <list> imbriqués:

  <a> <b> <list data="1"><list data="2"></list></list> </b> <c> <list data="3"><list data="4"></list></list></c> </a> 

Soit qu'il soit nécessaire de concaténer des listes de l'élément <b> et de l'élément <c> et de placer le résultat directement dans <a>. Pour ce faire, trois fonctions XPath doivent être introduites:

 concat_list($#, $##): add_list(#/self::*) and add_list(##/self::*) add_list($#): count(list) = 0 and copy_list(#/self::*) or list[add_list(#/self::*)] or true() copy_list($#): count(#/list) = 0 or create(list[@data = #/list/@data]) and (list[copy_list(#/list)] or true()) 

et ajoutez-y le XPath appelant:

 concat_list(/a/b,/a/c) 

J'espère que, chers lecteurs, il vous sera un peu intéressant de comprendre un tel "code". La seule chose que je mentionnerai certainement est create (XPATH) est une fonction système qui exécute son argument XPATH en mode construction.

Et maintenant que tout cela est intéressant, bien sûr, mais la programmation sans variables est encore assez difficile. Comprenant cela, j'ai introduit des variables à part entière, qui, en fait, dans XPath existent déjà - elles commencent par le signe "$", mais j'ai ajouté la possibilité de leur attribuer des valeurs avec la nouvelle fonction set. S'il vous plaît, voici un exemple de la fonction depth_list avec deux arguments - une référence à l'élément initial contenant une liste imbriquée d'éléments (comme dans l'exemple ci-dessus), et une variable de sortie qui contient la longueur de la liste:

 depth_list($#, &$OUT1): set($OUT1,0) and (#/list[set($OUT1,1) and depth_list(#/list,$OUT0) and set($OUT1,max($OUT0+1,$OUT1))]) or true() 

Conclusion

Dans le micro-langage résultant, que j'ai appelé XPath Defender , j'ai ajouté quelques fonctions plus nécessaires et l'ai utilisé dans mon système pour reconnaître et générer des programmes PGEN ++ pour effectuer une tâche aussi importante que l'achèvement automatique du modèle d'un programme présenté comme un document XML. En d'autres termes, s'il existe une description textuelle d'un problème (pour être définitif, en russe), pour la solution duquel il est nécessaire de générer un programme, alors cette description est reconnue et se transforme en un ensemble ordonné d'éléments d'énoncé de tâche (objets avec paramètres). Il s'agit de la déclaration initiale, qui ne contient pas encore de plan pour résoudre le problème. Les éléments reconnus sont placés dans un document XML et les règles leur sont appliquées, écrites à la fois sous forme de délimitation simple ou de génération d'instructions XPath, et sous forme de fragments sur XPath Defender (c'est l'une des options du workflow). Ces règles valident et complètent le modèle de document XML avec des éléments d'un plan de solution. Et alors seulement, selon le modèle obtenu, le système construit un programme décisif. Ce circuit a été testé avec succès sur des problèmes simples de traitement mathématique de données vectorielles.

Mais encore, le résultat le plus important, je pense, est le fait qu'il a été possible de prouver qu'il est possible de construire un langage de programmation algorithmique, en utilisant presque exclusivement les moyens de l'habituel et en construisant XPath, il a fallu introduire uniquement des fonctions.