XSD - ¿Cómo describir un conjunto desordenado de tipos de elementos donde el primer elemento debe aparecer primero en la secuencia?

Question

Esta es una pregunta de esquema XML.

Sé que el elemento xsd:all no puede aparecer en una secuencia (debe ser el elemento de nivel superior de su tipo).

Es decir, no puede utilizar el siguiente:

<xsd:complexType name="Application"> 
    <xsd:sequence> 
    <xsd:element ref="Name"></xsd:element> 
    <xsd:all> 
     <xsd:element ref="ADD"></xsd:element> 
     <xsd:element ref="DELETE"></xsd:element> 
    </xsd:all> 
    </xsd:sequence> 
</xsd:complexType> 

Mi pregunta es cómo declarar la "ADD" y "Borrar" elementos anteriores en cualquier orden (conjunto desordenado), pero aún así asegurarse de que el elemento "Nombre" sería el primero y siempre aparecería. (Piense en la situación en la que no solo tengo "AGREGAR" y "ELIMINAR", sino que aproximadamente 10 o más elementos desordenados establecen: AGREGAR, ELIMINAR, EDITAR, etc.)

NOTA IMPORTANTE: el AGREGAR y ELIMINAR pueden aparecer solo una vez, pero su orden no se importa:

<Application> 
    <NAME> 
    <DELETE> 
    <ADD> 
</Application> 

pero nO:

<Application> 
    <NAME> 
    <DELETE> 
    <ADD> 
    <DELETE> <!--cannot appear twice--> 
</Application> 

Answer 1

Si entiendo su petición está en el camino correcto, lo único que se está perdiendo es maxOcurrencias = "sin límites" en tu elección.

creé el siguiente esquema:

<?xml version="1.0"?> 
<xs:schema targetNamespace="http://someNamespace" xmlns="http://someNamespace" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <xs:element name="Root" type="Application"> 
    </xs:element> 

    <xs:complexType name="Application"> 
    <xs:sequence> 
     <xs:element ref="Name"></xs:element> 
     <xs:choice maxOccurs="unbounded"> 
     <xs:element ref="ADD"></xs:element> 
     <xs:element ref="DELETE"></xs:element> 
     </xs:choice> 
    </xs:sequence> 
    </xs:complexType> 

    <xs:element name="Name"/> 
    <xs:element name="ADD"/> 
    <xs:element name="DELETE"/> 
</xs:schema> 

y funcionó bien para

<ns0:Root xmlns:ns0="http://someNamespace"> 
    <ns0:Name /> 
    <ns0:ADD /> 
    <ns0:ADD /> 
    <ns0:DELETE /> 
    <ns0:ADD /> 
    <ns0:DELETE /> 
    <ns0:DELETE /> 
</ns0:Root> 

pero no para

<ns0:Root xmlns:ns0="http://someNamespace"> 
    <ns0:ADD /> 
    <ns0:ADD /> 
    <ns0:DELETE /> 
    <ns0:ADD /> 
    <ns0:DELETE /> 
    <ns0:DELETE /> 
</ns0:Root> 

Answer 2

no creo que esto puede hacerse sin la enumeración cada combinación de ADD, DELETE, etc. En general, las listas desordenadas no funcionan bien, ya sea con DTD o sc hemas.

Answer 3

Creo que está buscando el elemento "todos", permite la lista desordenada. Sin embargo, existen restricciones sobre los elementos que puede poner allí. Consulte http://www.w3.org/2005/07/xml-schema-patterns.html#Collection

Answer 4

Puede implementar listas desordenadas utilizando el tipo de secuencia xs:choice.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
<xs:element name="Application"/> 
    <xs:complexType> 
    <xs:element name="NAME"> 
    <xs:sequence> 
    <xs:choice minOccurs="0" maxOccurs="unbounded"> 
     <xs:element name="ADD" type="xs:string"/> 
     <xs:element name="DELETE" type="xs:string"/> 
    </xs:choice> 
    </xs:element> 
    </xs:sequence> 
    </xs:complexType> 
</xs:element> 
</xs:schema> 

De esta manera se restringe al usuario utilizar cualquier etiqueta que quieren dentro del elemento <NAME/> pero les permiten utilizar <ADD/> y <DELETE/> tan a menudo como deseen.

Answer 5

Lamento que haya estado trabajando duro con este problema desde hace 7 años sin respuesta.

Voy a ayudar revisando sus suposiciones.

Al tratar "Nombre" como un dato que debe venir primero, y que requiere que sea un hijo de la Aplicación, y luego, en general, diciendo que no le importa el orden de sus hermanos, está haciendo una situación confusa para ti. ¿Por qué Name es un hermano de ADD y DELETE si sigue reglas diferentes y tiene un propósito diferente? Si tuviera que modelar esto en cualquier otra estructura de datos, no incluiría "Nombre" en una lista de cosas junto con "AGREGAR" y "ELIMINAR". Diría dos cosas: una aplicación tiene un nombre y también una lista de comandos como AGREGAR y ELIMINAR.

Dado que Name es algo especial en comparación con ADD y DELETE, entonces debe modelarse por separado de esas otras etiquetas.

Entonces, puede hacer que Nombre sea un atributo de Aplicación y mantener Agregar y Eliminar como elementos secundarios, o puede mantener Nombre como elemento secundario pero rodear AGREGAR y ELIMINAR con un marcador de posición/agrupación, como Comandos . La etiqueta Commands sería el único hermano de Name.

Aquí hay un esquema que admite el nombre como un atributo, con un número arbitrario de comandos en cualquier orden. "Nombre como Attribute.xsd":

<?xml version="1.0"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <xs:element name="Application" type="Application_Type" /> 
    <xs:complexType name="Application_Type"> 
      <xs:all> 
       <xs:element minOccurs="0" ref="ADD"/> 
       <xs:element minOccurs="0" ref="DELETE"/> 
       <xs:element minOccurs="0" ref="THIRD"/> 
       <xs:element minOccurs="0" ref="FOURTH"/> 
      </xs:all> 
      <xs:attribute name="Name"/> 
    </xs:complexType> 
    <xs:element name="ADD"/> 
    <xs:element name="DELETE"/> 
    <xs:element name="THIRD"/> 
    <xs:element name="FOURTH"/> 
</xs:schema> 

Ejemplo XML:

<?xml version="1.0" encoding="UTF-8"?> 
<Application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="text" xsi:noNamespaceSchemaLocation="Name as Attribute.xsd"> 
    <THIRD>text</THIRD> 
    <ADD>text</ADD> 
    <FOURTH>text</FOURTH> 
    <DELETE>text</DELETE> 
</Application> 

Y es uno con los comandos anidados dentro de una etiqueta de marcador de posición aquí. "Comandos Grouping.xsd":

<?xml version="1.0"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <xs:element name="Application" type="Application_Type"/> 
    <xs:complexType name="Application_Type"> 
     <xs:sequence> 
      <xs:element ref="Name"/> 
      <xs:element name="Commands" type="Commands_Type"/> 
     </xs:sequence> 
    </xs:complexType> 
    <xs:complexType name="Commands_Type"> 
     <xs:all> 
      <xs:element minOccurs="0" ref="ADD"/> 
      <xs:element minOccurs="0" ref="DELETE"/> 
      <xs:element minOccurs="0" ref="THIRD"/> 
      <xs:element minOccurs="0" ref="FOURTH"/> 
     </xs:all> 
    </xs:complexType> 
    <xs:element name="Name"/> 
    <xs:element name="ADD"/> 
    <xs:element name="DELETE"/> 
    <xs:element name="THIRD"/> 
    <xs:element name="FOURTH"/> 
</xs:schema> 

Ejemplo XML:

<?xml version="1.0" encoding="UTF-8"?> 
<Application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Commands Grouping.xsd"> 
    <Name>text</Name> 
    <Commands> 
     <THIRD>text</THIRD> 
     <ADD>text</ADD> 
     <FOURTH>text</FOURTH> 
     <DELETE>text</DELETE> 
    </Commands> 
</Application> 

Una nota acerca de cualquiera de éstos es que los mensajes con comandos de cero son todavía mensaje válido. Quizás está bien, pero si es un problema, tal vez esa validación pertenece a la capa de Aplicación en lugar de a la XSD.