OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] The purpose of a namespace URI is ...

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.


[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



On Sat, Dec 1, 2012 at 4:44 PM, Fraser Goffin <goffinf@gmail.com> wrote:
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

It's a conumdrum.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS