Re: Best practices: Namespaces, versions and RDDL

[Charles Reitzel <creitzel@mediaone.net>]

This is the web equivalent of DLL hell and has been around for a while.

You have identified the basic approaches: 
1) dependent documents refer to *any* version of a NS 
        e.g. http://examplotron.org/

2) dependent documents refer to *major* version of a NS 
        http://examplotron.org/0/

3) dependent documents refer to *specific* version of a NS
        http://examplotron.org/0/3/

Your compromise approach by depending on the major release, but not hanging up on patch level releases makes sense to me.    Especially for simpler, quick to deploy cases.

The COM solution to this problem isn't bad.   In addition to a version specific name, the provider of a component may register a general name.  Applications are free to request a component implementation by either name.  If the reference is to the version specific name, installation of a new version will not break the old code.  But neither will the component client get any benefit of an update.  Alternatively, clients may request components by the general name and will receive the latest available version.  

This approach is similar to the "latest" and "version-specific" URLs to W3C specs.  Typically, but not always, references between specs use the "latest" URL over the "version-specific".    While not orthodox, I don't see why the same approach couldn't be use for NS URIs.

An important here is that it is up to the -client- to decide the dependency.

RDDL could mediate the use of a version-independent NS - especially if Dublin Core/RDF metadata (version, date) is included.  A version-specific NS URI could resolve directly to the schema.

take it easy,
Charles Reitzel

At 09:25 AM 3/23/01 +0000, David Carlisle wrote:

>> Does it make sense ?
>
>yes, but I think it's a much better policy not to change namespace URI
>on version changes.  For example early XSL(T) drafts had a similar
>policy to the one you describe of adding to a base URI, but fortunately
>they changed that before REC and now have a fixed URI and a separate
>version attribute for version changes.
>
>To a namespace aware processor, if you change the namespace URI you have
>changed the name of _every_ construct in the language.
>
>In most contexts, two languages which do not have a single name in common
>would not be considered versions of each other, but rather two separate
>languages.
>
>Thus I think the rule should be:
>
>If the new system is close enough to the old that you just want to
>increment a version number rather than giving it a different name, use
>the same namespace. 
>
>So in th eyear 2021, MathML version 77 should still use
>http://www.w3.org/1998/Math/MathML, but if then we want to make a clean
>break and have NewMathML version 1 then at that point switch to
>http://www.w3.org/2022/Math/NewMathML
>
>David
> 
>
>_____________________________________________________________________
>This message has been checked for all known viruses by Star Internet delivered
>through the MessageLabs Virus Control Centre. For further information visit
>http://www.star.net.uk/stats.asp
>
>------------------------------------------------------------------
>The xml-dev list is sponsored by XML.org, an initiative of OASIS
><http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: xml-dev-request@lists.xml.org 


take it easy,
Charles Reitzel