[
Lists Home |
Date Index |
Thread Index
]
I'm trying to figure out the best approach for converting RELAX NG to
XSD. In many cases, it's fairly obvious. But there's one very common
case for which I'm not clear what the "best" conversion is. Consider
a RELAX NG definition of the form
<define name="x">
<element name="y">...</element>
</define>
There would seem to be a number of different ways to translate this
into XSD.
a) Use an <xs:element> declaration. I see three problems with this:
(i) There could be multiple definitions with the same element
name but different content models, but there can be only
one global element declaration in XSD.
(ii) An including RELAX NG schema might do something like:
<define name="x" combine="choice">
<element name="z">...</element>
</define>
But there's no way in XSD to redefine an <xs:element> to be
an <xs:group>
(iii) RELAX NG requires you to say what elements can occur as
document elements (using <start>). XSD doesn't do this explicitly,
but it seems that one can get a very similar effect by using global
element declarations only for elements that can occur as document
elements. Would this be considered bad practice in the XSD
community?
b) Use an <xs:complexType> containing the body. Don't represent
the element name in the definition. <ref name="x"/> would
turn into <xs:element name="y" type="x"/>. This
will have problems with redefinitions as well.
c) Use an <xs:group>:
<xs:group name="x">
<xs:sequence>
<xs:element name="y">
<xs:complexType>...</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
This seems the closest to the RELAX NG semantics, and would work
best for redefinition, but I have three concerns:
(i) Would this seem too weird for the person reading the XSD, or
is this a common design pattern in XSD?
(ii) 3.8.6 of XSD says "Circular groups are disallowed. That is,
within the {particles} of a group there must not be at any depth a
particle whose {term} is the group itself." Will a case such as
<xs:group name="div">
<xs:sequence>
<xs:element name="div" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:group ref="div"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
violate this constraint? I hope not, because it would make
<xs:group> all but useless in a schema which included recursive
element types. I'm guessing that "at any depth" does not intend
that you look inside element declarations. This seems to be
what the implementations I've tried (SQC, MSXML, MSV, XSV) do.
(iii) What about the "element declarations consistent" constraint?
If I do
<xs:sequence>
<xs:group ref="x"/>
<xs:group ref="x"/>
</xs:sequence>
are there two element declarations or one? Actually, I don't think
I understand the "element declarations consistent" constraint.
Consider:
<xsd:element name="e">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="x" type="xsd:int"/>
<xsd:element name="x" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
This surely cannot be illegal, but I don't see why it doesn't
violate the "element declarations consistent" constraint.
James
|