124 votes

Le XML est-il sensible à la casse ?

Question brève

Le XML est-il sensible à la casse ?

Question plus longue

Par exemple :

<Shirt color="Red"/>

L'attribut couleur est de type string qui peut contenir un ensemble de couleurs valides ( Red , Blue et Green ).

Pour valider le XML, j'ai utilisé le XSD suivant :

  <xs:simpleType name="ColorType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Red"/>
      <xs:enumeration value="Blue"/>
      <xs:enumeration value="Green"/>
    </xs:restriction>
  </xs:simpleType>

Est-ce que je suis attendu pour accepter différentes variations de cas de rouge, bleu et vert ? Ou bien le XML est largement accepté comme étant sensible à la casse ?

4 votes

Oui, c'est ça. C'est l'une des premières choses que l'on apprend sur le XML.

97voto

Jon Egerton Points 16192

Réponse courte :

Oui - XML est sensible à la casse.

Réponse plus longue :

Il est généralement admis que les énumérations sont sensibles à la casse. Toutefois, si vous souhaitez être plus souple, consultez la question ci-dessous, qui traite des énumérations insensibles à la casse :

Énumération insensible à la casse du type simple String de XML Schema

6 votes

Réponse plus longue : rien ne vous empêche d'écrire une application XML qui ne tient pas compte des cas. Mais ce ne serait ni attendu ni habituel.

19voto

Michael Kay Points 52194

Avec XSD 1.1, vous pouvez réaliser une énumération insensible à la casse en utilisant une assertion :

<xs:simpleType name="RGB">
  <xs:restriction base="xs:string">
    <xs:assert test="lower-case($value) = ('red', 'green', 'blue')"/>
  </xs:restriction>
</xs:simpleType>

XSD 1.1 est pris en charge dans les versions récentes de Saxon et Xerces.

0 votes

Soyez juste conscient de l'utilisation de XSD 1.1, à l'heure actuelle, c'est juste une recommandation du W3C - Xerces avec la validation XSD 1.1 est un artefact autonome en état bêta, et XSD 1.1 n'est pas supporté par le JDK, même pas par le plus récent 1.8. Il n'est même pas prévu pour le JDK 1.9 pour autant que je sache. Vous ne pouvez pas utiliser les technologies XML avancées comme JAXB basées sur XSD 1.1 intégré au JDK de cette façon.

2 votes

Oui, il faut être prudent, mais la réponse de @René doit être nuancée. Premièrement, "juste une recommandation du W3C" : eh bien, XSD 1.0 l'est aussi. Une "recommandation" est ce que le W3C appelle une spécification finie, finale, ratifiée. Oui, il est vrai qu'il n'existe actuellement que trois implémentations de XSD 1.1 (Saxon, Xerces et Altova), et c'est un facteur dont vous devez tenir compte. Mais ne vous laissez pas décourager par ce qui se trouve dans le JDK - le JDK a depuis longtemps abandonné la prise en charge des dernières normes du W3C (par exemple, il ne prend même pas en charge XPath 2.0), mais il existe de nombreuses bibliothèques tierces pour combler cette lacune.

0 votes

Bien sûr, cela dépend de la technologie utilisée. Si vous mettez en œuvre l'analyse syntaxique et le code de bas niveau, vous pouvez utiliser une bibliothèque d'analyse syntaxique tierce (Xerces pour XSD 1.1 est encore en version bêta, il existe deux artefacts différents de la même version de Xerces !) Pour l'exemple de JAXB - @Michael : Connaissez-vous une implémentation ou un dérivé de JAXB tiers faisant usage de XSD 1.1, générant ainsi des classes par exemple en utilisant des "alternatives" ? De toute façon, c'est à Ian de choisir en fonction de ses besoins.

2voto

Oui. L'examen de la spécification XML actuelle La seule déclaration apparente à ce sujet se trouve à la section 1.2, où les auteurs déclarent que

Les deux chaînes de caractères ou noms comparés sont identiques. Les caractères ayant plusieurs représentations possibles dans la norme ISO/CEI 10646 (par exemple, les caractères ayant à la fois une forme précomposée et une forme base+diacritique) ne correspondent que s'ils ont la même représentation dans les deux chaînes. Aucun traitement de la casse n'est effectué.

Notez la référence à un manque de pliage du boîtier . Pour illustrer les problèmes que peut causer l'inattention à ce détail, j'ai récemment analysé un code qui extrait des données d'un corpus de données physiologiques de taille moyenne (quelques 100 Go) où le nom d'un paramètre avait été changé de SPO2 en SpO2 au fil des ans, dans le logiciel principal.

En revanche, le logiciel utilisé pour extraire les données a fidèlement conservé la convention XML et a considéré les paramètres comme distincts. Le pire était à venir. Comme le nom du paramètre était utilisé pour nommer le fichier CSV dans lequel les données étaient écrites, et ce sous Windows, qui met les noms de fichiers en majuscules, deux poignées étaient ouvertes sur le même fichier, ce qui entraînait des erreurs mystérieuses.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X