Re: Interdire les espaces dans un noeud texte en RelaxNG

Stephane Bortzmeyer <[email protected]> Tue, 23 Jan 2007 22:24:55 +0100
Newsgroups gmane.text.xml.french.tech
Message-ID <[email protected]>
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 ? Votre livre, que
vous citez, n'en donne apparemment pas.
 
> 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 ?

> 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 !"
 
> 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.