Why bound prefixes are an anti-pattern in language design

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 
easy.

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".

   http://www.w3.org/2004/04/webapps-cdf-ws/papers/verity.html

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

   http://www.ibm.com/developerworks/library/x-abolns.html

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."

   http://krijnhoetmer.nl/irc-logs/whatwg/20080801#l-160

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

   http://lists.xml.org/archives/xml-dev/200502/msg00306.html
   http://lists.xml.org/archives/xml-dev/200808/msg00030.html

Prefixes are notoriously hard for implementors to get right:

   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6475032
   http://dev.ctor.org/soap4r/ticket/179
   http://sourceforge.net/tracker/?func=detail&atid=454391&aid=924041&group_id=48863
   http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009May/0064.html
   http://lists.w3.org/Archives/Public/public-rdfa/2009Mar/0068.html
   http://lists.w3.org/Archives/Public/public-rdfa/2009Mar/0060.html
   http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Mar/0100.html
   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-May/019717.html
   http://www.jenitennison.com/blog/node/104#comment-4957

(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/">
    <foo>
     <bar>
      <baz content="a:b"/>
     </bar>
    </foo>
   </test>

...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