Стандартное решение для упорядоченных последовательностей XSD - PullRequest
0 голосов
/ 08 апреля 2020

Я сталкиваюсь с интересным препятствием, когда дело доходит до генерации классов с помощью XSD и чтения их с помощью moxy (вероятно, не связанных с проблемой). У меня есть элемент с несколькими базовыми элементами, некоторые из которых встречаются от 0 до N раз, пара встречается не чаще одного раза и один или два всегда должны быть предоставлены.

Стандартное решение для этого - через последовательность :

<xs:complexType name="element1">
    <xs:sequence>
        <xs:element name="element2" type="xs:string" />
        <xs:element name="element3" type="element3Type" minOccurs="0" maxOccurs="unbounded"/>
        <xs:element name="element4" type="xs:boolean" default="false" minOccurs="0" />
        <xs:element name="element5" type="element5Type" minOccurs="0" />
        <xs:element name="element6" type="element6Type" minOccurs="0" />
        <xs:element name="element7" type="element7Type" minOccurs="0" />
        <xs:element name="element8" type="element7Type" minOccurs="0" />

        <xs:element name="element9" minOccurs="0" maxOccurs="1">
            <xs:complexType>
                <xs:sequence>
                    <xs:element name="element10" type="xs:short" />
                    <xs:element name="element11" type="xs:short" />
                    <xs:element name="element12" type="xs:short" />
                    <xs:element name="element13" type="xs:short" />
                </xs:sequence>
            </xs:complexType>
        </xs:element>
        <xs:element name="element14" type="element5Type" minOccurs="0" />

        <xs:element name="element15" type="element7Type" minOccurs="0" />

        <xs:element name="element16" type="element16Type" minOccurs="0"/>
        <xs:element name="element17" type="element16Type" minOccurs="0"/>
    </xs:sequence>
</xs:complexType>

Как видите - сложно. Наши пользователи сталкиваются с большими трудностями при написании сценариев или написании для нашего сервиса вручную, потому что может быть трудно вспомнить, в каком порядке все должно go в этом порядке, иначе анализ через moxy завершится неудачно. Я считаю, это связано с атрибутом @xmlType(propOrder=...), который xj c шлепает по сгенерированным классам. В результате наши пользователи ненавидят это, хотят, чтобы это изменилось, и я не виню их.

Очевидно, что мы не можем заменить <xsd:sequence /> на <xsd:all /> из-за отклонения в частоте элемента.

Я начинаю подозревать, что дело не в ограничениях XSD, а, возможно, в нашем общем подходе к такого рода конфигурации.

Исходя из этого, существует ли стандартный подход к этому виду проблемы, которую мы не рассматриваем? Какое решение является наиболее подходящим?

1 Ответ

0 голосов
/ 08 апреля 2020

XSD 1.1 допускает xs:all с пределами вхождения, отличными от [0,1] и [1,1].

...