XSD : Validation d'une donnée

Bonjour,
Je voudrais valider une zone de texte en vérifiant qu(il n'y a ni espace en début de ligne , ni espace en fin de ligne.
Ave cette expression j'arrive bien a tester en début de ligne mais rien en fin de ligne

Code:

---

^(\S([A-Za-z0-9]|[\+|\?|/|\-|:|\(|\)|\.|,|'| ]){1,70}\S)$

---

Merci par avance a qui pourrait m'aider

Faudrait donner des contre-exemples, parce que chez moi ta regex interdit bel et bien les espaces en début et en fin.
Puisque \S en début et en fin exige qu'il y ait un caractères, n'importe quoi sauf un espace.

Edit : au temps pour moi, j'avais pas copié le ^ et le $. Ils ne veulent rien dire en XSD, ils ont rien à faire là.

Citation:

---

Envoyé par thelvin

Faudrait donner des contre-exemples, parce que chez moi ta regex interdit bel et bien les espaces en début et en fin.
Puisque \S en début et en fin exige qu'il y ait un caractères, n'importe quoi sauf un espace.

---

Voici l'exemple

Code:

---

<nn>TOTO </nn>

---

Il s'agit de tester dans un fichier xml qu'il n'y ait pas d'espace dans la balise xml ni au début ni à la fin de la donnée
Lorsque je passe cet regexp dans NOTEPAD 2007 pas de problême mais dés que je passe en programmation avec les deux objets

Code:

---

1 2	Set xmlDoc = Server.CreateObject("MSXML2.DOMDocument.6.0") Set schemaCache = Server.CreateObject("Msxml2.XMLSchemaCache.6.0")

---

à ce moment là le progamme me met chaque ligne en erreur
Je ne sais pas si c'est suffisant pour toi comme contre exemple
Apparement il semblerait que les caractéres $ et ^ ne soit pas interprétés par les XSD

Citation:

---

Envoyé par loupat456

Apparement il semblerait que les caractéres $ et ^ ne soit pas interprétés par les XSD

---

Oui. Soit dit en passant, même s'ils étaient gérés par XSD, je vois pas pourquoi tu les aurais mis.

As tu une idée du problême à l'origine de la non-validation ?

Oui. ^ et $, comme nous venons de le dire.

Ils ne servent à rien dans le cas présent et n'existent pas en XSD. Le plus simple est de les enlever.

En fait j'ai trouvé la solution

Code:

---

\S([A-Za-z0-9]|[\+|\?|/|\-|:|\(|\)|\.|,|'| ]){1,35}\S

---

il suffisait de mettre \S devant et derriere le

Code:

---

([A-Za-z0-9]|[\+|\?|/|\-|:|\(|\)|\.|,|'| ]){1,35}

---

Citation:

---

As tu une idée du problême à l'origine de la non-validation ?

---

D'abord w3c schema ne porte pas support qu'un sous-ensemble de regex au plein sens du terme pratiqué par la plupart des langages.

En particulier, regex de w3c schema ne porte pas support d'"anchors" (^ et $); pourtant ils sont implicites et sont là pour toujours.

Dans la partie II de la recommendation, il se dit le suivant.

Citation:

---

Note: Unlike some popular regular expression languages (including those defined by Perl and standard Unix utilities), the regular expression language defined here implicitly anchors all regular expressions at the head and tail, as the most common use of regular expressions in ·pattern· is to match entire literals.

---

Or, en pratique, quand on a, par malheur ou par ignorance, mis des anchors dans la valeur, comment il se comporte?

Prenons un exemple

Code:

---

<xs:pattern value="^TOTO$" />

---

D'abord, le ^ au début va s'ignorer. Et puis le $ au dernière va se prendre comme le charactère litéral comme tel et il va verifier ceci:

Code:

---

<nn>TOTO$</nn>

---

Qu'est-ce qu'il prend pour une texte comme ceci?

Code:

---

<nn>^TOTO$</nn>

---

La valeur sera comme ça.

Code:

---

<xs:pattern value="\^TOTO$" />

---

ou si on veut

Code:

---

<xs:pattern value="\^TOTO\$" />

---

C'est un peu abérrant, d'autant plus pour l'anchor ^ étant ignoré, mais pas l'anchor $.

Mais en fin de compte, ça peut être assez dépendant du logiciel, en principe.