[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSchema question
Don Park, Ron Bourret, Don Park: >>> <schema> >>> <!ELEMENT foo (a, b)> >>> </schema> >>> <foo> >>> <a> >>> <b> >>> </foo> >>> <schema> >>> <!ELEMENT foo (a, c)> <!-- redefine foo element's containment >>> rules --> >>> </schema> >>> <foo> >>> <a><c> >>> </foo> > >>Hey! Nice idea! XSchema certainly supports this -- >it's just a bunch of XML > >Thanks. Support is, I suppose, unintentional?;-) Unintentional of course, but very useful and a significant improvement to XSchema. This makes the so-far-nonexistent-but-shortly-to-be-written section 5 much more interesting: 5.0 Connecting XSchemas to XML Documents 5.1 Processing Models 5.2 Processing Instruction We have plenty of room to describe this operation, though I think we'll want to offer both PI syntax for linking external schemas and this inline syntax. If this is too complex, it may get held for 1.1 or 2.0, and I suspect inline processing will be something that is described but not made mandatory. Just including XSchema elements in the document (preferably at the top, right after the document's root element) is a bit tricky, potentially requiring the XSchema to declare and verify itself (I'd just use ANY on that usage to skip a lot of redundant processing). The application would definitely have to be on the lookout for XSchema elements in the XSchema namespace and treat them specially. The application could still be a layer on top of SAX or something similar, but there's a lot of work to do here. Don Park: >You are right but it makes perfect sense for transitory documents which >exists only while it is moving from one place to another. Ability to >redefine default attribute values should be enough of a benefit I think. Ron Bourret: >3) The semantics of how each successive XSchema affects the previous >XSchema are not well-defined (additive? total replacement? partial >replacement?) and probably won't be defined in XSchema 1.0. You are >therefore on your own. For safety's sake, I suggest you treat each >XSchema as a completely new definition of the following elements. We're definitely going to have to come up with a way to address what happens when multiple XSchemas appear in a document. I think it might be worthwhile to include an attribute on the XSchema element that indicates a fresh start or an overwrite. Repeating the whole schema to change an attribute default seems like overkill. How about: <!ATTLIST XSchema AdditiveBehavior (Replace | Overwrite) "Overwrite"> Where Replace cleans the slate and Overwrite writes over previous declarations? This is pretty tricky stuff, though I'd like to see it work... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|