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: Wed, 18 Apr 2001 14:45:21 -0700
Message-ID: <4C4A7BE77CE1D311A1D200508BA38C1202F3559A@venus.commerceone.com>
To: "'James Clark'" <jjc@jclark.com>, XML Schema Comments <www-xml-schema-comments@w3.org>

Thank you for some excellent suggestions for visual appearance.  With
regards to q's 3 - 7, see below.


> -----Original Message-----
> From: James Clark [mailto:jjc@jclark.com]
> Sent: Wednesday, April 18, 2001 12:34 AM
> To: XML Schema Comments
> Subject: Formal Description comments

1 & 2 elided

> 3. In 3.5, it says
> (Shortcoming: we make no further use of attributeGroup or 
> modelGroup in
> this document.)
> This left me wondering. In a content group, can you have a 
> reference to
> an attributeGroup or modelGroup.  I assume yes (given than you use the
> letter x in the production for group).  If so, that seems to 
> capture the
> semantics of attributeGroup or modelGroup, so what exactly is the
> shortcoming referred to in section 3.5.

This is because we haven't worked on including them in the formalization
yet, not because we want to ignore them.

> 4. How are substitution groups handled?

Substitution groups are just the element inheritance hierarchy.

> 5. I don't think the formalization should restrict itself to 
> Schema Part
> 1.  Part 2 also badly needs the same treatment.

The WG is also of this opinion, but one must start somewhere, and doing part
1 is already a significant task.  Personally, I think much of the work on
part 2 should be done by the people working on operators, as they'll be
doing the heaviest thinking on this.  However, I think that the general
framework for how simple types work (facets, unions, list, derivation)
should be included here.  It's just a question of getting it done.

> 6. In general, a group g{1,1} means the same as g. However, this would
> mean that
> <restriction base="int"/>
> and
> <list itemType="int">
>   <minLength value="1"/>
>   <maxLength value="1"/>
> </list>
> were modelled by equivalent simpleType components.  But as 
> far as I can
> tell in Schema Part 2 a list containing just the integer 7 is not the
> same value as the integer 7.

Good point, and one to consider as we start to look at Part 2.  

> 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.
Received on Wednesday, 18 April 2001 17:46:26 UTC

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