extensibility in XSchema?

[Paul Prescod]

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
working upon)

 * 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.

 Paul Prescod

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.
> 
> Simon?
> 
> > -- 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
http://www.geezjan.org/humor/computers/threes.html

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)