xml-dev - Re: XSchema question

["Simon St.Laurent" <SimonStL@classic.msn.com>]

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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)