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] namespaces redux (was: Re: [xml-dev] [XML Schema]Here's how to empower instance document authors to create their own rootelement)

On Wed, 2012-10-17 at 09:57 +0100, Andrew Welch wrote:
> I remember when I first had to design some xml and went looking for
> some advice, I think I may have even asked on here... There was pretty
> much zero advice when it came to namespaces - whether to use one, what
> namespace to use, what about versioning, whether to use a prefix etc.

I agree that tutorials and guidelines are useful.


> Supporting multiple namespaces is a real pain... What is the benefit
> at all putting version numbers in a namespace?  (as opposed to just
> using a version attribute on the root element)

In most cases a fixed namespace and a version attribute does seem to be
the best approach - I just don't like saying "never do this" to
something that's legal and may have use cases. I'm OK with saying,
"please don't do this" with something that's officially deprecated, but
that's not the case here.

A namespace indicates who owns a format, so if ownership changes,
sometimes a "v2" namespace becomes appropriate.


> I don't know... I've done several contracts over the last few years
> and you see the same mistakes over and over again.  Some people *hate*
> xml... and they hate it because they struggle with it, and the
> struggle could easily be avoided if only some simple rules were
> followed when deciding on things like namespaces.

The most common reasons I have seen for hating XML - do you have others
to add? that would be interesting - maybe we need a symposium on hating
XML - are
. data binding, where people use XML for serializing objects.
  JSON - one line of code and you have native objects.
  Not messy DOM not-objects with an API from hell.
  XML - depending on language, getting those same not-DOM native objects
  means traversing a tree or using SAX, dozens of lines of code that's
  easy to get wrong.

. DOM - most people using XML are using DOM. Try rewriting:
   for $club in /students/student[@socks = 'black']/clubs/member
   let $id := $club/@id
   return (name, ": ", count(/students/clubs/club[@id = $id]))
  in Java or PHP or Python or JavaScript using the DOM. Or C++ or C if
  you don't mind making your eyes bleed (you can do it in under 100
  lines of C, i expect, checking everything for NULL on the way).

. Culture dissonance: <e>...</e> instead of e { ... } feels like going
  back to the 1960s for anyone brought up on C and its bastard children,
  awk, perl, javascript, c++, css, TeX, all use braces for scope.
  This is part of why relaxng feels more natural than xsd to people
  who write programs in such languages.

Some of these things are pointless to try to address - people will hate
being forced to use a particular language or tool regardless of how
appropriate it is. Some are harder to address than others.

I agree with you that making XML easier to work with does help. Anyone
who has used XML tools to work with RDF/XML knows that if you really
design an XML format with enough passive-aggression and total disregard
for XML tools, you can make life really unpleasant all round :-)

So yes, some "education and outreach" would go a long way.


Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

[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