|
| | | Altova Mailing List Archives>Archive Index >xmlschema-dev Archive Home >Recent entries >Thread Prev - Re: Permit (greedy) conflicting wildcards >Thread Next - Re: Permit (greedy) conflicting wildcards Re: Permit (greedy) conflicting wildcardsTo: <noah_mendelsohn@--.---.---> Date: 4/10/2007 9:43:00 PM
----- 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/
=============================================
From mike@s... Tue Apr 10 20:34:49 2007
Received: from aji.w3.org ([133.27.228.225])
by frink.w3.org with esm | |
| | ||||||||
| Company | Legal | Press | Partners | Careers | Sitemap | Contact Us | Altova Blog | Mobile | Full Site | |||
|
