[
Lists Home |
Date Index |
Thread Index
]
Hi James,
On the technical questions:
> (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.
It don't think the above violates the Model Group Correct constraint;
the constraint is on the content model being defined, not on the types
of the elements that are particles in that content model. The 'at any
level' is referring to sequences inside choices inside sequences etc.,
not the nesting of the elements that make up the schema document.
> (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.
Yes, it's absolutely fine. The Element Declarations Consistent Schema
Component Constraint states that if you have two element declaration
particles in the same content model, and those element declarations
have the same name and target namespace, then they must both have the
same top-level type.
The above is fine because although you have two element declarations
for the same element, they both have the same type (xsd:int). What you
can't do is, for example:
<xsd:element name="e">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="x" type="xsd:int"/>
<xsd:element name="x">
<xsd:simpleType>
<xsd:restriction base="xsd:int" />
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
In general, I agree that the most natural fit for RELAX NG definitions
that contain only elements is with XML Schema groups, mainly because
it prevents clashes with other elements of the same name. The only
exception that has to be made is for the document elements, which have
to be global in XML Schema or there wouldn't be a starting point for
the validation.
On the other hand, as you indicated, global elements are more readable
than groups, and it's not exactly true that they can't be 'redefined'
into a choice group in an including schema - you could use
substitution groups to do roughly that. But you can't redefine global
elements into sequence groups, and the biggest drawback is that you
can't have two global elements of the same name. Perhaps it would be
possible to map to a global element as the first choice, and to a
group if there is already an element of that name (I don't think
mapping to complex types is going to give the flexibility you need).
Of course, even mapping to a group won't necessarily solve all the
problems involved with the differing abilities of RELAX NG and XML
Schema when it comes to redefining schema components. For example, as
I understand it, it would be quite possible with RELAX NG to have a
definition in an including grammar that looked like:
<define name="x" combine="choice">
<attribute name="z">...</attribute>
</define>
But I imagine that you're dealing with that kind of situation
separately anyway.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
