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

Sorry Ian I wasn't deliberately being cryptic in the last email, 
although reading that to my self again it seems that way...Ill try again

I wrote:
> 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-content">Hey this is foo.</div>
> </div>
>
It gets a bit cryptic from here on.... What I meant was...

All the above example tries to demonstrate  is creating a scope for 
which terms can be used, there Is no namespace voodoo going on, just 
prefixes used in a "meaningful" way, the content of prefix-entry is just 
text that may or may not be referenced sometime later, Its a reference 
to where the meaning of these scoped terms are being used.

Thanks

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

Received on Thursday, 6 August 2009 18:15:35 UTC