¿Convenciones de casos sobre nombres de elementos?

¿Existen recomendaciones formales sobre la carcasa de elementos en XML?

Sé que XHTML usa nombres de elementos en minúsculas (a diferencia de HTML que canónicamente usa mayúsculas pero no distingue entre mayúsculas y minúsculas).

Pero estoy hablando de XML para contenido genérico.

minúscula:

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

el caso de Carmel:

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

PascalCase:

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

MAYÚSCULAS:

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

Nota: estoy buscando pautas citadas en lugar de opiniones. Pero la opinión con más votos a favor puede considerarse una guía.

La mayoría de los estándares XML que se originan en el W3C tienden a usar minúsculas con guiones.

Existe una distinción filosófica entre ver XML como un formato para documentos neutrales de plataforma, que los estándares W3C intentan fomentar, y lenguajes como XAML, que ven XML como una serialización de un gráfico de objeto específico de la plataforma.

Si no está utilizando XML como un formato de documento neutral de la plataforma, sino como una serialización específica de la aplicación, entonces también podría ahorrarse algunas molestias y tener una correspondencia 1: 1 entre los nombres XML y los nombres específicos de la plataforma. Pero casi cualquier otro formato de gráfico de objetos es mejor que XML para ese propósito.

Si es así, es posible que desee encajar con XHTML, XSLT, SVG, XProc, RelaxNG y el resto.

No es que importe, pero siempre he sido parcial con PascalCase for Elements y camelCase en cuanto a atributos:

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

No hay ninguna recomendación formal.

Dado que XML se diseñó con el doble propósito de almacenar documentos e intercambiar información entre sistemas dispares , se diseñó para poder coincidir con las aplicaciones que lo utilizan.

Entonces .Net XML tiende a usar ProperCasing (testigo XAML), mientras que otros XML usarán camelCasing, python_conventions, dot.naming e incluso COBOL-CONVENTIONS. Al W3C parece gustarle las minúsculas con guiones bastante (por ejemplo, XSLT) o simplemente las palabras en minúscula mezcladas (por ejemplo, MathML).

Me gusta todo en minúsculas y sin guiones bajos, ya que eso significa menos uso de la tecla [Shift] y mis dedos son un poco perezosos. :)

Para agregar a la respuesta de Metro Smurf.

El modelo de intercambio de información nacional (NIEM: http://en.wikipedia.org/wiki/National_Information_Exchange_Model ) dice que se use:

• Upper CamelCase (PascalCase) para elementos.
• (inferior) camelCase para atributos.

El NIEM es una buena opción cuando busca cumplir con algún estándar.

Para ampliar mi comentario anterior : el uso de 'minúsculas con guiones' tiene algunos problemas en XSLT. Específicamente, es fácil confundir un nodo llamado, digamos, 'año a partir de la edad' con una fórmula 'año - edad' (por ejemplo, restar la edad del año).

Como señala @KarlKieninger, esto es solo un problema a nivel humano y no para el analizador XSLT. Sin embargo, dado que esto a menudo no producirá un error , usar 'minúsculas con guiones' como estándar está buscando problemas, en mi humilde opinión.

Algunos ejemplos pertinentes:

<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

En el código anterior, debe poner al menos un espacio antes de un operador de resta, pero no existe tal requisito para un operador de suma.

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

¡Pero tenga en cuenta lo confuso que es leer lo anterior!

<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 presencia de un solo espacio cambia la salida anterior, pero ninguna variante es un error.

Consulte la Especificación técnica de las reglas de diseño y nombres XML de UN / CEFACT, versión 3.0, página 23, para ver algunos ejemplos de reglas utilizadas en varios estándares.

Detalles (de la página 23 de la Versión 3.0 con fecha del 17 de diciembre de 2009):

• Se DEBE utilizar LowerCamelCase (LCC) para nombrar atributos.
• UpperCamelCase (UCC) DEBE usarse para nombrar elementos y tipos.
• Los nombres de elementos, atributos y tipos DEBEN estar en singular, a menos que el concepto en sí sea plural.

( otro enlace, sitio sueco )

La guía de estilo de Google recomienda (quizás incluso exija) camelCase para todos los nombres de elementos, así como los nombres de atributos.

La intención original para el formato XML era minúscula con guiones. Es sensible a mayúsculas y minúsculas y no requiere que sigas esa convención, por lo que puedes hacer lo que quieras. No tengo citas, lo siento.

Yo no diría que HTML "canónicamente" usa mayúsculas. Creo que originalmente se usaban mayúsculas para separar visualmente HTML del contenido más fácilmente. Con el resaltado de sintaxis hoy en día, eso simplemente no es necesario.

Me desvío hacia las minúsculas, con guiones si es necesario (también más rápido para escribir). Mezclar mayúsculas y minúsculas en XML me parece mal.

El caso Camel tiene mi voto.

En cuanto a los ejemplos citados, quizás esta pregunta pueda ser el vínculo que la gente cita.