[
Lists Home |
Date Index |
Thread Index
]
Hi, I checked this message. I think my write-up is kind of preliminary,
though itdiscusses exactly what Michael said. I think is is important to
understand two different ways of doing subtyping --explicit subtyping and
implicit subtyping. The issues in implicit subtyping are not fully solved.
I will try to upgrade my report at my earliest, but I will encourage you
to read the preliminary version, and please give any comments you may
have.
you may please find the report at
http://www.cs.ucla.edu/~mani/xmlresearch/datamodels/subtyping.doc
(or)
http://www.cs.ucla.edu/~mani/xmlresearch/datamodels/subtyping.pdf
I conjecture this will be an important topic to be discussed and probably
solved in the next few months.
thanks and regards - murali.
On Mon, 8 Jul 2002, Derek Denny-Brown wrote:
> -----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
>
>
|
