W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2007

Re: Permit (greedy) conflicting wildcards

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 21 Mar 2007 18:35:41 -0400
To: "Pete Cordell" <petexmldev@tech-know-ware.com>
Cc: xmlschema-dev@w3.org
Message-ID: <OF706724E7.7FFC2AF8-ON852572A5.007BE07F-852572A5.007C1E90@lotus.com>

Nobody's making you use any one variant of the wildcard.  When Not In 
Schema (notQname="##defined") is what you want, use that.  If not, you can 
always explicitly list the QNames you want to exclude.  We toyed with 
allowing some reference to a shared list, but it didn't make the 80/20 
cut.  You can, of course, use XML entities to share a list if it's long, 
should you wish to, and if similar wildcards are to appear in many places. 
 In some cases, the automatic exclusion of everything is what you want. 
After all, many languages combine elements from many namespaces, and we 
don't want to put a lot of semantic into which things happen to be 
declared in the same schema document vs. say, an included document or an 
includer document.

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

"Pete Cordell" <petexmldev@tech-know-ware.com>
Sent by: xmlschema-dev-request@w3.org
03/21/2007 12:47 PM
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     <xmlschema-dev@w3.org>
        Subject:        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:

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

then I think, yes it should be.  I don't think there is any difference 
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 
> cases we're discussing:  if the first "middle" name matches an element
> reference particle, and a 2nd matches the wildcard, many APIs will 
> 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 
> model itself that we are likely to propose the notQName="##defined"
> construct (which, by the way, is known informally in the workgroup and 
> some blog postings I think as the "Not In Schema" or NIS wildcard.

Uh oh!  I've now read 
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 
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 
some one forgot about it, but new use-cases have been discovered and 
bits of data need to be made available in different contexts.

It also seems inconsistent with the rest of XSD practice.  XSD allows 
to be multiple complex type elements that contain <name> elements, each 
their own application defined meaning.  Defining notQName="##defined" 
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 
the local scope.  i.e. the wildcard should not match the names of any of 
children of the parent of the wildcard (and any of the childrens' 
substitution group members).

Thanks again,

Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
Received on Wednesday, 21 March 2007 22:36:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:41 UTC