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

Re: Permit (greedy) conflicting wildcards

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Tue, 10 Apr 2007 20:43:19 +0100
Message-ID: <001e01c77ba8$81d91c00$2400a8c0@Codalogic>
To: <noah_mendelsohn@us.ibm.com>
Cc: <xmlschema-dev@w3.org>

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

> Pete Cordell writes:
>> I think it will be possible to find many cases where such an
>> extension does not make sense.  But I also think that it will
>> be possible to find many cases where it does make sense.
> Sure, but you can always allow for it.  For example, you could do:
>        <choice>
>                <element ref="html"/>
>                <any notQname="##defined"/>
>        </choice>

Is this intended to be the syntax for a version 1 schema?  i.e., I design my 
schema thinking that I probably don't want <html> here (otherwise I would 
have put it in more formally), but I'm leaving scope for it in the future by 
putting it into this choice (which as you say, could be a group)?

That would seem very ugly to me.

> Many other strategies are possible.  For example, instead of the ref to
> the HTML element, that could be a reference to a group with a choice of
> several elements.  The point is, if it's in your schema, you tend to know
> about it, and can reference it if you want to allow it.

...Unless you make a mistake in V1, or new use-cases arise.  In my 
experience most schemas are not perfect in their first incarnation. 
Otherwise why would you need a V2?

> Furthermore, nothing requires you to use a NIS wildcard.  You've
> acknowledged it's useful in some cases.  In the others, use something
> else!

I'm not denying that ##defined might be useful to some, although my gut 
feeling is that people will regret using it.

Also, schema permits the design of syntaxes of the form:

                <!-- Do you really want the following to match the WC? -->

It seems inconsistent for the language to permit this design, and yet not 
readily allow an extension to this sort of design.

Perhaps a more fine grained control, e.g. allow something like:

    <any notQname="##locallyDefined  ##globallyDefined  ##ancestorDefined"/>

and then schema authors can pick and choose the exact configuration they 

BTW - Is this what ##defined is currently set to cover; all potential local 
siblings, all global elements, and all ancestors.  What about all possible 
descendents in an instance?


Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
Received on Tuesday, 10 April 2007 19:43:52 UTC

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