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


120

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.


1
duplication possible de Y a
Basil Bourque

Réponses:


88

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.


7
cela signifie-t-il que les minuscules avec tirets sont recommandées ou non?
WarFox

9
@WarFox Je ne pense pas que quiconque ait fait une recommandation officielle. IME, les formats qui proviennent de w3c pour l'interopérabilité ont tendance à être dans le style d'un trait d'union; les formats qui proviennent de Microsoft et de certains autres ont tendance à être étroitement associés à une implémentation et à la convention pour les noms d'objets dans le langage utilisé pour l'implémentation. Si vous utilisez XML pour découpler les systèmes, le fait de ne pas coupler votre XML au style de langage d'un composant de ce système peut vous forcer à penser en termes de messages plutôt que d'objets, et je recommanderais donc le style minuscule et trait d'union.
Pete Kirkham

5
Notez que «minuscules avec tirets» pose quelques problèmes dans XSLT. Plus précisément, il est facile de confondre un nœud appelé, disons, «année à partir de l'âge» avec une formule «année-âge» (par exemple soustraire l'âge de l'année)
Richard Kennard

3
@RichardKennard Est-ce que cette confusion est possible seulement au niveau humain? Pour xslt, les espaces requis (?) Autour de l'opérateur fournissent une distinction claire et sans ambiguïté, n'est-ce pas?
Karl Kieninger

1
@KarlKieninger c'est vrai, mais la confusion au niveau humain est une préoccupation importante, à mon humble avis. Voir ma réponse détaillée ci-dessous.
Richard Kennard

64

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>

31

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. :)


2
Il semble que s'il avait pour but "d'échanger des informations", une norme pour les conventions de dénomination serait absolument souhaitée. Cela s'appliquerait également à tous les documents utilisés par plus d'une implémentation spécifique (par exemple, qui n'étaient pas des sérialisations ponctuelles).

25

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.


1
Voici le document NIEM où ils décrivent les conventions de dénomination des attributs et des éléments: niem.gov/documentsdb/Documents/Technical/NIEM-NDR-1-3.pdf
e1i45

Je sais qu'il est ancien, mais le lien ci-dessus est rompu, mais ce lien semble avoir mis à jour des détails concernant la convention NIEM pour Elements / Attrubutes: reference.niem.gov/niem/specification/naming-and-design-rules
CajunCoding

13

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.


3
Vendu. En outre, l'outil de génération de code MS .NET (xsd.exe) supprimera simplement les traits d'union lorsqu'il crée des classes de désérialisation. Donc, à la place, si des propriétés comme "alpha-beta" vous obtenez "alphabeta". Ainsi, non seulement les noms ne se traduisent pas exactement, mais ils sont plus difficiles à lire. Et si vous avez besoin de créer du xml avec des traits d'union MS SQL, c'est également un problème. Les éléments spécifiques à la SP ne devraient pas dicter une norme, mais ils sont suffisamment utilisés pour que je pense que cela puisse être considéré comme une considération. Et cela m'oriente vers des minuscules délimitées par un soulignement ou une casse mixte.
Karl Kieninger

1
Il semble que XSD.exe ajoute maintenant un XmlElementAttribute à la plupart des propriétés, et s'il y a un trait d'union, il ajoute explicitement la chaîne ElementName comme premier paramètre afin qu'il soit clarifié. Le problème que j'ai trouvé est que, selon vos bibliothèques .NET, cela n'a peut-être pas d'importance - l'élément ne sera toujours pas désérialisé sur certains systèmes. Il fonctionne dans VS2012 sur Win7, mais ne fonctionne pas en tant qu'exe sur un serveur 2008.
David Storfer

13

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 )


2
-1: votre lien est cassé - c'est peut-être une URL interne? Veuillez le réparer, et je supprimerai le vote défavorable.
John Saunders

3
Bien que certainement intéressant, le document cité dans cette section / page spécifique établit des règles pour les schémas XML , et non les parsers / documents xml qui adhèrent à ce schéma. Ce sont deux choses différentes.
MrCC

Pour tous ceux qui se demandent quelle est la différence entre LowerCamelCase et UpperCamelCase: mySettingName est un exemple de LowerCamelCase (qui aurait pu être plus intelligent d'appeler lowerCamelCase), et MySettingName est un exemple d'UpperCamelCase.
Jinlye


4

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é.


1

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 HTML est indépendant de la casse. Ce n'est pas le même XML / XHTML.

-2

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.