Re: Permit (greedy) conflicting wildcards

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

> Pete Cordell wrote:
>
>> I think what I want can be more simply stated as, an element information
>
>> item in an instance can not be validated by a wild card if the
> information
>> item's name matches that of an element declaration that corresponds to a
>
>> potential sibling of the information item in an XML instance.
>
> I think I understood that, but I'm not convinced it's what I want when
> writing schemas.  Let's say you're writing an extensible schema for the
> HTML table element.  HTML 4 says it can have (in DTD syntax):
>
>        CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+
>
> Let's say I want to add one of these new wildcards:
>
>        CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+, NewWC*
>
> By your rule, that would disallow:
>
>        <TABLE>
>                <CAPTION>...</CAPTION>
>                <TBODY>...</TBODY>
>                <CAPTION>...</CAPTION>
>        </TABLE>
>
> but would allow:
>
>        <TABLE>
>                <CAPTION>...</CAPTION>
>                <TBODY>...</TBODY>
>                <!-- Do you really want the following to match the WC? -->
>                <HTML>...</HTML>
>        </TABLE>

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.  Elements with names such as <name>, <id>, 
<date>, <width> all spring to mind as examples that could have different 
interpretations based on context.  I don't think the schema spec is in a 
position to make such a judegement for all possible schemas.

> The point of the Not In Schema Wildcard is that you know about things like
> HTML, and if you wanted them, you would have mentioned them explicitly.
> The wildcard is presumably for extensions you've never heard of.

Just because you know of a thing, does not mean that you won't discover new 
use-cases where known constructs will be needed in new locations.  And let's 
face it, schema designers are only human, and do make mistakes.  It would be 
very unfortuneate if the design of schema didn't allow you to correct such 
errors.

> I do
> understand your proposal, I think, but I'm not convinced it gives us what
> we want.

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 10:22:05 UTC