W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2001

RE: Formal Description comments

From: Fuchs, Matthew <matthew.fuchs@commerceone.com>
Date: Fri, 20 Apr 2001 10:19:13 -0700
Message-ID: <4C4A7BE77CE1D311A1D200508BA38C1202F355A5@venus.commerceone.com>
To: "'James Clark'" <jjc@jclark.com>
Cc: XML Schema Comments <www-xml-schema-comments@w3.org>

> -----Original Message-----
> From: James Clark [mailto:jjc@jclark.com]
> Sent: Thursday, April 19, 2001 10:00 PM
> To: Fuchs, Matthew
> Cc: XML Schema Comments
> Subject: Re: Formal Description comments
> "Fuchs, Matthew" wrote:
> > > 4. How are substitution groups handled?
> > >
> > 
> > Substitution groups are just the element inheritance hierarchy.
> I don't understand. Could you explain further?  Are you saying that
> substitution groups are already handled by the current XSFD WD?

XSDL has two inheritance hierarchies - one for complex/simpleTypes, and one
for elements.  The complex/simpleType hierarchy is called "type derivation"
and the element hierarchy is called "substitution groups".  For
complex/simpleTypes, a subtype must declare its supertype and its content
must be either an extension/restriction of the content of its base type
(this may be a vacuous extension/restriction).  A supertype can constrol
whether a subtype can be a restriction or an extension.  For elements, a
subelement (in the sense of subtype) must declare its superelement (called
the "head" in the Structures spec) and its type must be in the type
hierarchy of the head's type.  The head can further restrict whether the
type of the subelement can be an extension/restriction of the head's type.
The parallelism must be painful by now.  So substitution groups are type
hierarchies by any commonly accepted definition of type hierarchy (outside
of the context of Part II) and XSDL toplevel elements are types by any
commonly accepted definition of what a type is (outside of the context of
the Part II - which is why I was explicit about complex/simpleType above).

Since a major goal of the formalization is a simpler explanation of the
underlying semantics, we don't use two different names for the same thing.
In MSL, there is an inheritance hierarchy allowed for each type of sort.  So
complex/simpleTypes have their inheritance hierarchy, corresponding to
derivation in Part II, and elements have their derivation hierarchy,
corresponding to substitution groups in Part II.  Since, in MSL, the content
of an element sort is its type, there is a single derivation rule:  a sort,
A, is a valid subtype of another sort, B, if it declares B as its base and
its content is a valid extension/restriction of the content of B.

So yes, substitution group are already handled by the current XSFD WD.

> > > 7. I would suggest using * instead of *:* for consistency 
> with XPath.
> > >
> > 
> > In wildcards?  The issue is a consistent notation for:
> > 1) any namespace, any local name
> > 2) any namespace, fixed local name
> > 3) fixed namespace, any local name
> > 4) fixed namespace, fixed local name
> > *:* is certainly more internally consistent.  I would normally find
> > consistency with XPath to be a compelling counter argument, 
> but in this case
> > the rest of the syntax for expressing wildcards is so 
> un-XPath that I'm not
> > sure anything would be gained.  My coeditors may feel otherwise.
> I don't think the design you have is any more consistent than XPath. 
> It's not simply a matter of
>  fixed v any namespace
> and
>  fixed v any local name
> there's also the distinction between a null/absent and a 
> non-null/absent
> namespace. (I think you need this distinction for ##other in
> anyAttribute as of the PR.) There aren't enough ways of combining "*"
> and ":" to handle all of these combinations.  *:* doesn't seem very
> appropriate to match a name with an absent namespace URI.  The XPath
> usage of * is consistent with the intuition that * matches one or more
> characters of the QName, but there's no QName of the form *:* that
> expaned to a name with an absent namespace URI.

I'll discuss this with my fellow editors.


Received on Friday, 20 April 2001 13:20:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:56 UTC