An interesting conversation indeed. My understanding was namespaces were to be used as specific pointers. As an example; I have a project at www.mlhim.org using this as the base I add xmlns and then the version of the schema to create the complete namespace for each schema. Examples: xmlns:mlhim2="http://www.mlhim.org/xmlns/mlhim2/2_3_0" xmlns:mlhim2="http://www.mlhim.org/xmlns/mlhim2/2_4_0" xmlns:mlhim2="http://www.mlhim.org/xmlns/mlhim2/2_4_1" [actually 2.4.1 will be released this coming week] are all three active versions of this reference model schema. Though they are essentially the same schema. Small changes to improve usability etc. were made in each version. There are constraint schemas developed against them and they will always exist as they were initially created, representing healthcare concepts. Once there are constraint schemas (Concept Constraint Definitions or CCDs) built against them and there is instance data against those CCDs. They must remain there forever in order to provide the syntax and semantics for the instance data, where ever that instance data exists. I cannot decide from the conversation if this is considered best practice or not. I had at one time thought to use xmlns:mlhim2=" http://www.mlhim.org/xmlns/mlhim2" in parallel with the versioned ones above but that is not functional as far as I can tell since the CCD needs to always know where the reference model schema it was built against exists. Thoughts? Thanks, Tim
David you may very well be right, but on a practical level, it is more
likely that due to a change in pure *syntax*, for example wanting an
existing complexType to have a new mandatory element, a change of the
namespace may be necessary to clearly signal that break. I'm not
saying that's right, I'm just saying that whilst a new namespace may
at one level create a new language, if it substantially inherits it's
semantics from the previous version but because of a practical issue
can't really maintain the same namespace ....
That's why I said earlier that a data model can be 'damaged' because
of the 'leakage' of shortcomings of the language used to express it.
Whilst we could philosophically satisfy ourselves that if implementers
followed a particular approach to processing messages using that
language the problem wouldn't exist, again, reality would suggest that
many (perhaps most) don't do that and instead rely on features of 'off
the shelf' processors to do most of the heavy lifting but still
exhibit the processing flaw (e.g. strict XSD validation rather than
'selective/elective').
It's a conumdrum.
Fraser.
On 01/12/2012, David Carlisle <davidc@nag.co.uk> wrote:
> On 30/11/2012 20:22, Fraser Goffin wrote:
>> But isn't it usually the case that you would only change the
>> namespace for a MAJOR version change, and it is this explicit and
>> deliberate breaking change that you are signalling by doing so (ie. a
>> significant change of semantics and sometimes syntax).
>
> Well stronger than that, If you change the namespace you have changed
> the name of every token in the language so it's not a new version it's a
> new language. Sometimes that's what you want to do SGML->XML dsssl to
> xslt etc but if the language is plausibly a new _version_ of an existing
> language it ought to have the same namespace (a policy that isn't always
> followed:-)
>
> David
>
>
>
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php