extensibility in XSchema?
cowan at locke.ccil.org
Fri Jun 26 19:49:33 BST 1998
Ron Bourret wrote:
> John Cowan wrote:
> > Doc was definitely intended for documentation only. I have thoughts
> > on extensibility, but no time to write them up today: hopefully
> > tomorrow.
> I'm looking forward to hearing your ideas. Extensibility is my greatest area of
> concern in XSchema and, although I've got some ideas, none are wholly
Basically, you raised all the points I was thinking of.
> As I understand it, our current plan for extensibility is that new types of
> constraints (such as data types) can be added to ElementDecl and AttDef as
> standard, optional elements in future versions of XSchema. The standardization
> of such elements is rather critical, as the whole point is to make sure that
> everybody is playing the same game -- without standardization, we will be back
> to where we are today.
> If we want better forward compatibility, we
> can state that XSchema applications should assume that any elements they don't
> recognize are from a future version and should be discarded.)
I think this is apple-pie advice and as such, wise.
> However, I keep having a recurring vision of people being able to add their own
> metadata in addition to that which the spec defines and being able to do this
> without changing the DTD -- the same thing that Mark Anderson recently asked
> for. At first, I thought that Paul Prescod's pattern/constraint model would
> magically solve this problem, but after further research, realized that its
> extensibility is almost certainly no different than the current model's -- new,
> optional constraints are added to the DTD over time.
Can't be done if you want XSchemas to be valid. DTDs are just too
restrictive: for validity, all elements and attributes must be declared.
Perhaps the spec should talk about "loose" and "strict" conformance
of a document instance to an XSchema. Loose conformance means
roughly that nothing the XSchema says is disobeyed: if an attribute
is given a type or an element a content model, it must have that type
or model. Strict conformance means further that no elements,
attributes, etc. are used except those mentioned in the
XSchema. Doing that would allow us to say, e.g. that XSchema 2.0
schemas loosely conform to XSchema 1.0 even if they are no longer
valid by the XSchema 1.0 DTD.
> -- If UserSpecific has a content model of ANY, people can then invent their own
> elements. The resulting file is not valid, but will be well-formed. We would
> also need to state that applications that check the XSchema itself would ignore
> the children of UserSpecific.
> -- If UserSpecific has a content model of #PCDATA, people can put whatever
> metadata they want in it. The resulting file is valid, but forces the
> application to parse the PCDATA.
I think that both of these lose, and that UserSpecific is very ugly,
et iterum censeo Carthago delenda est....
John Cowan http://www.ccil.org/~cowan cowan at ccil.org
You tollerday donsk? N. You tolkatiff scowegian? Nn.
You spigotty anglease? Nnn. You phonio saxo? Nnnn.
Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev