[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Translating RELAX NG to XSD

• To: "XML Developers' List" <xml-dev@l...>
• Subject: Translating RELAX NG to XSD
• From: James Clark <jjc@j...>
• Date: Sun, 17 Feb 2002 10:07:21 +0700

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

• Prev by Date: Re: Re: Why REST
• Next by Date: Re: Re: Why REST
• Previous by thread: creating a URI class
• Next by thread: Re: Translating RELAX NG to XSD
• Index(es):
  • Date
  • Thread