RE: Formal Description comments

James,

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

Matthew

> -----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