[
Lists Home |
Date Index |
Thread Index
]
You can mimic inheritance with RELAX NG. [1] Also, Murata-san has written a nice vocabulary for OO that can be transformed into RELAX NG with XSLT. [2] For a RELAX NG view on simple vs. multiple inheritance, see James Clark's design paper. [3]
Mike
[1] http://lists.oasis-open.org/archives/relax-ng/200108/msg00107.html
[2] http://www.asahi-net.or.jp/~eb2m-mrt/oo.html
[3] http://www.thaiopensource.com/relaxng/design.html#section:15
> -----Original Message-----
> From: Derek Denny-Brown [mailto:derekdb@microsoft.com]
> Sent: Monday, July 08, 2002 10:06 AM
> To: Michael Fitzgerald; xml-dev@lists.xml.org
> Subject: [xml-dev] RE: 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:sequence>
> <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"/>
> </xs:sequence>
> </xs:complexType>
>
> And then differentiate the sub-types via subtyping.
> <xs:element name="referenceBook">
> <xs:complexType>
> <xs:complexContent mixed="0">
> <xs:restriction base="book">
> <xs:sequence>
> <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"/>
> </xs:sequence>
> </xs:restriction>
> </xs:complexContent>
> </xs:complexType>
> </xs:complexType>
>
> 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.
>
> -derek
>
>
|
