On 26 Jun 2008, at 03:07 , Pete Cordell wrote:

>
> - Original Message From: "Michael Kay"
>
>>> Personally I think that, subject to occurrence constraints,
>>> the particle that is currently gobbling up input, should have
>>> priority (i.e. they're greedy).  ...
>>
>> Then I suggest you make the suggestion as a comment on the last  
>> call spec
>> which has just been published.
>
> I'll do that then.  In the mean time, if any one wants to share  
> with me why they think the current XSD 1.1 rules are preferable I'd  
> interested to hear it.

The 'weak wildcard' rule caters to the design idiom in which
explicit element declarations are used for the elements which
a processor semantically aware of the vocabulary being defined
is expected to understand and process, and wildcards are used
to allow extension, or to allow the occurrence of semantically
negligeable elements.

For example, to take an example beloved of David Orchard, suppose
you have a v1 type for personal names with the structure

   <complexType name="person-name">
     <sequence>
       <element ref="tns:first-name"/>
       <element ref="tns:middle-name" minOccurs="0"/>
       <element ref="tns:last-name"/>
     </sequence>
   </complexType>

and you wish to allow for unexpected elements before or between the
known elements.  Weakening the wildcards allows the content model
to be written

   <complexType name="person-name">
     <sequence>
       <any minOccurs="0" maxOccurs="unbounded"/>
       <element ref="tns:first-name"/>
       <any minOccurs="0" maxOccurs="unbounded"/>
       <sequence minOccurs="0">
         <element ref="tns:middle-name"/>
         <any minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
       <element ref="tns:last-name"/>
       <any minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
   </complexType>

instead of the somewhat more cumbersome

   <complexType name="person-name">
     <sequence>
       <any minOccurs="0" maxOccurs="unbounded" notQName="tns:first- 
name"/>
       <element ref="tns:first-name"/>
       <any minOccurs="0" maxOccurs="unbounded"
         notQName="tns:middle-name tns:last-name"/>
       <sequence minOccurs="0">
         <element ref="tns:middle-name"/>
         <any minOccurs="0" maxOccurs="unbounded" notQName="tns:last- 
name"/>
       </sequence>
       <element ref="tns:last-name"/>
       <any minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
   </complexType>

Of course, there other ways of writing this kind of thing, and one
might argue that some of them are convenient enough that a priority
system based solely on occurrence indicators (min and max occurs,
I mean) could be equally convenient.  Personally, I think giving
priority to element particles over wildcard particles is fairly
intuitive, a simple form of weighted finite-state automaton.  One
could imagine a future schema language in which the schema author
could specify priorities explicitly, as in XSLT.  Since I think
that such a system is compatible with defaults set up as in the
current draft of XSD 1.1, but not compatible or less compatible
with defaults set up depending on occurrence indicators, I think I
have a mild preference for the current XSD 1.1 rules.

This is not, however, to discourage you from raising the issue against
XSD 1.1:  I think raising the issue, and discussing it, is probably a
good thing.

--C. M. Sperberg-McQueen
   W3C






From cmsmcq@a... Tue Jul 01 22:17:52 2008
Received: from [128.30.52.63] (helo=bart.w3.org)
	by frink.w3.org with esmtp (Exim 4.63)