[
Lists Home |
Date Index |
Thread Index
]
I read the TAG postings (which, amazingly enough, were indirectly
started by me ;-) -- Joseph Reagle [2] cross-posted some versioning
questions I'd previously posted on RSS-DEV [1] ).
So, yeah. It's clearly a messy problem.
But it would be nice to have some discussion on this list (or somewhere!)
of practical experience, to know which ways are good - or outrageously
bad.
I can't imagine the company I'm working for is the only one confronting
this problem, and looking for a decent (if admittedly interm) approach.
To summarize what I think I've undersood, we (as in XML developers) can
currently use the following to identify versions:
1. namespaceURI
advantages:
* generally well supported by XML tools
* always present in a document (well, ones that use namespaces,
anyway)
disadvantages:
* changing the URL implies a major, earth-shattering change
* there is no way to indicate minor variations
* most everyone agrees that using nsURIs to mark minor version
changes is a Bad Thing To Do.
2. schemaURIs
advantages:
* more granular than namespace URIs, but related to them, so that
a set of tuples {nsURL, schemaURI} provides a possible signatur
for the version within a given namespace
* tells the receiving application where to find the schema files!
disadvantages:
* no explicit mechanism for providing this information -- can overload
schemaLocation, but semantics are different.
* no explicit 'ordering' of schema URIs -- don't really know
the relationships between different schema versions for a namespace
unless you encode this in the URI (proprietary extension)
* there's no single schema language -- not clear how to handle
the case where one namespace uses XML schema, one RELAX NG, and
the other something else. (not to even talk about having the
schema URIs point to schemas defined using different versions of
XML schema......)
* doesn't support situation where there are namespaces without
normative schemas, but that do have different 'versions'
with somewhat different semantics (real-world: RSS)
* what about potential changes in semantics that don't result in
changes to the schema (I would think, in that case, you should
'rev' the schema URI - even if the schema document doesn't change)
3. version attribute
advantages:
* 'everyone' knows what version means; although there is no
normative definition for this
* don't have to overload URIs with new meaning
* version numbers can provide ordering and sequence information
disadvantages:
* no defined, normative, universal rule for constructing
version numbers (thus not portable)
* no obvious way to relate version numbers to schemas (I would
imagine that an app not understanding a message version may
want to access the schema to find out if it is capable of
processing data with that namespace/version)
So, I'm still left with the feeling that the best version 'signature' is
some set of {nsURI, schemaURI} pairs, although I don't know what happens
if you allow for multiple schema languages in the same context. And I also
agree that overloading schemaLocation with this information -- and using
ad-hoc tricks to encode version 'numbers' in the schema URIs -- are
problems that need to be sorted out.
I also admit that this approach may be entirely bogus ... but I haven't
heard much feedback from anyone confronting this problem directly.
Best --
Ian
On Mon, 30 Sep 2002, Ian Graham wrote:
>
> On Sun, 29 Sep 2002, Dare Obasanjo wrote:
>
> > Sorry to burst the bubble but versioning in XML applications is
> > neither well understood nor a solved problem. My opinion on this is in
> > the TAG archive[0] in a recent thread on the topic[1].
> > Your question seems to mix validating the document interchangeably
> > with performing whatever processing you need to do on the document. If
> > you use xsi:schemaLocation then there isn't a problem for validation
> > since the XML instance tells you where its schema is located. As for
> > whether to use schema locations as a versioning mechanism to tell if
> > you can process the namespace, I'd suggest using version numbers
> > instead. Version numbers are very useful because you can perform
> > comparisons to tell if the schema revision is one your application
> > doesn't know about.
>
> I was kinda expecting bubble bursting, but thanks for the gentle letdown
> ;-)
>
> I see what you mean about mixed roles. I do want each document to contain
> xsi:schemaLocation so that each application knows precisely which
> schema(s) apply. But I also want to have (the potential for) programmatic
> logic in the applications that can make choices about what to do with the
> document, based on the (schema) versions but independent of any formal
> schema processing.
>
> So as per your comment below, we'd already decided to add 'version-like'
> information into the schema URIs (basically a timestamp) to make version
> comparisons easier.
>
> But, as you say, this overloads the meaning of schemaLocation ....
>
> On the other hand, it makes me uncomfortable to have both schema URIs and
> version numbers, in a 1-1 relationship (which we'd need to track new
> versions for each schema). That just seems like unnecessary duplication,
> and moreover just one more thing to go wrong (i.e., version numbers and
> schemas getting out of synch).
>
> Thanks for the references -- I will follow up on the TAG discussions, and
> follow-up tonight if anything else comes to mind.
>
> > For example, application A understands how to process documents with
> > elements from the "http://www.example.org"; namespace in revisions 1.0,
> > 1.1, 2.0 etc. up to version 3.0 of the schema. If elements from that
> > namespace from revision 2.1 or revision 4.7 of the schema show up
> > there is an easy way to know if they can be handled and the code is a
> > lot simpler than switching on URI names.
>
> > Of course, you could structure your schema locations in a manner that
> > allows such comparisons (e.g.
> > "http://www.example.org/2002/09/29/schema.xsd
> > <http://www.example.org/2002/09/29/schema.xsd> " ) and you'd get
> > similar functionality although you would be overloading the meaning of
> > the xsi:schemaLocation attribute which is unwise and should very well
> > documented in your business logic and to all partners involved.
> >
> >
> > [0] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0092.html
> > [1] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0082.html
[1] http://groups.yahoo.com/group/rss-dev/message/3659
[2] http://lists.w3.org/Archives/Public/www-tag/2002Sep/0082.html
|
