Допустимо ли иметь «выбор» элементов «группы» при определении схемы XML (XSD)

Я не эксперт по XML, хотя использую его довольно часто. Это не то, как я обычно делаю такую ​​​​структуру. Я бы предпочел отдельные сложные типы, а не выбор из двух групп (см. самый конец этого ответа).

Я подозреваю, что проблема в том, что ReservationGroup и CancellationGroup начинаются с одного и того же элемента, и в этом случае вы нарушите ограничение компонента схемы: уникальное атрибутирование частиц (ниже).

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-nonambig

Ограничение компонента схемы: уникальная атрибуция частиц

Модель контента должна быть сформирована таким образом, чтобы во время «валидации» последовательности информационных элементов элемента компонент частицы, содержащийся прямо, косвенно или «неявно» в нем, с помощью которого можно попытаться «валидировать» каждый элемент в последовательности, в свою очередь, может быть однозначно определен. без изучения содержимого или атрибутов этого элемента и без какой-либо информации об элементах в оставшейся части последовательности.

Примечание. Это ограничение реконструирует для XML-схемы эквивалентные ограничения [XML 1.0 (Second Edition)] и SGML. Учитывая наличие групп замещения элементов и подстановочных знаков, краткое выражение этого ограничения затруднено, для дальнейшего обсуждения см. Анализ ограничения атрибута уникальной частицы (ненормативное) (§H).

Например, две приведенные ниже группы недопустимы при одном и том же выборе, потому что каждый из их первых элементов является «именем», что означает, что вы не можете определить, на какую группу вы смотрите. Однако если первый элемент ReservationGroup отличается от группы Cancellation (возможно, resDate и cancDate), то это допустимо.

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

Группы, которые не могут сделать законный выбор

<xs:group name="ReservationGroup">
    <xs:sequence>
        <xs:element name="date"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

<xs:group name="CancellationGroup">
    <xs:sequence>
        <xs:element name="date"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

Группы, которые могут сформировать законный выбор

<xs:group name="ReservationGroup">
    <xs:sequence>
        <xs:element name="resDate"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

<xs:group name="CancellationGroup">
    <xs:sequence>
        <xs:element name="cancDate"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

Как я уже упоминал выше, я бы делал такие вещи со сложными типами. Да, это добавляет еще один элемент, но это кажется очевидным, а я люблю очевидность.

<xs:complexType name="HeaderType">
  <xs:sequence>
    <xs:element name="reservation-number" type="ReservationNumberType" minOccurs="1" maxOccurs="1" nillable="false" />
    <xs:choice minOccurs="1" maxOccurs="1">
      <xs:element name="reservation" type="ReservationType" />
      <xs:element name="cancellation" type="CancellationType" />
    </xs:choice>
  </xs:sequence>
</xs:complexType>

да. Это произошло потому, что и ReservationGroup, и CancellationGroup имели один и тот же первый элемент — элемент «тип резервирования» с фиксированным значением «Reservation» в ReservationGroup и «Cancellation» в Cancellationgroup соответственно.

Верно ли это, зависит от содержания групп: если это модельные группы «последовательности» или «выбора», это совершенно законно; Группы моделей «все» более проблематичны и обычно не допускаются в этом случае.