XSD - Changer le message de warning

Bonjour,

Dans mon fichier XSD, j'ai ceci pour vérifier le format des dates rentré qui doit être de type YYYY-MM-DD.

Code:

---

1 2 3 4 5 6 7 8 9

<xs:simpleType name="date_as_string"> <xs:annotation> <xs:documentation>Format de la date attendue : YYYY-MM-DD</xs:documentation> </xs:annotation> <xs:restriction base="xs:token"> <xs:pattern value="(\d{4}-\d{2}-\d{2})?" /> <!--<xs:pattern value="(\d{4}-((0[1-9])|(1[0-2]))-((0[1-9])|(1[0-9])|(3[0-1])))?" />--> </xs:restriction> </xs:simpleType>

---

L'inconvénient est que le message de retour (msxml) stipule que la date ne respecte pas le pattern... mais je voudrais personnaliser le message de retour pour mettre le texte que j'ai mis dans la balise xs:documentation, comment faire ?

:merci:

Pas prévu pour. Quelqu'un qui peut modifier un fichier XML à la main, peut aussi comprendre le message indiqué. Pas besoin d'en mettre un autre.

Après, il y a moyen de le faire quand même, mais c'est de l'overkill, c'est pas fait pour. Il va falloir le faire toi-même, pour la technologie que tu utilises.

En fait, l'utilisateur n'a pas accès à l'XSD. C'est à travers un éditeur XML qu'il obtient le message d'erreur s'il ne met pas une date valide. Mais l'information qui lui est renvoyée contient le pattern. Or, tout le monde ne s'y connait pas forcément en regex, d'où mon besoin d'afficher un message d'erreur compréhensible. Donc ce n'est pas possible ?

Citation:

---

L'inconvénient est que le message de retour (msxml) stipule que la date ne respecte pas le pattern... mais je voudrais personnaliser le message de retour pour mettre le texte que j'ai mis dans la balise xs:documentation, comment faire ?

---

De par xsd v1.0, ce serait d'une impasse. Xsd v1.1 commence de provisionner un peu de possibilité dans cette direction quand on fait valider via xs:assert. Mais il ne semble pas claire du tout comment faire intégrer avec un logiciel d'application en général - et bien entendu msxml2 ne support pas du tout xsd v1.1 pour le mement ou ne vais supporter jamais (?) avant être totalement remplacé.

Pourtant, si l'on est déterminé de la faire, je dirais ce devrait faire via une contrôle penible en utilsant les infos de .ParseError object, en particulière ses propriétés ErrorCode, Reason et Line. Une correspondance simple dans la code d'application pour les cas simple pour montrer les messages d'erreur qu'on a voulu de montrer. Pour les cas compliqués et avec beaucoup de détermination, on peut faire ça avec une base de données même pour en aider. Mais je m'en doute que ce vaille la peine finalement!