uso - ¿Hay una convención de nomenclatura estándar para elementos XML?
xml distingue entre mayusculas y minusculas (14)
Reglas de nombres XML
Los elementos XML deben seguir estas reglas de denominación:
- Element names are case-sensitive
- Element names must start with a letter or underscore
- Element names cannot start with the letters xml(or XML, or Xml, etc)
- Element names can contain letters, digits, hyphens, underscores, and periods
- Element names cannot contain spaces
Se puede usar cualquier nombre, no hay palabras reservadas (excepto xml).
Las mejores prácticas de nomenclatura
- Create descriptive names, like this: <person>, <firstname>, <lastname>.
- Create short and simple names, like this: <book_title> not like this: <the_title_of_the_book>.
- Avoid "-". If you name something "first-name", some software may think you want to subtract "name" from "first".
- Avoid ".". If you name something "first.name", some software may think that "name" is a property of the object "first".
- Avoid ":". Colons are reserved for namespaces (more later).
- Non-English letters like éòá are perfectly legal in XML, but watch out for problems if your software doesn''t support them.
Estilos de nombres
No hay estilos de nombres definidos para elementos XML. Pero aquí hay algunos de uso común:
- Lower case <firstname> All letters lower case
- Upper case <FIRSTNAME> All letters upper case
- Underscore <first_name> Underscore separates words
- Pascal case <FirstName> Uppercase first letter in each word
- Camel case <firstName> Uppercase first letter in each word except the first
¿Existe algún estándar, de facto o de otro tipo, para documentos XML? Por ejemplo, ¿cuál es la "mejor" forma de escribir una etiqueta?
<MyTag />
<myTag />
<mytag />
<my-tag />
<my_tag />
Del mismo modo, si tengo un valor enumerado para un atributo que es mejor
<myTag attribute="value one"/>
<myTag attribute="ValueOne"/>
<myTag attribute="value-one"/>
Consulte este enlace ... Estándares y convenciones XML
EDITAR: Este enlace está roto, el nuevo enlace está debajo: http://docs.oracle.com/cd/E82085_01/141/funtional_artifacts_guide/or-fasg-standards.htm
Es subjetivo, pero si hay dos palabras en una etiqueta de elemento, la capacidad de lectura se puede mejorar agregando un guión bajo entre palabras (por ejemplo, <my_tag> ) en lugar de no usar separador. Referencia: http://www.w3schools.com/xml/xml_elements.asp . Entonces, según w3schools, la respuesta sería:
<my_tag attribute="some value">
El valor no necesita usar un subrayado o separador, ya que se le permiten espacios en los valores de los atributos, pero no en los nombres de las etiquetas de los elementos.
He estado buscando mucho para un buen enfoque, también leyendo este hilo y algunos otros, y votaría por usar guiones .
Se usan ampliamente en ARIA ( https://developer.mozilla.org/de/docs/Web/Barrierefreiheit/ARIA ) que se pueden ver en muchos códigos fuente y, por lo tanto, son comunes. Como ya se señaló aquí, están permitidos, lo que también se explica aquí: Usar - en nombre del elemento XML
También como un beneficio adicional: al escribir HTML en combinación con CSS, a menudo también tiene clases cuyos nombres usan guiones como separador por defecto. Ahora, si tiene etiquetas personalizadas que usan clases CSS o atributos personalizados para etiquetas que usan clases CSS, entonces algo como:
<custom-tag class="some-css-class">
es más consistente y lee, en mi humilde opinión, mucho mejor que:
<customTag class="some-css-class">
Microsoft adopta dos convenciones:
Para la configuración , Microsoft usa camelCase . Mire el archivo de configuración de Visual Studio. Para VS2013, se almacena en:
C: / Archivos de programa (x86) / Microsoft Visual Studio 12.0 / Common7 / IDE / devenv.exe.config
Ejemplo:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
- Microsoft también usa UpperCase para su XAML. Supongo que es para diferenciar de HTML (que usa minúsculas).
Ejemplo:
<MenuItem Header="Open..." Command="ApplicationCommands.Open">
<MenuItem.Icon>
<Image Source="/Images/folder-horizontal-open.png" />
</MenuItem.Icon>
</MenuItem>
Muchos dialectos XML centrados en documentos usan minúsculas en latín básico y guión. Tiendo a ir con eso.
Los generadores de código que asignan XML directamente a los identificadores de lenguaje de programación son frágiles y (con la excepción de la serialización de objetos ingenuo, como XAML) deben evitarse en formatos de documentos portátiles; para una mejor reutilización y longevidad de la información, el XML debería tratar de hacer coincidir el dominio, no la implementación.
No hay una recomendación explícita. Según otra recomendación del W3C, la de XHTML , he optado por minúsculas:
4.2. Los nombres de elementos y atributos deben estar en minúsculas
Los documentos XHTML deben usar minúsculas para todos los nombres de elementos y atributos HTML. Esta diferencia es necesaria porque XML distingue entre mayúsculas y minúsculas, por ejemplo, <li> y <LI> son etiquetas diferentes.
Normalmente alineo la convención de nomenclatura XML con la misma convención de nomenclatura en otras partes del código. La razón es que cuando cargo el XML en Object, sus atributos y nombres de elementos se pueden denominar como la misma convención de nomenclatura actualmente utilizada en el proyecto.
Por ejemplo, si su javascript usa camelCase, entonces su XML también usa camelCase.
Para mí, es como discutir el estilo del código para un lenguaje de programación: algunos argumentarán a favor de un estilo, otros defenderán una alternativa. El único consenso que vi es: "¡Elija un estilo y sea consecuente"!
Solo observo que muchos dialectos XML solo usan nombres en minúsculas (SVG, Ant, XHTML ...).
No obtengo la regla "sin espacios en los valores de los atributos". De alguna manera, envía al debate "¿qué poner en atributos y qué poner como texto?".
Quizás estos no sean los mejores ejemplos, pero hay algunos formatos XML conocidos que usan espacios en los atributos:
- XHTML, particularmente el atributo de clase (puede poner dos o más clases) y por supuesto los atributos alt y title.
- SVG, con por ejemplo el atributo d de la etiqueta de ruta.
- Ambos con atributo de estilo ...
No entiendo completamente los argumentos en contra de la práctica (parece que se aplican solo a algunos usos) pero al menos es legal y se usa ampliamente. Con inconvenientes, aparentemente.
Ah, y no necesita espacio antes de la barra de cierre automático. :-)
Sospecho que los valores más comunes serían camelCased, es decir,
<myTag someAttribute="someValue"/>
En particular, los espacios causan algunas fallas si se mezclan con generadores de código (es decir, para [de] serializar xml a objetos), ya que no hay muchos idiomas que permitan enumeraciones con espacios (lo que exige un mapeo entre los dos).
Yo prefiero TitleCase para los nombres de elementos y camelCase para los atributos. Sin espacios para ninguno.
<AnElement anAttribute="Some Value"/>
Como comentario adicional, realicé una búsqueda rápida de las Mejores Prácticas en XML, y se me ocurrió este enlace bastante interesante: Esquemas XML: Mejores Prácticas .
rss es probablemente uno de los esquemas xml más consumidos en el mundo y es camelCased.
La especificación está aquí: RSS
De acuerdo, no tiene atributos de nodo en el esquema, pero todos los nombres de elementos de nodo están en camelCase. Por ejemplo:
lastBuildDate managingEditor pubDate
Reglas de nombres XML
Los elementos XML deben seguir estas reglas de denominación:
- Los nombres pueden contener letras, números y otros caracteres
- Los nombres no pueden comenzar con un número o caracter de puntuación
- Los nombres no pueden comenzar con las letras xml (o XML, o Xml, etc.)
- Los nombres no pueden contener espacios Se puede usar cualquier nombre, no hay palabras reservadas.
Tiende a preferir las etiquetas en minúsculas o en camello y dado que los atributos normalmente reflejan valores de datos, no de contenido, me apegaría a un valor que podría usarse como nombre de variable en cualquier plataforma / idioma que pudiera interesar, es decir, evitar espacios pero el otro dos formas podrían estar bien