xml - para - Convenciones de casos sobre nombres de elementos
apodos segun nombres (10)
¿Hay alguna recomendación formal sobre el revestimiento del elemento en XML?
Sé que XHTML utiliza nombres de elementos en minúsculas (a diferencia de HTML, que canónicamente usa letras mayúsculas pero no distingue entre mayúsculas y minúsculas).
Pero estoy hablando de XML para contenido genérico.
minúsculas:
<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ÚSCULA:
<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 puede considerarse una guía.
Consulte la Especificación técnica de reglas de diseño y nombres XML de UN / CEFACT versión 3.0 página 23 para ver algunas reglas de ejemplo utilizadas en varios estándares.
Detalles (de la página 23 de la Versión 3.0 del 17 de diciembre de 2009):
- LowerCamelCase (LCC) DEBE ser utilizado para nombrar atributos.
- UpperCamelCase (UCC) DEBE usarse para nombrar elementos y tipos.
- Los nombres de elementos, atributos y tipos DEBEN estar en forma singular a menos que el concepto en sí sea plural.
El caso Camel obtiene mi voto.
En cuanto a los ejemplos citados, tal vez esta pregunta pueda ser el vínculo que las personas citan.
La intención original para la carcasa XML era minúsculas con guiones. Es sensible a mayúsculas y no requiere que sigas esa convención, para que puedas hacer lo que quieras. No tengo citas, lo siento.
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 de plataforma neutral, que los estándares W3C intentan alentar, 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 de plataforma neutral, sino como una serialización específica de la aplicación, entonces también puede ahorrar algo de molestia 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 objeto 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 diría que HTML "canónicamente" usa mayúsculas. Creo que originalmente mayúsculas se usaba para separar visualmente HTML del contenido más fácilmente. Con resaltar la sintaxis hoy en día, eso no es necesario.
Me dirijo hacia minúsculas, con guiones si es necesario (más rápido para escribir, también). La combinación de mayúsculas y minúsculas en XML me parece mal.
No es que importe, pero siempre he sido parco a PascalCase for Elements y camelCase para los atributos:
<Root>
<ParentElement attributeId="1">
<ChildElement attributeName="foo" />
</ParentElement>
</Root>
No hay una recomendación formal.
Como XML se diseñó con el doble propósito de conservar documentos e intercambiar información entre sistemas dispares , se diseñó para poder hacer coincidir las aplicaciones que lo utilizan.
Entonces .Net XML tiende a usar ProperCasing (testigo XAML), mientras que otro XML usará camelCasing, python_conventions, dot.naming e incluso COBOL-CONVENTIONS. Al W3C parece que le gusta minúsculas con guiones, bastante un bit (p. Ej., XSLT) o simplemente minúsculas con palabras juntas (por ejemplo, MathML).
Me gustan todas las minúsculas y sin guiones bajos, ya que eso significa menos uso de la tecla [Shift], y mis dedos son un poco flojos. :)
Para agregar a la respuesta de Metro Smurf.
El Modelo Nacional de Intercambio de Información (NIEM: http://en.wikipedia.org/wiki/National_Information_Exchange_Model ) dice que se debe usar:
- Upper CamelCase (PascalCase) para elementos.
- (inferior) camelCase para atributos.
El NIEM es una buena opción cuando buscas 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, por ejemplo, ''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, este 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 es pedir 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 adicional.
<a-b>1</a-b><c>1</c>
<xsl:value-of select="a-b -c"/>
outputs 0, as expected
¡Pero fíjate qué tan confuso es leer!
<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 el resultado anterior, pero ninguna variante es un error.
La guía de estilo de Google recomienda (quizás incluso mandatos) camelCase para todos los nombres de los elementos, así como los nombres de los atributos.