salut,
 
je suis en train d'écrire un validateur XML pour ma boite.
ce validateur doit vérifier que nos auteurs respectent non seulement la DTD (facile à détecter) mais aussi des règles de saisie interne.
 
on n'accepte pas ceci par exemple:
 
<level type="3">
  <gp type="2">
    <p>...</p>
  </gp>
</level>
 
(c'est un exemple bidon mais qui illustre le besoin.)
 
on n'accepte pas de groupe de paragraphe de type 2 dans un level de type 3
 
et ce genre d'erreur, je dois les détecter et les noter dans un reporting (ça c'est facile).
 
j'ai regardé XML-Schéma mais je dois avouer que je ne pige pas trop... je suis en train de lire des ressources mais qq'un le connaissant pourrait-il me dire si avec Schéma je peux construire un ensemble de règles me permettant de construire un set de contraintes ? (profondeur: 3-4 noeuds, multi-attributs sur chaque noeud)
 
merci pour le coup de pouce.
bon, beh j'y retourne

[jfdsdjhfuetppo]--Message édité par TBone--[/jfdsdjhfuetppo]

euh... personne ?

bon, beh.. je rentre
 
j'ai trouvé une autre façon de faire... mais bon. si qq'un d'inspiré passe par ici... et qu'il peut juste m'informer...
 
je le remercie d'avance!
 
bonne soirée !

J'espere que tu adaptes un des parseurs standard du marché pour ce faire, sinon, tu n'es pas au bout de tes peines.
A priori, je laisserai le validateur standard faire son boulot, et verifierais les contraintes supplementaires sur l'arbre DOM construit par le parsing. Je te suggere d'utiliser Xerces (voir sur le site Apache).
 
Une autre possibilité serait d'utiliser TREX et RELAX-NGEN, voir ici: http://www.thaiopensource.com/trex/
A+,

Xerces (http://xml.apache.org/) supporte les schema. Pourquoi réinventer la roue ?

[jfdsdjhfuetppo]--Message édité par Matafan--[/jfdsdjhfuetppo]

Ce qu'il veut verifier comme contrainte n'est pas necessairement supporté par les schémas (d'ou mon lien sur TREX et RELAX, beaucoup plus puissants).
Mais sinon, bien d'accord sur Xerces. Pour ceux devant implementer en C/C++, il y a pas mieux actuellement.
En java, je sais pas, mais je suppose qu'il est tres bien aussi.
A+,

gilou> j'utilise Xerces en effet pour la validation de mon document XML (je ne compte pas réinventer la roue surtout si elle tourne bien et c'est en Java au fait.).  
c'est ton approche que j'ai mis en fonction.    
   
validation XML -> validation logique.  
   
mais mon problème surgit au niveau suivant.  
   
je dois tester ce document en fonction d'une logique éditoriale. (cf. mon exemple) et donc ma question était: "est-ce que schéma peut m'aider à construire un ensemble de contraintes sur un noeud en fonction de ses parents. (3 niveaux de profondeur, multi-attributs sur chaque niveau)
 
'oilà.
 
merci!

(je vais voir les liens donnés)

TBone a écrit a écrit : gilou> j'utilise Xerces en effet pour la validation de mon document XML (je ne compte pas réinventer la roue surtout si elle tourne bien et c'est en Java au fait.).     c'est ton approche que j'ai mis en fonction.             validation XML -> validation logique.           mais mon problème surgit au niveau suivant.           je dois tester ce document en fonction d'une logique éditoriale. (cf. mon exemple) et donc ma question était: "est-ce que schéma peut m'aider à construire un ensemble de contraintes sur un noeud en fonction de ses parents. (3 niveaux de profondeur, multi-attributs sur chaque niveau)   'oilà.   merci!

Tu devrais pouvoir valider ce genre de contraintes avec du XSL je pense: ecrire une feuille de style en XSL qui renvoie "Fichier valide" ou "Erreur ligne..." avec un fichier en input, parce que si tes contraintes, c'est sur des valeurs d'attribut sur qques niveaux de hierarchie, XSL sait assez bien faire cela.
A+,

XSL ne me semble pas une bonne idée. Déjà parce que c'est la merde à écrire (!!!) et ensuite parce que c'est pas fait pour ca ... (le but c'est de transformer un XML en un autre fichier texte)
 
si tu n'as pas trop de contrôles à faire, tu pourrais faire une vérif, après une première validation par les xml schema, en utilisant un parser SAX ...  
=> tu fais un maximum de vérif avec les schema, et les vérif que tu n'as pas pu faire, tu les fais après en SAX ...

XSL c'est un langage de prog comme un autre: on est pas obligé de s'en servir pour ne faire que de la transfo de texte.
Quand a sa syntaxe, elle est pas si compliquée avec un peu de pratique.
XSL ca implemente bien entre autres: l'acces aux valeurs d'attributs et XPath.
Or ce sont ces deux trucs dont il a l'air d'avoir besoin pour ses contraintes.
Quand a passer par du SAX, la je vois pas trop l'interet, puisque s'il veut acceder aux infos hierarchiques, il va falloir qu'il maintienne les infos lui meme. Ca serait nettement plus simple sur l'arbre DOM (ma suggestion initiale).
A+,

[jfdsdjhfuetppo]--Message édité par gilou--[/jfdsdjhfuetppo]

j'ai lu de la doc XSL et ça me paraît compliquos pour ce que je veux faire.  
 
je m'oriente vers une solution XPath et DOM.  
 
/!\ évolution du projet >> une partie des contraintes viendront d'une base de données de contraintes remplie par un "administrateur éditorial". (c'est pompeux comme terme nan? )  
 
-> j'arrive à construire des requêtes XPath en fonction des contraintes de la DB(qu'elles soient positives (un seul élément fils de tel ou tel type, telles valeurs d'attributs pour tel attribut, ...) ou négatives ( pas de fils de tel type pour tel noeud, ...)  
 
=> je liste les erreurs "logiques" de mon document. c'est OK.  
 
souci actuel> sortir les erreurs trouvées par ordre chronologique.  
 
Sol1: DOM/XPath: c'est le plus facile. je parse la liste de mes contraintes XPath, j'en déduis une NodeList de noeuds correspondants. OK. mais pas de notion d'ordre d'apparition.  
 
Sol2: SAX/XPath: pas encore essayé de travailler avec SAX  
il me semble que je dois parser mon document XML et à chaque événement (rencontre d'un noeud) vérifier si il correspond à une de mes contraintes XPath. j'ai bon ? si oui, il me reste à trouver comment connaître l'environnement XPath local du noeud (devrait être possible assez facilement) mais ensuite à chercher son équivalent dans la liste des XPath globaux de contraintes. et ça...

Ben pour les noeuds, c'est facile, c'est un parcours d'arbre par profondeur d'abord.
Pour les attributs, comme il y a pas d'ordre en XML sur les attributs, tu peux pas savoir quel attribut a ete lu en premier a priori (meme en SAX, ca marche pas: tu as un evenement START_ELEMENT qui te file l'element et sa liste d'attributs reordonnes par le parser, d'un coup).
A+,

[jfdsdjhfuetppo]--Message édité par gilou--[/jfdsdjhfuetppo]

TBone a écrit a écrit :   Sol2: SAX/XPath: pas encore essayé de travailler avec SAX   il me semble que je dois parser mon document XML et à chaque événement (rencontre d'un noeud) vérifier si il correspond à une de mes contraintes XPath. j'ai bon ? si oui, il me reste à trouver comment connaître l'environnement XPath local du noeud (devrait être possible assez facilement) mais ensuite à chercher son équivalent dans la liste des XPath globaux de contraintes. et ça...

 
C'est sur que si tes contraintes sont exprimées à partir de XPath, le choix de DOM est bien plus adapté.
 
L'idée que j'avais eu au départ, c'était d'avoir un ensemble d'objet Contrainte. A chaque évenement (rencontre d'une balise, etc ...), tu informes les contraintes. Chacune des contraintes pourras alors traiter ou non l'évenement quivant que la contrainte porte sur cette balise ou non.
 
C'est une idée un peu simpliste, et qui à priori ne correspond plus très bien à ton projet (ajout de contraintes via une base) ... Ca complique un peu les choses. D'ailleur ca me parait diffcilement applicable à moins que vous ayez parfaitement défini les type de contraintes possible, ce qui en limite énormément les possibilités. Enfin c'est l'impression que ca me donne, mais bon, j'ai pas toutes les données ...  ,)
 
Attention quand même avant de faire ton choix : DOM est très gourmand en CPU et en mémoire dans le cas de gros fichiers XML. C'est une chose à prendre en compte si le volume de données XML à vérifier est important.

gilou> ouaip. pour les noeuds c'est facile... mais j'avais d'abord pensé à lister toutes mes contraintes XPath, ensuite pour chacune d'elle sortir les noeuds correspondants. -> perte de chronologie des noeuds puisque séquence sur les contraintes. (pour les attributs, c'est pas grave)  
   
-> je cherche
   
benou> pour DOM et l'utilisation CPU/RAM, j'ai eu le coup avec un document XML (historique de modification de codes juridiques) de 7.8Mb qui faisait... 178Mb en RAM. (XML généré -> ne passera pas par le futur validateur logique)  
la taille des fichiers saisis à valider oscille entre 2ko et 200ko (qques rares fichiers à 300ko.)  
 
les principales contraintes portent sur 2 choses:  
 
- détection d'attributs ambigus pour un élément.
  (notre dtd comporte un élément <link> ayant comme attributs file et codoc. où file correspond à un ... file (pdf, ...) et codoc correspond à un identifiant de document XML. file et codoc ne peuvent être remplis en même temps. (nos clients n'utilise pas nécessairement un éditeur XML checkant la DTD (d'autant plus vrai lors d'une saisie en masse par certaines boîtes de saisie papier->électronique))
 
- détection d'incohérences d'architecture.  
  on veut que la logique d'édition d'un document soit réglée par l'administrateur éditorial. -> il doit être capable de dire qu'il n'accepte pas telle ou telle séquence de noeuds.
(pas de <p type=3"> dans un <gp type="2"> lorsque l'on est dans un <level type="3"> par exemple (bidon).
 
Un 3ème point, plus facile, est la vérification de la valeurs d'attributs en fonction de sa place dans le document.
ex.: dans un <gp type="2">, je ne pourrai avoir que des p de type 4, 5 et 6. (ex. bidon mais qui illustre)
 
à l'heure actuelle, l'admin peut générer ses contraintes dans mySQL (bientôt via une interface Swing), j'en déduis le XPath correspondant et je sors (très bientôt ) la liste des erreurs (suivant un niveau de gravité)
 
 
le but final du projet est d'obtenir un ensemble d'outils dont un validateur et un enrichisseur se basant sur une base de donnée d'édition contenant des informations utiles à plusieurs personnes (saisie des documents). (liens possibles vers les différents documents, mot-clés, ...). 2 façons de remplir cette base: petit à petit au cours de la saisie et en batch.(lecture des documents et envoi des données (permettant de calculer des liens inverses beaucoup plus facilement pour les thématiques et autres par exemple.))
 
'oilà. merci pour le coup de main!

Tu bosses pour Juris Classeur?
A+,

non.
mais je connais de nom. (je ne suis pas basé en France mais j'ai dû bosser avec des fichiers ORT si ça te dit qque chose)
 
@+

Bien, le projet avance bien... mais il évolue aussi...
 
récapitulons...
 
je valide avec une DTD des documents XML, et ensuite je checke des éléments bien particuliers en fonction de contraintes XPath venant d'une base mySQL.
 
soit, ça marche.
 
mais
 
j'ai fait joujou plus en profondeur avec XML Schema (transfo d'une DTD en Schema itou) et mon prog valide bien mes documents (grâce à une lib trouvée chez Sun (Multi-Schema Validator))
 
seulement voilà, j'essaie d'ajouter des contraintes dans ce schéma sans succès...
 
je voudrais par exemple énoncer que pour un élément donné, certains de ces attributs sont exclusifs.
 
<element a1=" "/> ou element a2=" "/> et pas <element a1=" " a2=" "/>
 
j'ai ceci pour l'instant
 
<xs:element name="link">
  <xs:complexType mixed="true">
    <xs:choice minOccurs="0" maxOccurs="unbounded">
 <xs:element ref="style"/>
 <xs:element ref="img"/>
    </xs:choice>
  <xs:attribute name="url" type="xs:string"/>
  <xs:attribute name="doc" type="xs:string"/>
</link>
 
et je cherche à exclure soit "url" soit "doc"...
alors si qq'un sait m'aider car là je sèche...  
 
j'ai la démo de XMLSpy (4.3) en attendant de trouver un éditeur sous Linux...
 
merci!