RE: [xml-dev] To namespace or not to Namespace .... dictionaries are the

I respectfully beg to differ!

Architecturally XSD Schema is lacking a registry and dictionary system. That was a W3C decision. Namespaces attempt to remediate some of the shortcomings that introduces.

With the OASIS CAM approach - you have true content assembly driven from canonical component dictionaries that you can then use structurally to develop your schema. This encourages good data modelling and structure design, it also encourages good naming and design rules practice so you have consistent definitions and reuse.

Each dictionary provides isolation within itself and automatically across dictionaries since you can specify the dictionary::item and context parent/child to denote the specific use reference.

What is more - you can take existing Schema ugly - load those into CAM templates - refactor and rename - merge - and then generate consolidated dictionaries. Whenever you do this it is hugely instructive - even for established standards of sets of industry schema. I'm constantly seeing - "oh we did not realize we had those conflicts and inconsistencies - we need to fix that" or just plain errors (type mismatch with entity name and intended use). Schema is like using a compiler with no type consistency checking and no variable use pattern checking - it assumes you know what you are doing and that what you coded is what you really intended. Once you have consistent dictionaries - then you can compare across dictionaries - and align and reuse. For the OASIS SET work we are defining semantic mechanisms to exploit what canonical dictionaries add to the equation. Using namespaces fixes nothing relating to conflicts - just makes you think it does - e.g. I have nc:PersonDetails and im:PersonDetails - OK - now what are you going to do? Are these the same? If different how do they differ and when do I use one and not the other? Can I setup automated mapping (focus of OASIS SET)?

Canonical XML dictionaries combined with structure blueprint templates and an expander tool are redefining how people build information exchanges for interoperable business information.

BTW - sidebar technical note - the one use of namespaces I do see technically is to embed program directives into XML content streams to allow discreet processing to occur - but is otherwise stripped out and ignored for content purposes e.g.

-------- Original Message --------
Subject: RE: [xml-dev] To namespace or not to Namespace ....
From: "Michael Kay" <mike@saxonica.com>
Date: Wed, April 07, 2010 3:51 pm
To: "'Simon St.Laurent'" <simonstl@simonstl.com>, <liam@w3.org>
Cc: "'David'" <dlee@calldei.com>, <xml-dev@lists.xml.org>

> > If you don't have an ambiguity problem, the complexity of
> namespaces is simply unlikely to give you any benefit.
>
> I'll agree with Liam, to the extent that I'd like to see that
> emblazoned on a brass plaque somewhere in the XML Hall of Fame.
>
> The opening "if" is important, of course.
>

Well, I beg to differ. You may not have an ambiguity problem, but when
someone else tries to use your vocabulary as part of something bigger, they
may have an ambiguity problem. If the designers of the XSLT and XSD
vocabularies had not used namespaces, it would have been difficult or
impossible for someone else coming along later to define a document type in
which both vocabularies coexisted.

So I'd say: if you want to design your vocabulary for longevity and reuse,
put it in a namespace.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay

_______________________________________________________________________

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