[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Versioned Namespaces


Subject: Re: [xsl] Versioned Namespaces
From: Andrew Welch <andrew.j.welch@xxxxxxxxx>
Date: Thu, 15 Jul 2010 10:27:02 +0100

On 15 July 2010 09:58, Andy Chambers <achambers.home@xxxxxxxxx> wrote:
> Hi,
>
> I've developed a small library of re-usable functions for working with
> an clinical data XML standard.  The
> standard has been around for a while now and so there are multiple
> versions of it, each one of which
> has a slightly different namespace
>
> http://www.cdisc.org/ns/odm/v1.2
> http://www.cdisc.org/ns/odm/v1.3
>
> are the two I work with most commonly.
>
> My library was developed against v1.3 and so uses this for the
> namespace but now I need to make it
> work when operating on a v1.2 documents.  Is there a way to do this
> without code duplication?

:)

One of the rules (well... my rules, others disagree) about namespaces
is "choose one that will never change".  You will never need to mix
different versions of the same XML in a single file, so there is no
need to use a different namespace for each version.  And by embedding
versioning information in the namespace, you are not only using it for
something it wasn't intended for, but you make the life of consumers
of that XML much more difficult.

Given you are in this situation, your options are:

- make your code namespace agnostic, by using * instead of a specific
namespace

- modify your code to accept both namespaces

- insert a step in pipeline that converts the XML into a single
version.  If your lib processes v1.3 XML, then you will need a step
that coverts v1.2 docs to v1.3.  Or in your case as its a function
library, you may be able to just add a set of adapter functions.

Either way its a lot of pain that could've been avoided.  As this is
such a common problem, I tried to get a thread going on xml-dev about
coming up with some "golden rules" to follow when choosing a namespace
(such as "choose one that will never change") to avoid the huge
problems this simple decision can cause, but it basically got shouted
down as being futile and too simplistic.

http://markmail.org/message/jk7fvdbebwvmxbzi

and

http://markmail.org/message/jk7fvdbebwvmxbzi#query:+page:1+mid:mr5oxta62xvg3f
dm+state:results



--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/


Current Thread
Keywords
xml