Re: Permit (greedy) conflicting wildcards

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:

    notQName="##localElements"

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.
--
=============================================
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 Thursday, 22 March 2007 19:56:19 UTC