Re: Why bound prefixes are an anti-pattern in language design

Hello Ian,

Ian Hickson wrote:
> 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"

Here is where I have to stop you I am afraid, I am not talking about 
XML/Namespaces,  I am only talking about prefixing mechanisms to convey 
semantic meaning in a way it was intended by the author.

for example: 
http://microformats.org/wiki/hatom-faq#Why_does_hAtom_use_class_names_with_prefixes

"... since we were reusing the semantics of the IETF Atom standard, we 
very much wanted to reuse the vocabulary as well to minimize confusion 
and mean precisely the same semantics as defined in the Atom RFC 4287, 
and thus a few of the hAtom properties use class names that appear to 
have shared prefixes (entry-title, entry-content, entry-summary) in 
order to literally reuse those terms from the Atom RFC (title, content, 
summary) with the Atom-specific semantics defined therein, rather than 
the generic semantics, e.g. "summary" has a much more general purpose 
semantic that is utilized broadly by multiple microformats."

This is more what I mean by prefixing mechanisms, these kind of 
mechanisms give wider, richer semantic scope than just simple generic 
keywords. In hAtom prefixing works and doesn't cause many issues or 
confusion, sure the question "is that a namespace" comes up and the 
answer is simply no.

consider this example:

<div prefix-entry="http://tools.ietf.org/html/rfc4287#"
       class="hentry">
    <h2 class="entry-title">My foo article</h2>
    <div class="entry-title">Hey this is foo.</div>
</div>

What am I trying to Imply here? is prefix-entry implying a namespace or 
is it just creating a scope for which terms can be used, Is there any 
namespace voodoo going on there? or am I just dropping a hint, or 
reference to where the meaning of these scoped terms are being used?


Best wishes

-- 
Martin McEvoy
http://weborganics.co.uk/

Received on Thursday, 6 August 2009 13:08:10 UTC