2011-03-03 10 views
6

Necesito especificar un XSD para validar documentos XML. El XSD se usará para una generación JAXB de enlaces Java. Mi problema es especificar elementos opcionales de los que no conozco los nombres y que, en general, no estoy interesado en analizar.Creando un XSD válido que está abierto usando <all> y <any> elementos

La estructura de los documentos XML es como:

<TRADE> 
    <TIME>12:12</TIME> 
    <MJELLO>12345</MJELLO> 
    <OPTIONAL>12:12</OPTIONAL> 
    <DATE>25-10-2011</DATE> 
    <HELLO>hello should be ignored</HELLO> 
</TRADE> 

Lo importante es, que:

  • no puedo asumir cualquier orden, y la instancia de documento siguiente XML migtht tener etiquetas en un orden diferente
  • Solo estoy interesado en analizar algunas de las etiquetas, algunas son obligatorias y otras son opcionales
  • El documento XML NTS se pueden ampliar con nuevos elementos que no estoy interesado en el análisis

La estructura de mi XSD es como (no es un xsd válida):

<?xml version="1.0" encoding="ISO-8859-1"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 

    <!-- *********************************************** --> 
    <!-- Trade element definitions for the XML Documents --> 
    <!-- *********************************************** --> 

    <xs:complexType name="Trade"> 
    <!-- Using the all construction ensures that the order does not matter --> 
    <xs:all> 
     <xs:element name="DATE" type="xs:string" minOccurs="1" maxOccurs="1" /> 
     <xs:element name="TIME" type="xs:string" minOccurs="1" maxOccurs="1" /> 
     <xs:element name="OPTIONAL" type="xs:string" minOccurs="0" maxOccurs="1" /> 
     <xs:any minOccurs="0"/> 
    </xs:all> 
    </xs:complexType> 

    <!-- TRADE is the mandatory top-level tag --> 
    <xs:element name="TRADE" type="Trade"/> 

</xs:schema> 

Por lo tanto, en este ejemplo : DATE y TIME son obligatorios (deben estar en el XML exactamente una vez), OPTIONAL podría estar presente una vez y luego me gustaría especificar que todas las demás etiquetas están permitidas. El orden no importa.

¿Cómo especifico un XSD válido para esto?

Respuesta

5

Este es un problema de analizador clásico.

Básicamente, el BNF es:

Trade = whatever whatever* 
whatever = "DATE" | "TIME" | anything 
anything = a-z a-z* 

Pero esto es ambiguo. La cadena "DATE" puede ser aceptada bajo cualquier regla como "DATE" y como cualquier otra cosa.

Así que si usted tiene

<TRADE> 
    <TIME>12:12</TIME> 
    <DATE>25-10-2011</DATE> 
    <DATE>25-12-2011</DATE> 
</TRADE> 

no está claro si se debe aceptar o no.

Podría interpretarse ya sea uno de

"TIME", "DATE", anything 
anything, anything, "DATE" 
anything, anything, anything 
"TIME", "DATE", anything 
"TIME", "DATE", "DATE" 
etc. 

Todo se reduce a: Si usted tiene un comodín en combinación con una secuencia aleatoria, no se puede decidir qué token de manera significativa carrera en el que la regla.

No tiene sentido tener elementos opcionales junto con una tarjeta wilcard.

tiene dos opciones:

  • XS uso: la secuencia en lugar de xs: todo
  • no utilizan comodines

Como lo entiendo, ambas opciones están en conflicto con sus deseos .

Tal vez se puede construir un comodín que coincide con todo excepto FECHA, HORA etc.

+0

tuve un suspecion que este era el caso :-( La cosa extra que no escribió es, que yo sepa que los elementos serán máx aparecer una vez –

+0

Terminé teniendo un paso XSLT antes del paso de análisis. Esto funciona a la perfección, primero filtrando todas las etiquetas que no me interesan y luego validando de acuerdo con un xsd "delgado" que solo contiene elementos en los que estoy interesado. –

+0

What si sé que 'lo que sea 'nunca será una' fecha 'o' hora '? Entonces no habrá ninguna ambigüedad. –

2

¿Es un requisito difícil tener ataduras JAXB a sus elementos "conocidos"? Si no, básicamente puede tener <any maxoccurs="unbounded" processContents="skip"/> como su xsd, y luego seleccionar los elementos que le interesan del árbol DOM.

(Ver here cómo utilizar JAXB sin enlace de datos.)

+0

Me gustaría tener el enlace de datos (o al menos un XSD estrecho razonable), ya que no puedo usar XSD validación para verificar valores, longitud s y tipos de datos. –

Cuestiones relacionadas