Re: [xml-dev] RE: Namespace use cases

[James Fuller <james.fuller.2007@gmail.com>]

On Fri, Jul 10, 2009 at 2:59 AM, Jim Tivy<jimt@bluestream.com> wrote:
> I would love to hear of some success or horror stories of multi-namespaces
> in authoring content.  Anyone out there doing this in DITA, DocBook, open
> office...

some random general xml namespace thoughts:

* People not understanding them: of this group, non developers e.g.
authors are the issue e.g. spending the cycles to explain to them they
must use them without them really understanding (and lets be honest,
they don't have to understand them). Most developers I have taught get
namespaces after a 'lightbulb' moment which occurs in a time space of
hours/days.

* Pitfalls: whats in the default namespace ? should I use an attribute
or element ? should I embed versioning or any kind of metadata within
namespace URI ? I don't want to sound like an XML Namespace
'apologist' but doesn't every concept have its dark corners and
nuances to trip up on ?

* Doesn't play well with others: the last time I had real issues with
XML namespaces was when I had to use DTD's, those memory are starting
to fade now. Remember the context when XML namespaces were introduced
10 years ago ... there were some compromises to be made but I would
argue that XML Namespaces has performed its primary use case admirably
and have been adopted widely. The proof of this success is that anyone
in this world can create an XML document and know that it won't
collide with anyone else's data ... yes there are caveats with respect
to some corner cases that need fixing but in whole hasn't XML
Namespaces actually been a success (knowing that I am trivializing
some of the details with this last statement leaves a somewhat bitter
taste in my mouth to write that) ?

* Namespace fixup: This is the one (in the light of my ongoing xproc
impl) that causes real pain for me ... as an implementator it can be
almost intractable to work with namespaces when it comes to
manipulating XML and making sure after some process that the XML has
the correct namespace(s) in the right places. We need more libraries
to help in this area.

* Verbosity: Personally (being a Perl programmer in disguise) I enjoy
reducing verbosity in code, but in data I don't care ... there can
never be enough verbosity in data (if its meaningful) which is
probably why I like my namespaces to mean something to me and others.
Some may argue about bloating data formats, etc ... of which most of
the issues can be optimized away.

* Failure of XML Linking: I wonder if we had a wide spread adopted
linking mechanism for XML how this would affect things today ?
Wouldn't the problem of groking multiple namespaces in a single
document be reduced ?

Perhas the real problem is what XML is that its a 'place' where many
people doing may different things interact ... for example, we would
never expect content creators/authors/etc to directly work on binaries
underlying a Relational Database but that's exactly what we do with
XML with a surprising little tooling to add abstraction to ease
comprehension for those creating content.

Ultimately, XML Namespaces are trying to solve a particularly
difficult problem of avoiding collision in a distributed environment
without the need of a central registry.

I think using java namespace mechanism as an example of what is
correct makes me cringe ... I know a few years ago that no one would
have looked at me strange (in the circle I was in) for saying this,
perhaps tooling is so good now that the problem has gone away. I also
think that talking about such mechanisms that work for code may not be
appropriate for data.

I am all for refreshing the concept and taking another look at XML
Namespaces, but I don't share the idea that XML Namespaces are a
failed pillar of the XML pantheon to be fixed/refactored.

Personally I think we need to ensure we fix xml linking first before
retrofitting XML namespaces.

my 2 euro.

Jim Fuller