英文:
Standard Solution for orderless XSD sequences
问题
我在通过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>
如您所见，这很复杂。我们的用户在手动脚本化或手工编写代码时遇到了很多问题，因为很难记住每个元素的顺序，否则通过moxy解析会失败。我认为这可能是由于xjc在生成的类上添加的@xmlType(propOrder=...)属性造成的。因此，我们的用户不喜欢它，希望更改它，我也不怪他们。
显然，我们不能将<xsd:sequence />替换为<xsd:all />，因为元素频率存在差异。
我开始怀疑问题可能不在于XSD的约束，而可能在于我们对这种配置的整体方法。
基于此，我们是否有考虑过这种问题的标准方法？什么是最合适的解决方案？
英文:
I'm encountering an interesting obstacle when it comes to generating classes through an XSD and reading them through moxy (probably unrelated to the issue). I have an element with several underlying elements, several of which occuring 0 to N times, a couple occuring at most once, and one or two that must always being supplied.
The standard solution for this is through a sequence:
<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>
As you can see - complicated. Our users are having a lot of trouble scripting or writing against our service by hand because it can be hard to remember what order everything must go in that order or else parsing through moxy fails. I believe it's due to the @xmlType(propOrder=...) attribute that xjc slaps on the generated classes. As a result, our users hate it, want it changed, and I don't blame them.
Obviously, we can't replace <xsd:sequence /> with <xsd:all /> because of the variance in element frequency.
I'm starting to suspect that it's not the constraints of the XSD, but possibly in our overall approach to this sort of configuration.
Based on that, is there a standard approach to this sort of problem that we aren't considering? What is the most appropriate solution?
答案1
得分: 0
XSD 1.1 允许 xs:all 具有除了 [0,1] 和 [1,1] 之外的出现限制。
英文:
XSD 1.1 allows xs:all with occurrence limits other than [0,1] and [1,1].
专注分享java语言的经验与见解，让所有开发者获益！
评论