extensibility in XSchema?
papresco at technologist.com
Fri Jun 26 22:18:49 BST 1998
Re: extensibility, let me suggest:
* XSchema processors are only responsible for checking things that live
in the XSC: namespace.
* Things in other namespaces behave as if they do not exist (this can be
expressed either informally, or formally using some ideas I am still
* The next version of XSC will have a new namespace (and XSC2 prefix) and
XSC processors will ignore the new rules as if they never existed.
Although the pattern/rule model does not magically make versioning and
extensibility a non-issue, I think that it is more forwards-compatible in
the sense that elements from separate namespaces are cleanly separated
from each other. You can still "group" things in the pattern/rule model by
putting them adjacent, if you want. The grouping is just not enforced by
the language syntax. You group what you want when you want.
John Cowan wrote:
> 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
> > satisfying.
> 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.
> Just so.
> > 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;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
Paul Prescod - http://itrc.uwaterloo.ca/~papresco
Three things trust above all else: Your knowledge of your craft
That someone turns a profit, and that you will get the shaft
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