Re: Interdire les espaces dans un noeud texte en RelaxNG

Bonjour,
Le mardi 23 janvier 2007 à 22:24 +0100, Stephane Bortzmeyer a écrit :
> On Tue, Jan 23, 2007 at 08:42:31AM +0100,
>  Eric van der Vlist <[email protected]> wrote 
>  a message of 161 lines which said:
> 
> > Si rnv et xmllint disent le contraire, c'est un bug.
> 
> Hmmm, bon, je vais leur signaler, alors. Toutefois, j'ai beau lire
> http://www.w3.org/TR/xmlschema-2/, je ne vois pas clairement où cette
> différence entre xsd:string et les autres est indiquée. Si vous avez
> une référence précise, pour le rapport de bogue ? 

C'est défini dans la description de la facette whiteSpace:

http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-whiteSpace

xsd:string est le seul type prédéfini dont cette facette a la valeur
"preserve", xsd:normalizedString est le seul type prédéfini dont cette
facette à la valeur "replace". Pour tout les autres types la valeur de
cette facette est "collapse" ce qui justifie cette différence de
comportement.

> Votre livre, que
> vous citez, n'en donne apparemment pas.

Je détaille beaucoup plus ce sujet dans mon livre sur W3C XML Schema qui
n'est malheureusement pas disponible en ligne de manière gratuite.

> > Il n'y a aucun moyen d'empêcher cela et la seule solution pour interdire
> > les espaces en début et en fin d'une valeur est d'utiliser le type
> > xsd:string :
> 
> De toute façon, NMTOKEN, que j'employais, devrait être réservé aux
> attributs, non ?

Pas nécessairement : W3C XML Schema ne l'impose pas mais fait remarquer
que si vous voulez rester compatible avec les DTDs, vous devriez
effectivement ne l'utiliser que pour des attributs.   

> > element code {xsd:string { minLength = "2" maxLength = "3" pattern = "[a-z]+"} }
> 
> OK, ça marche, merci.
>  
> > Par contre, pour interdire ces caractères en début et fin de
> > valeurs, il faut utiliser là encore le type xsd:string :
> > 
> > name = element name {xsd:string { pattern="\S*" } }
> 
> Comme je veux autoriser les espaces à l'intérieur, j'ai mis :
> 
> name = element name {xsd:string { pattern="\S.*\S"}}
> 
> qui semble donner ce que je veux (en prime, il impose au moins deux
> caractères).
> 
> > La seule solution est, ici encore, d'utiliser xsd:string!
> 
> Oui, ça marche, mais ce n'est pas vraiment beau à lire :
> 
> salary = element salary {xsd:string {pattern="[0-9]+"}}
> 
> Le lecteur du schéma va bondir : "Mais pourquoi ce type n'a t-il pas
> utilisé xsd:integer ? En prime, son pattern ne permet pas +33 ou
> autres nombres qui seraient légaux avec xsd:integer !"

Effectivement, je ne le conseillerais pas dans le cas général...

Est-ce que les espaces sont vraiment gênants pour votre application? 

> > En fait, W3C XML Schema a décidé pour nous que les espaces ne sont
> > pas significatifs dans la majorité des cas et nous impose ce
> > comportement que cela nous plaise ou non.
> 
> Dommage. Mais merci beaucoup pour l'aide.

You're welcome!

Eric

-- 
GPG-PGP: 2A528005
If you have a XML document, you have its schema.
                                                  http://examplotron.org
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------


-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBFt6MhDvn+ZCpSgAURAqxQAJ9Mjm3PVHqxb2d/pPNOO0mESsSxwgCgmhA0
dizmlCAvE3wRawnZgVCCORI=
=qkfb
-----END PGP SIGNATURE-----