2010-02-10 8 views
8

Digamos que tiene que escribir un lenguaje basado en xml (sin opción) que al final será un tipo de formato "estándar", utilizado por miles de millones de aplicaciones en todo el mundo, o al menos lo espera. Ese idioma será como html para internet, pero en otro dominio específico. Algo realmente simple y descriptivo, que será interpretado por herramientas y otras aplicaciones.¿Qué debe saber un desarrollador antes de crear un nuevo formato o idioma basado en XML?

Ahora digamos que tiene una comprensión básica de cómo funciona XML (usted sabe cómo funcionan las etiquetas, que pueden tener atributos y que puede haber elementos en los elementos ...). Realmente entiende bien el dominio, pero nunca antes escribió un lenguaje o especificación de formato xml (aparte de algunos formatos xml básicos para las herramientas internas de su compañía).

¿Qué más debe saber para hacer su trabajo, verdad? Tal vez algunas características específicas del lenguaje XML? ¿Tal vez usando un archivo XSD como un archivo de especificación?

En resumen: ¿Cuáles son las mejores prácticas al diseñar y escribir especificaciones para este tipo de lenguaje?

+0

Todas las respuestas a estas preguntas han sido útiles de diferentes maneras ... ¿qué debo hacer? Hacer esta wiki? – Klaim

Respuesta

1

Definitivamente, querrá aprender XPath en algún momento u otro. Es (creo) la mejor forma de seleccionar XML.

3

En primer lugar, lo que necesita saber su problema de dominio realmente, realmente bien para asegurarse de que su margen de beneficio puede cubrir todos los requisitos para esos mil millones de aplicaciones. Todo lo demás es secundario. No es un problema de tecnología o herramientas.

+0

Bien, debería haber agregado que realmente entiende su dominio pero nunca antes escribió un lenguaje o una especificación de formato xml: D Se agregará en la pregunta. – Klaim

+0

Si está buscando algo que sea para una adopción muy amplia, a menos que sepa que es un genio certificado al 110%, probablemente sea mejor que lo abra para la revisión por pares más temprano que tarde para asegurarse de que todos esos los casos de esquina impares no se omiten. –

+0

Sí, piense en ello como un "estándar" abierto para uso abierto y amplio. – Klaim

3

La entrada de blog Using and Abusing XML tiene un buen consejo, entre otras cosas:

Otro mal uso popular de XML implica datos arbitrarios con XML-envolviendo finos etiquetas ... como los siguientes:

<key>Name</key><string>Audiobooks</string> 
<key>Playlist ID</key><integer>94</integer> 

En un formato de archivo XML mejor, diseñada a medida, es de esperar que este par a ser algo así como

<name id="94">Audiobooks</name> 
1

Definitivamente usar un esquema, si se trata de un XSD o relajarse NG.

+0

Use XSD - hay mejor soporte de herramienta. –

1

IBM hizo una serie en Principles of XML Design que contiene muchas verdades. El mejor consejo es que nunca hay una sola manera correcta 1 otro entonces:

  • ser conciso en sus opciones de diseño, si se elige la ruta A elegir por todas partes. es decir: si usa un elemento de envoltura <books> para contener <book> use un elemento de envoltura en todas partes para las colecciones.

  • Sea lo más preciso posible para evitar el desorden. Se supone que XML es legible por nosotros los humanos.

  • Evite espacios de nombres tanto como sea posible
  • TIENE que ser validable mediante un esquema.
+0

Eso es interesante. No conozco la historia de XML, así que ¿puedo preguntar si esos documentos siguen siendo correctos hoy? – Klaim

+1

Tengo que estar en desacuerdo con evitar los espacios de nombres. Si está desarrollando un estándar, especialmente uno que se utilizará junto con otros documentos XML, entonces necesita espacios de nombres. OTOH, es posible que solo necesite un espacio de nombre para todo el XSD. –

+0

Ese hizo que mis cejas subieran. Lo leeré para entender su punto. – Klaim

2

En primer lugar, solo haz algo si realmente no existe otra cosa que pueda usarse en su lugar.

Mantenga los nombres de elementos breves pero/y descriptivos.

Si es posible, tenga un esquema muy estricto que no permita múltiples formas de hacer lo mismo. Esto evitará una posible confusión sobre lo que es posible o cómo interpretar el marcado.

Tenga mucho cuidado al permitir la extensibilidad ya que esto puede permitir los problemas que un esquema estricto intenta evitar.

Asegúrese de versionar su esquema y siempre trate de evitar los cambios y/o permitir la compatibilidad con versiones nuevas.

Asegúrese de tener un validador y otras herramientas disponibles para hacer que su nuevo idioma sea lo más fácil posible.

1

en primer lugar, estoy de acuerdo con trevor, usted tiene que saber el área que está cubriendo, nada peor que un estándar remendado, que lo parece.

En segundo lugar, necesitará saber al menos un poco sobre xsd y xslt. y un poco más acerca de xpath/xquery, ya que los usuarios de su estándar probablemente los usarán para manejar su contenido.

En tercer lugar, sugiero que profundice lo más que pueda en otros estándares basados ​​en XML, para ver cómo se construyeron. el estándar XHTML es muy bueno para el estudio, ya que es el estándar XML más antiguo, y su evolución fue impulsada por el uso real durante un período prolongado de tiempo. También, es posible que desee considerar el estudio de átomo y RSS, xsd (esta vez como un standrad, no es una tecnología), y microformatos

2
  1. Aprender esquema XML
    • No trate de hacer que su esquema conveniente por permitiendo elementos en diferentes órdenes.
    • Haga que su esquema sea accesible a través de Internet. No necesita alojarlo en una URL relacionada con su espacio de nombres, pero puede ser agradable.
  2. Aprender espacios de nombres XML
  3. Aprender XPATH
  4. entender lo que un conjunto de información XML es, y aprender lo que significa para serializar una.
1
  • Namespaces: qué son, cuándo y cuándo no usarlas, cómo influyen en el análisis
  • Schema Validation/XSD.Una de las ventajas de XML es que es fácilmente verificable, por lo que esperan un esquema para validar contra de todo lo que sí llama a un estándar de
  • XPath y otros mecanismos de consulta de (XQuery es rara y en relación con XPath, pero sigue siendo una norma de él es poseer, al menos, de forma rápida mirar)
  • conocimiento general sobre escaping stuff, CDATA u otras formas
  • cuándo utilizar atributos vs cuándo utilizar elementos secundarios
  • estándares relacionados posibles. Esto no está estrictamente relacionado, pero, por ejemplo, si necesita agregar Firma de documento, ya existen estándares para eso (por ejemplo, XML Signature). Básicamente, cada vez que agregue una función, eche un vistazo rápido si ya hay un estándar y decida si vale la pena adaptarlo. Reinventar la Rueda está bien si al menos estás al tanto de por qué todas las otras ruedas apestan.
Cuestiones relacionadas