W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > August 2009

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>
Cc: RDFa Developers <public-rdf-in-xhtml-tf@w3.org>
Message-ID: <Pine.LNX.4.62.0908052219520.18950@hixie.dreamhostps.com>
On Wed, 5 Aug 2009, Martin McEvoy wrote:
> > 
> > (Of course, I personally would strongly argue against any prefix 
> > mechanism. But that's another story.)
> I have never understood your stance on prefixes, to me and many others 
> they are a "feature" of the future web as well as the present, even 
> html5 uses prefixes i.e: data-* so why you think they are OK in some 
> cases and not in others seems a little inconsistent to me but that my 
> own personal view.

My stance is against mechanisms that bind arbitrary strings to other 
arbitrary strings, which can then be used in conjunction with a third set 
of arbitrary strings to form a identifier that is never explicitly stated 
in the source.

data-* isn't such a mechanism, since "data-" isn't explicitly bound to 
anything, and doesn't mean anything but "data-".

I have a problem with mechanisms that separate parts of an identifier for 
a variety of reasons.

Copy-and-paste of the source becomes very brittle when two separate parts 
of a document are needed to make sense of the content. Copy-and-paste is 
how the Web evolved, so I think it is important to keep it functional and 

Prefixes are notoriously hard for authors to understand. As far back as 
2004, Micah wrote "As the author of an O'Reilly book on XForms, I can 
report that 90% of the technical questions from readers involve confusion 
related to namespaces".


Parand Darugar has said similar things: "Experience shows XML namespaces 
can be a common cause of confusion and a major complicating factor in XML 


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

Maciej has also said things to this effect: "Namespaces are an example of 
the Fundamental Software Engineering Error, which is that something too 
terrible to actually use can be fixed by adding a level of indirection. 
Sometimes that is true but software engineers try to do it even when it 
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.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 5 August 2009 22:29:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:03 UTC