Re: Permit (greedy) conflicting wildcards

----- 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:

<HTML>
        <TABLE>
                <CAPTION>...</CAPTION>
                <TBODY>...</TBODY>
                <!-- Do you really want the following to match the WC? -->
                <HTML>...</HTML>
        </TABLE>

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 
want.

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?

Thanks,

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 Tuesday, 10 April 2007 19:43:52 UTC