[
Lists Home |
Date Index |
Thread Index
]
Andrew,
I particularly liked Dave Orchard's exposition of the problem and the
partial solutions.
In XForms we allowed foreign attributes across the board, added an
<extension> element, and added an attribute mustUnderstand (borrwed from
SOAP) to let document authors express which extensions are required and
which ones are optional. It still doesn't feel right, since the <extension>
element is clunky, and the division line between Schema author and document
author seems inadequate if there are multiple document processing contexts.
The analysis in Dave Orchard's paper shows, however, that nothing (yet)
feels quite right.
I think it really *ought* to be easy to define a language that allows
extensions from other namespaces, specifies where they are allowed, and
maybe even lets you (the Schema author) say something about the extensions
as substitution groups do, but without having to dance through the
minefields of optional elements and sequence limitations. In my non-Xerox
time I am trying to help design a language that allows for future
extensibility, and finding the tools still a bit blunt (http://xdif.org).
Leigh.
-----Original Message-----
From: Andrew Wheeler [mailto:akwheel99@hotmail.com]
Sent: Tuesday, October 26, 2004 11:12 AM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Schema Evolution
...
[3] Providing Compatible Schema Evolution.
http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSche
maEvolution.html
|
