

Why bound prefixes are an anti-pattern in language design

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 5 Aug 2009 22:28:52 +0000 (UTC)
To: Martin McEvoy <martin@weborganics.co.uk>
Message-ID: <Pine.LNX.4.62.0908052219520.18950@hixie.dreamhostps.com>
On Wed, 5 Aug 2009, Martin McEvoy wrote:
> > 
> > mechanism. But that's another story.)
> own personal view.

My stance is against mechanisms that bind arbitrary strings to other 
of arbitrary strings to form a identifier that is never explicitly stated 
in the source.

anything, and doesn't mean anything but "data-".

a variety of reasons.


report that 90% of the technical questions from readers involve confusion 
related to namespaces".


Parand Darugar has said similar things: "Experience shows XML namespaces 


Fundamentally, prefixes are an indirection model. Indirection models are 
very, very hard for people to understand.

the Fundamental Software Engineering Error, which is that something too 
clearly is not."


Questions about namespaces come up again and again, over many years:


Prefixes are notoriously hard for implementors to get right:


(This covers bugs by such vendors as Sun, Google, Yahoo!, MySpace -- and 
these aren't just bugs that don't affect end-users, like forgetting to 
quote attributes in HTML.)

Prefixes in dynamically changing content are even worse because they 
require than an observing software agent not only track the value that 
they are concerned about, but also all possible ways for the value's 
prefixes to change meaning. So for instance, here:

   <test prefixes="a=http://example.com/">
      <baz content="a:b"/>

...if a software agent wants to see when <baz>'s content="" attribute 
changes to include the value http://example.net/b, he has to not only 
watch the content="" attribute, but also the prefixes="" attribute of all 
ancestor elements up the tree, just in case they redefine the prefix "a" 
to mean "http://example.net/".

Anyway, all this is why I generally think that prefix mechanisms are an 
anti-pattern in language design.

Received on Wednesday, 5 August 2009 22:29:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 5 August 2009 22:29:30 GMT