OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: RELAX NG and type derivation [Was:] XQuery and DTD/Schema?

[ Lists Home | Date Index | Thread Index ]
  • To: "Michael Fitzgerald" <mike@wyeast.net>,<xml-dev@lists.xml.org>
  • Subject: RE: RELAX NG and type derivation [Was:] XQuery and DTD/Schema?
  • From: "Derek Denny-Brown" <derekdb@microsoft.com>
  • Date: Mon, 8 Jul 2002 10:06:08 -0700
  • Thread-index: AcIjhxL7aZMRxydGS8yBWAZscAlOKQCeHIr/
  • Thread-topic: RELAX NG and type derivation [Was:] XQuery and DTD/Schema?

-----Original Message----- 
>From: Michael Fitzgerald [mailto:mike@wyeast.net] 
> RELAX NG can do type derivation by restriction, union, and list. In some
> ways, RELAX NG's list type derivation is more powerful that XML Schema's
> derivation.[1] All the facets that are available in XML Schema are available
> in implementations of RELAX NG. In what specific ways does RELAX NG fall
> short in type derivation?

> As for named typing/subtyping in XML Schema, I think Murali Mani's analysis
> is worthy of consideration.[2] There he discusses implicit and explicit
> assignment, subsumption, and even (briefly) an instanceof method a la
> XQuery. RELAX NG does not offer named typing yet, but a proposal is on the
> table to provide it in 2.0.[3] As such it will most probably be presented in
> a module rather than added to the core specification, in keeping with RELAX
> NG's layered approach. I predict it will be a well-reasoned spec that won't
> later invoke pangs of regret and won't be unduly difficult to implement or
> use.

I was not talking about simple-type (as WXS uses the term) derivation.  I was talking about complex type derivation.  The ability to define a type 'book'
<xs:complexType name="book">
    <xs:element name="title" type="xs:string"/>
    <xs:element name="author" type="properName"/>
    <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"/>
    <xs:element ref="chapter" maxOccurs="unbounded"/>
    <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"/>
And then differentiate the sub-types via subtyping.
<xs:element name="referenceBook">
    <xs:complexContent mixed="0">
      <xs:restriction base="book">
          <xs:element name="title" type="xs:string"/>
          <xs:element name="author" type="properName"/>
          <xs:element ref="chapter" maxOccurs="unbounded"/>
          <xs:element name="references" type="sourceReference" minOccurs="0" maxOccurs="unbounded"/>
An application can now unambiguously query whether a given element is of type 'book'.  With RELAX-NG, the closest you can come is to ask if an instance matches 'book', but that in now way unambiguously determines whether it was intended to be considered a type of book or not.
This ability to extend the type model of one schema is one of the core principles behind OOP, and as such is something that people want in a schema language. 
Also note, that I am not even remotely defending WXS as a complete, well-designed, nor elegant spec.  It just is, and it achieves certain things which people wanted.  I am simply arguing that it is not an utter failure, and that there exists nothing which could fully replace it currently.  There is no doubt in my mind that RELAX-NG is a more elegant creation, nor that it could be extended to fill the same role as WXS.  The problem is that WXS is already out there, and a large number of vendors are already committed to it.  If that is not an issue for you, use RELAX-NG.  I would.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS