Merci Eric !
Comme tu le dis c'est un sujet passionnant, mais qui se complexifie au fur
et à mesure que j'avance...
J'apprend bcp cependant et le challenge en vaut la peine. Au départ j'avais
fait une recette maison, puis grâce à xml-fr j'ai découvert RelaxNG et il y
a pas longtemps la programmation "100% déclarative" en xsl !
Ce qui est difficile c'est de lier les impératifs, les échéances du projet
et la réalisation d'un code propre, ré-exploitable, prévu pour du long
terme... ce qui n'est pas toujours facile à faire comprendre à la hierarchie
!
Pour ce qui est de l'élément start, c'est une erreur d'interprétation un peu
rapide de la doc RelaxNG de ma part. En fait dans mon schéma maison j'avais
un élément <root> pour la racine et je l'ai tout simplement remplacé par
start... En fait j'aurai peut être mieux fait d'utiliser <element>, à partir
du moment ou je fais le choix de ne pas utiliser <grammar> ?
maintenant pourquoi je me suis tant restreint, dans le choix des élément
relaxNG utilisés...?
Par souci de simplicité, de temps : je ne voulais pas implémenter toutes les
possibilité de relaxNG et je me suis basé sur les besoins rééls des
documents que j'allais devoir éditer, en me disant que je pourrais toujours
implémenter le reste par la suite.
Mais maintenant que j'ai tout re-codé en déclaratif, il est vrai qu'ajouter
certains patern ne pose pas de grandes difficulté. Il s'agit de choisir
lesquels cependant, les plus pertinents :
je pense notamment au pattern <optional> (qui pourra m'être utile pour les
attributs notamment) et peut être aussi les patters nommés (define/ref).
petite question au passage le pattern grammar devient-il indispensable dans
le cas d'utilisation de pattern nommés et/ou de l'élément start ?
Il ne m'arrive jammais dans mes documents xml d'avoir des modèles de
contenus récursifs comme les div, sans ça je n'aurait pas pu exclure les
patterns nommés, en revanche ils pourront être utiles pour éviter de
redéfinir plusieurs fois des patterns identiques.
Je pense aussi peut être utilisé le pattern <externalRef>, pour avoir la
possibilité d'éditer un document externe (mes doc xml font références les
uns aux autres avec des liens par id).
Mais avant d'implémenter tout cela je voulais vérifier la faisabilité du
projet sur un schéma très simple n'utilisant que les quelques patterns
cités.
Pour ce qui est des contenus du type (B1, C1) & (B2, C2) comme j'avais mis
dans mon exemple... disons que ce n'est pas un cas réél, mais m'étant limité
aux éléments cités, je me suis dit qu'il fallait prévoir toutes les
combinaisons de ces éléments donc j'ai fait un exemple un peu tordu exprès.
La solution n'est peut être pas de limité uniquement les types d'éléments
mais surtout la manière de les imbriquer alors... ?
Après tout, il m'est tout à fait possible de mettre des consignes à
l'écriture du schéma : "n'utilisez que tels éléments et ne les imbriquez que
de cette manière ou de cette autre mais pas comme ceci ou comme cela"...
c'est peut être vers ça que je devrais me pencher... compte tenu des
impératifs de temps et des autres développements qui m'attendent...
Car mes document xml sont en fait très simples en réalité, je les ai écrit
en restant très déterministe, les seuls cas rencontrés sont :
* une suite d'éléments différents apparaissant une seule fois chacun et dans
un ordre prédéfinis :
<element name="A">
<element name="B"/>
<element name="C"/>
<element name="D"/>
</element>
* ou un élément qui peut contenir une liste de X et/ou Y (zeroOrMore,
chacun) dans n'importe quel ordre
<element name="conteneur">
<interleave>
<zeroOreMore>
<element name="X"/>
</zeroOreMore>
<zeroOreMore>
<element name="Y"/>
</zeroOreMore>
<interleave>
</element>
J'utilise l'élément group dans le seul but de définir un ensemble d'éléments
"adjacents" à éditer en une seule fois : dans le menu arborescent (cf. 1er
message) représentant le document xml (qui permet de choisir quelle noeud on
veut éditer) les group apparaisent également et permette d'éditer non pas un
seul noeud mais plusieurs (on envois plusieurs paramètres XpathNode à la
feuille de style qui applique chacun des template)
Je vais essayer la méthode que tu me conseilles (exécuter en chaîne une
série de templates dans des
modes différents)... je n'ai pas regardé dans le détail encore.
Je suis trop avancé dans le projet pour changer XSLT par un langage de
programmation, mais xslt n'est-il pas le mieux adapter pour ce type de
traitement réccursif sur une syntaxe xml ?
Pour info tu penses à quel(s) langage(s) par exemple ? il y a une partie
asp/vb dans mon projet qui me permet de manipuler le dom des documents xml :
le formulaire html envois les valeurs des "champs" (attribut ou text) à
modifier et ils sont modifiés par script asp. De même pour l'ajout des
noeuds, même si les boutons sont affichés par xsl, au final j'envois les
paramètres (quel noeud à ajouter, sous quel noeud etc) à une page asp qui se
charge d'effectuer le travail (sans contre validation)
>Personnellement, je pense que, quelque soit le langage de programmation,
>je travaillerais sur un schéma RELAX NG simplifié et chercherais à
>m'inspirer de la méthode déclarative décrite par James Clark :
>http://www.thaiopensource.com/relaxng/derivative.html.
Qu'entend tu par simplifié ? restreind à qq élément et/ou imbriqué de
manière déterminée (cf plus haut)?
J'ai jeté un coup d'oeil à la methode de James Clark et ... humm faudra que
je plonge plus dedans parce que survolé comme ça, j'avoue que je ne comprend
rien... il n'y aurait pas un petit exemple de "dérivée du schéma par le
document" quelque part ?
>Pour faire cela en XSLT, vous pourriez vous appuyer sur la bibiothèque
>FXSL (http://fxsl.sourceforge.net/) ou, si cela vous fait peut (il y a
>de quoi) faire une série de passes successives en utilisant une fonction
>node-set (personnellement je préfère cela à dyn:evaluate().
J'avais déjà entendu parler de cette bibliothèque FXSL, mais ça fait
beaucoup de choses à découvrir, je vais butiner un peu sur le site histoire
d'avoir quelques idées de ce qu'elle permet.
Merci en tout cas pour toutes ces pistes, j'étais bloqué et démotivé, là ça
permet de rebondir !
Matthieu.
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Received on Fri Oct 14 17:12:35 2005
