W3C home > Mailing lists > Public > public-html@w3.org > November 2009

Namespace-aware APIs do not need to suck

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 04 Nov 2009 22:26:55 +0100
Message-ID: <20091104212655.45010@gmx.net>
To: public-html@w3.org
In today's panel it was pointed out that people do not "get" that the real identifier for an element type is a tuple (namespaceURI, localName), and thus URI-based extensibility is a problem.

My experience in other spaces that use URI-based extensibility is that this problem goes away once you use an API that actually takes namespaces into account.

To address the "tuple" problem, a very simple approach is to use the so-called "Clark" notation (<http://www.jclark.com/xml/xmlns.htm>), where the tuple (namespaceURI, localName) is simply replaced by the string

  {namespaceURI}localName
  
Note that a string in Clark notation can always be disambiguated from a string in prefix notation. We took advantage of that in the JCR 2.0 specification where we overloaded the methods that previously took prefixed strings to allow Clark notation as well.

In the Java (!= JS) API world, we also have been successfully using Java interfaces for these kind of interfaces, exposing both the components of the tuple plus the Clark notation, and leaving it to the implementation how to internally represent that.

In the panel it was also pointed out that no proposals have been made to actually enhance DOM L2 with respect to this. On the other hand, it hasn't been exactly clear that the WG actually is interested to pursue this. If we are (unconference session Thursday or Friday), we really should spend some time looking into this. I can't say that I fully understand the restrictions under which we can extend then DOM (IDL?), but I'm certainly willing to contribute.
 
Best regards, Julian
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Received on Wednesday, 4 November 2009 21:27:31 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:02 UTC