OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Namespaces best practice: managing dialect evolution --

From: "Ian Graham" <igraham@ic-unix.ic.utoronto.ca>
> So, there are strengths in both approaches -- but the real world probably
> lies in between. Has anyone thought through this issue, and determined a
> good strategy to follow?

I think in the long run the best approach would be

 1) The Namespaces spec is updated to include some minor
version number up date (i.e. indicating that there may
be some minor difference in schema without changing
the general semantics of the element) which friendly 
processors would then ignore. 

  The definition of minor would have to be nutted out:
it would have to be something like that
  - no required information items are removed
  - the relative sequence of required items is
    not altered.
  - the general semantics have not changed
I think the XML Schemas "suffixation" idea idea
would be stronger than needed.  If developers knew
that a content model could evolve in certain
ways such that, between variants, the content
model was open w.r.t. non-required elements,
we would have a measure of future-proofing. 

  XML Schemas supports a lot of wildcarding,
substitution and derivation which can help 
managed versions.  But if you tightly control
your content models now, you make it more
difficult to handle version changes later.

2) Schema languages need to build the idea
of variants in. Change should not be a surprise
to anyone.  The only schema languages
with variant support currently AFAIK
is Schematron's phase mechanism
and, to a lesser extent, DTDs (with 

Being able to identify versions (using URLs
or namespaces with minor numbers) and being
able to represent variants within a schema
(e.g. Schematron's phases) would provide
useful primitives for schema management.

Rick Jelliffe