Thanks for the prompt reply Gareth.Well, the schemas are not 100% compatible, that is why I version them. The use case is such that we do not want to convert the data from one version to another. It is for longitudinal healthcare records and this has been (and continues to be) a problem, especially when using SQL databases. The science changes over time but what was recorded at that point in time is what is important; forever. Including the semantic links that are embedded in RDF annotations in the schema.I understand that the URI is the namespace but when I use the same prefix to represent different namespaces, will that cause a problem? One other thing to note is that I use UUIDs for complexType and element names so any combination of prefix:element-name will always be unique, even though the prefix is the same.My question actually comes up because I am using MarkLogic and it won't allow me to define mlhim2 as a QName with two different namespaces. So, maybe it is only a MarkLogic limitation because of the way the database works?--TimOn Thu, Oct 10, 2013 at 4:49 PM, Gareth Oakes <goakes@gpslsolutions.com> wrote:
I'm not exactly sure of your use case so it is hard to comment, but just to be certain:
- Namespace is the URL, not the prefix.
- Prefix is a convenient shorthand for representing a certain namespace.
- Namespaces know nothing of versioning.
So could just as easily make your namespaces "http://apples" and "http://autocannons", bind them to a: and b: respectively then use that as a thought exercise :)If your database queries are not intended to be scoped by version, then you might want to look at your schema versioning scheme. The "semantic versioning" concept might be a good point of reference for that activity, eg. only bump up the version number in the namespace URL if your schema update makes incompatible changes with the previous version of the schema.In the case of incompatible schema updates, you might then want to make a conscious decision to either upgrade the entire database to the new schema or instead update all your query code to handle the new schema version (this second option is what you question in your email below). The easy (and slighty scary) option would be to just ignore namespaces. Hard to recommend an approach without knowing more about the data and application.It does occur to me however that if both the 2.4.1 and 2.4.2 schemas are compatible with each other then it doesn't seem like a great idea to use a different namespace for each version as that will complicate the query code and any other downstream consumers of the XML.Just my 2c anyway, hope that helps?From: "Timothy W. Cook" <tim@mlhim.org>
Date: Thursday, 10 October 2013 8:34 PM
To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Subject: [xml-dev] Namespace Mistake?Hi All,I don't recall my specific reasons now but I have been reusing a namespace prefix in schemas and instance data 'mlhim2' to reference different versions of a schema reference model.For example:xmlns:mlhim2="http://www.mlhim.org/xmlns/mlhim2/2_4_1" in one version of the schema and instance data and then xmlns:mlhim2="http://www.mlhim.org/xmlns/mlhim2/2_4_2" in another version of the schema and instance data.
Now I think this is a mistake when I need to have multiple versions of instance data in a single database and run queries across them.Should I change to start using:xmlns:mlhim241="http://www.mlhim.org/xmlns/mlhim2/2_4_1" and xmlns:mlhim242="http://www.mlhim.org/xmlns/mlhim2/2_4_2"
to be more explicit and avoid any problems?Thanks In Advance,Tim--
MLHIM VIP Signup: http://goo.gl/22B0U
============================================
Timothy Cook, MSc +55 21 94711995
MLHIM http://www.mlhim.org
Like Us on FB: https://www.facebook.com/mlhim2
Circle us on G+: http://goo.gl/44EV5
Google Scholar: http://goo.gl/MMZ1o
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
--
MLHIM VIP Signup: http://goo.gl/22B0U
============================================
Timothy Cook, MSc +55 21 94711995
MLHIM http://www.mlhim.org
Like Us on FB: https://www.facebook.com/mlhim2
Circle us on G+: http://goo.gl/44EV5
Google Scholar: http://goo.gl/MMZ1o
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook