|
| | | 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 12:21:00 PM 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/ ============================================= From noah_mendelsohn@u... Tue Apr 10 18:57:54 2007 Received: from maggie.w3.org ([193.51.208.68]) by frin | |
| | ||||||||
| Company | Legal | Press | Partners | Careers | Sitemap | Contact Us | Altova Blog | Mobile | Full Site | |||
|
