Re: Permit (greedy) conflicting wildcards

Original Message From: <noah_mendelsohn@us....>

Thanks Noah,

> Pete Cordell asks (regarding wildcards):
>
>> What is the justification for the currently specified set of rules?
>
> Imagine a container format like SOAP.  Is it not possible that somewhere
> in the descendents of the body element it should allow the appearance of
> another soap envelope?  The most basic wildcard is therefore one that
> accepts absolutely anything, including instances of elements that are
> declared in the schema.

If you're saying should something like:

    <given>David</given>
    <family>Orchard</family>
    <title>    <!- a new wildcard matching element -->
        <given>Most Honourable</given>
    </title>

then I think, yes it should be.  I don't think there is any difference there 
between what I would like to see and what is in the current spec.

> You can also make the case that it's not entirely unacceptable even in the
> cases we're discussing:  if the first "middle" name matches an element
> reference particle, and a 2nd matches the wildcard, many APIs will expose
> that to the application.  The application can then either ignore it,
> reject it, or give it some meaning as appropriate.  Nonetheless, it was
> because we realized that some users would want more help from the content
> model itself that we are likely to propose the notQName="##defined"
> construct (which, by the way, is known informally in the workgroup and in
> some blog postings I think as the "Not In Schema" or NIS wildcard.

Uh oh!  I've now read 
http://www.pacificspirit.com/blog/2006/04/29/not_in_schema_wildcard
and I'm now worried about notQName="##defined" as well!!!  Blocking any 
element that has been mentioned in a schema anywhere (it's not clear if it's 
just global elements, or all elements actually) seems way too broad.

I have often seen the case where information items used in one place 
subsequently have to be used in another place.  This not necessarily because 
some one forgot about it, but new use-cases have been discovered and similar 
bits of data need to be made available in different contexts.

It also seems inconsistent with the rest of XSD practice.  XSD allows there 
to be multiple complex type elements that contain <name> elements, each with 
their own application defined meaning.  Defining notQName="##defined" would 
mean that a <name> element could be added in any subsequent version (where 
notQName="##defined" the was used).  You'd quickly end up with silly 
scenarios like <name1043>!!!

What's needed is for the wildcard to not match the element names defined in 
the local scope.  i.e. the wildcard should not match the names of any of the 
children of the parent of the wildcard (and any of the childrens' 
substitution group members).

Thanks again,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================

Received on Wednesday, 21 March 2007 16:49:25 UTC