Re: Best practices: Namespaces, versions and RDDL

[Eric van der Vlist <vdv@dyomedea.com>]

Charles Reitzel wrote:
> 
> 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.

Exactly, and now that I am using it, I see some other benefits in
applying this scheme to the resources associated to the namespace.

For instance, the examplotron compiler can be found at:

http://examplotron.org/compile.xsl (latest release)
http://examplotron.org/0/compile.xsl (latest 0.x release)
http://examplotron.org/0/1/compile.xsl (release 0.1)

As long as I continue to add resources and do not change their names,
this can provide a very coherent way to access to these resources.

The other cool thing that I have found deploying (on Apache) this is
that this can be achieved through some simple rewriting rules and that
the addition of a new release is quite easy.

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

In my case, the namespace URIs do point on RDDL documents that have an
"history" section.

This section is not yet RDDL "enabled", but I'll update it defining the
different releases mentioned in this section as RDDL resources and a
RDDL application could find here the information it would need to take
decisions about the versions.

Although these documents are currently written by hand, backing this by
a CVS server could be really handy.

Thanks for your comments!

Eric
 
> take it easy,
> Charles Reitzel
> 
-- 
Rendez-vous à Paris pour net2001.
                         http://www.mynet2001.net/pgmonline2001/it2.html
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------