XSD — как описать неупорядоченный набор типов элементов, где первый элемент должен появиться первым в последовательности?

Если я понимаю ваш запрос, вы правы, единственное, чего вам не хватает, это maxOccurs="unbounded" по вашему выбору.

Я создал следующую схему:

<?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>

И это хорошо сработало для

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

но не для

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

Я думаю, вы ищете элемент «все», он допускает неупорядоченный список. Однако существуют ограничения на элементы, которые вы можете туда поместить. См. http://www.w3.org/2005/07/xml-schema-patterns.html#Collection

Мне жаль, что вы мучаетесь с этой проблемой уже 7 лет без ответа.

Я собираюсь помочь, пересмотрев ваши предположения.

Рассматривая «Имя» как элемент данных, который должен быть первым, и требуя, чтобы он был дочерним элементом приложения, а затем в целом говоря, что вас не волнует порядок его братьев и сестер, вы создаете запутанную ситуацию. для себя. Почему Name является братом ADD и DELETE, если оно следует другим правилам и служит другой цели? Если бы вам пришлось моделировать это в любой другой структуре данных, вы бы не включили «Имя» в список вещей вместе с «ДОБАВИТЬ» и «УДАЛИТЬ». Вы бы сказали две вещи: у приложения есть имя, а также список команд, таких как ADD и DELETE.

Поскольку имя — это особая вещь по сравнению с ADD и DELETE, его следует моделировать отдельно от этих других тегов.

Таким образом, вы можете сделать Name атрибутом Application и оставить Add и Delete в качестве дочерних элементов, или вы можете оставить Name в качестве дочернего элемента, но затем окружить ADD и DELETE тегом-заполнителем/группировкой, таким как Commands. Тег Commands будет единственным братом Name.

Вот схема, поддерживающая Name в качестве атрибута с произвольным количеством команд в любом порядке. «Имя как атрибут.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>

Пример 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>

А вот один с командами, вложенными в тег-заполнитель. "Группировка команд.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>

Пример 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>

Одно замечание по поводу любого из них заключается в том, что сообщения с нулевыми командами по-прежнему являются действительными сообщениями. Возможно, это нормально, но если это проблема, возможно, эта проверка принадлежит прикладному уровню, а не XSD.

Я не верю, что это можно сделать без перечисления всех комбинаций ADD, DELETE и т. д. Вообще говоря, неупорядоченные списки плохо работают ни с DTD, ни со схемами.

Вы можете реализовать ненумерованные списки, используя тип последовательности 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>

Таким образом, вы запрещаете пользователю использовать любой тег внутри элемента <NAME/>, но позволяете ему использовать <ADD/> и <DELETE/> так часто, как он хочет.