Conventions de cas sur les noms d'élément?

Existe-t-il des recommandations formelles sur la casse des éléments dans XML?

Je sais que XHTML utilise des noms d'éléments en minuscules (par opposition au HTML qui utilise canoniquement des majuscules mais ne respecte pas la casse.)

Mais je parle de XML pour le contenu générique.

minuscule:

<customer> 
   <accountnumber>619</accountnumber>
   <name>Shelby Lake</name>
</customer>

affaire de chameau:

<customer> 
   <accountNumber>619</accountNumber>
   <name>Shelby Lake</name>
</customer>

PascalCase:

<Customer> 
   <AccountNumber>619</AccountNumber>
   <Name>Shelby Lake</Name>
</Customer>

MAJUSCULE:

<CUSTOMER> 
   <ACCOUNTNUMBER>619</ACCOUNTNUMBER>
   <NAME>Shelby Lake</NAME>
</CUSTOMER>

Remarque: je recherche des lignes directrices citées plutôt que des opinions. Mais l'opinion avec le plus de votes peut être considérée comme une ligne directrice.

La plupart des standards XML issus du W3C ont tendance à utiliser des minuscules avec des tirets.

Il existe une distinction philosophique entre le fait de considérer XML comme un format pour des documents neutres de plate-forme, que les normes W3C tentent d'encourager, et des langages tels que XAML qui voient XML comme une sérialisation d'un graphe d'objets spécifique à une plate-forme.

Si vous n'utilisez pas XML comme format de document neutre pour la plate-forme, mais comme une sérialisation spécifique à une application, vous pouvez aussi bien vous épargner un peu de peine et avoir une correspondance 1: 1 entre les noms XML et les noms spécifiques à la plate-forme. Mais presque tous les autres formats de graphes d'objets sont meilleurs que XML à cette fin.

Si c'est le cas, vous voudrez peut-être vous intégrer à XHTML, XSLT, SVG, XProc, RelaxNG et les autres.

Ce n'est pas que cela compte, mais j'ai toujours été partial pour PascalCase pour les éléments et camelCase pour les attributs:

<Root>
  <ParentElement attributeId="1">
    <ChildElement attributeName="foo" />
  </ParentElement>
</Root>

Il n'y a pas de recommandation formelle.

Étant donné que XML a été conçu avec le double objectif de conserver des documents et d' échanger des informations entre des systèmes disparates , il a été conçu de manière à pouvoir correspondre aux applications qui l'utilisent.

Ainsi .Net XML a tendance à utiliser ProperCasing (témoin XAML), tandis que d'autres XML utiliseront camelCasing, python_conventions, dot.naming et même COBOL-CONVENTIONS. Le W3C semble aimer un peu les minuscules avec des tirets (par exemple XSLT) ou juste les mots-clés en bas de casse masqués ensemble (par exemple MathML).

J'aime toutes les minuscules et pas de traits de soulignement, car cela signifie moins d'utiliser la touche [Shift] et mes doigts sont un peu paresseux. :)

Pour ajouter à la réponse de Metro Smurf.

Le modèle national d'échange d'informations (NIEM: http://en.wikipedia.org/wiki/National_Information_Exchange_Model ) dit d'utiliser:

• Upper CamelCase (PascalCase) pour les éléments.
• (inférieur) camelCase pour les attributs.

Le NIEM constitue une bonne option lorsque vous cherchez à vous conformer à une norme.

Pour développer mon commentaire ci - dessus : l'utilisation de «minuscules avec tirets» pose quelques problèmes dans XSLT. Plus précisément, il est facile de confondre un nœud appelé, par exemple, «année à partir de l'âge» avec une formule «année - âge» (par exemple soustraire l'âge de l'année).

Comme le souligne @KarlKieninger, il ne s'agit que d'un problème au niveau humain et non pour l'analyseur XSLT. Cependant, comme cela ne produira souvent pas d'erreur , l'utilisation de «minuscules avec tirets» comme norme pose problème, à mon humble avis.

Quelques exemples pertinents:

<a>1</a><b>1</b>
<xsl:value-of select="a+b"/>
outputs 2, as expected

<a>1</a><b>1</b>
<xsl:value-of select="a-b"/>
DOES NOT ERROR, BUT OUTPUTS NOTHING AT ALL

Dans le code ci-dessus, vous devez mettre au moins un espace avant un opérateur de soustraction, mais il n'y a pas une telle exigence pour un opérateur d'addition.

<a-b>1</a-b><c>1</c>
<xsl:value-of select="a-b -c"/>
outputs 0, as expected

Mais notez combien ce qui précède est déroutant à lire!

<a>1</a><a-b>3</a-b><b>2</b>
<xsl:value-of select="a-b"/>
outputs 3

<a>1</a><a-b>3</a-b><b>2</b>
<xsl:value-of select="a -b"/>
outputs -1

La présence d'un seul espace modifie la sortie ci-dessus, mais aucune des deux variantes n'est une erreur.

Voir la spécification technique des règles de dénomination et de conception XML UN / CEFACT version 3.0 page 23 pour quelques exemples de règles utilisées dans plusieurs normes.

Spécificités (à partir de la page 23 de la version 3.0 du 17 décembre 2009):

• LowerCamelCase (LCC) DOIT être utilisé pour nommer les attributs.
• UpperCamelCase (UCC) DOIT être utilisé pour nommer les éléments et les types.
• Les noms d'élément, d'attribut et de type DOIVENT être au singulier à moins que le concept lui-même ne soit au pluriel.

( autre lien, site suédois )

Le guide de style de Google recommande (peut-être même oblige) camelCase pour tous les noms d'éléments, ainsi que les noms d'attributs.

L'intention d'origine de la casse XML était en minuscules avec des tirets. Il est sensible à la casse et ne vous oblige pas à suivre cette convention - vous pouvez donc faire ce que vous voulez. Je n'ai pas de citations, désolé.

Je ne dirais pas que HTML utilise «canoniquement» des majuscules. Je pense qu'à l'origine, les majuscules étaient utilisées pour séparer visuellement le HTML du contenu plus facilement. Avec la coloration syntaxique de nos jours, ce n'est tout simplement pas nécessaire.

Je vire vers les minuscules, avec des tirets si nécessaire (plus rapide à taper aussi). Mélanger le cas en XML me semble juste mal.

Le cas de chameau obtient mon vote.

Quant aux exemples cités, peut-être que cette question peut être le lien que les gens citent.