conventions de cas sur les noms d'éléments?

Question

Y at-il formel recommandations sur boîtier d'élément XML?

Je sais que XHTML utilise les noms d'éléments minuscules (par opposition à HTML qui utilise canoniquement en majuscules, mais est insensible à la casse.)

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

minuscule:

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

camelCase:

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

PascalCase:

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

MAJUSCULES:

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

Remarque: Je suis à la recherche de lignes directrices citées plutôt que des opinions. Mais l'opinion avec le plus up-voix peut être considérée comme une ligne directrice.

Answer 1

La plupart des normes XML provenant du W3C ont tendance à utiliser des minuscules avec des traits d'union.

Il y a une distinction philosophique entre voir XML comme format de documents neutres plate-forme, les normes du W3C tentent d'encourager, et des langues telles que XAML qui voient XML comme sérialisation d'un graphe d'objet spécifique de la plate-forme.

Si vous ne l'utilisez XML comme format de document neutre plate-forme, mais comme une application sérialisation spécifique, alors vous pourriez aussi bien vous épargner pris la peine et ont une correspondance 1: 1 entre les noms XML et les noms spécifiques de la plate-forme. Mais presque tout autre format graphique de l'objet est mieux que XML à cette fin.

Si vous êtes, alors vous voudrez peut-être adapter à XHTML, XSLT, SVG, XProc, RelaxNG et le reste.

Answer 2

Non que cela importe, mais je l'ai toujours été partielle PascalCase des éléments et des camelCase pour les attributs:

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

Answer 3

Il n'y a pas de recommandation formelle.

Depuis XML a été conçu avec les buts jumeaux de la tenue des documents et l'échange d'informations entre les systèmes disparates , il a été conçu de manière à pouvoir Match les applications qui l'utilisent.

XML .Net a tendance à utiliser ProperCasing (témoin XAML), tandis que d'autres XML utilisera notationsCamel, python_conventions, dot.naming, et même COBOL-CONVENTIONS. Le W3C semble comme minuscule-avec-tirets-tout-a-bit (par exemple XSLT) ou justlowercasewordssmashedtogether (par exemple MathML).

J'aime minuscules et pas underscores, car cela signifie moins d'utilisation de la touche [Shift], et mes doigts sont un peu paresseux. :)

Answer 4

Pour ajouter à la réponse de Metro Schtroumpf.

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

• Haute CamelCase (PascalCase) pour les éléments.
• (en bas) camelCase pour les attributs.

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

Answer 5

Voir la Naming XML UN / CEFACT et des règles de conception Spécifications techniques version 3.0 23 pour certaines règles par exemple utilisées dans plusieurs normes.

Specifics (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 types.
• éléments, d'attributs et les types DOIVENT être au singulier sauf si le concept lui-même est pluriel.

( autre lien, le site suédois )

Answer 6

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

Comme @KarlKieninger souligne, ce n'est un problème au niveau humain et non pas pour l'analyseur XSLT. Cependant étant donné que cela souvent ne pas produire une erreur , en utilisant « minuscule avec des traits d'union » comme norme est d'avoir des ennuis, à 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 la confusion est le lire ci-dessus!

<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 change la sortie ci-dessus, mais ni variante est une erreur.

Answer 7

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

Answer 8

L'intention originale pour boîtier XML était minuscule avec des traits d'union. Il est sensible à la casse et ne nécessite pas que vous suivez cette convention - afin que vous puissiez faire ce que vous voulez. Je n'ai pas de citations, désolé.

Answer 9

Je ne dirais pas que HTML « canoniquement » utilise les majuscules. Je pense que l'origine majuscule a été utilisé pour HTML visuellement distinct du contenu plus facilement. Avec la coloration syntaxique de nos jours, qui est tout simplement pas nécessaire.

Je vire vers minuscules, avec des tirets si nécessaire (plus rapide à taper aussi). Le mélange en XML cas se sent mal pour moi.

Answer 10

Camel cas obtient mon vote.

En ce qui a cité des exemples peut-être cette question peut être venir le lien des gens citent.