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

Re: Permit (greedy) conflicting wildcards

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Thu, 22 Mar 2007 19:55:21 -0000
Message-ID: <003a01c76cbc$0b208300$c900a8c0@Codalogic>
To: <noah_mendelsohn@us.ibm.com>
Cc: <xmlschema-dev@w3.org>

Original Message From: <noah_mendelsohn@us.ibm.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.

If not the default, then what I'm looking for is something like:


which does not conflict with any of the elements that have already been 
defined in the particle (and non-elemental child particles, and parents of 
non-elemental particles etc. etc.)

Is this the concept you dismissed above due to the 80/20 cut?

If I ruled the world, and I could only choose one of the above two mentioned 
options, then I would go for the notQName="##localElements" option.  This is 
because mimicking this with the entity technique you suggest would 
potentially involve dozens of entities (defined miles away from where they 
are actually used - making it buggy to add new elements to a complex type), 
whereas notQname="##defined" requires only one entity.  Indeed, you might 
get finer control using the entity technique rather than using the sweeping 
notQname="##defined" method.

Thanks again,

Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
Received on Thursday, 22 March 2007 19:56:19 UTC

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