As threatened, here are some thoughts on disambiguation as it applies to extensibility in HTML and the Web platform. This, as with all other things on this wiki, is a work in progress.


I gave a talk on this at BarCamp San Diego 5: Extensibility, HTML, and the Web ecosystem.


see also IM with Jed on 8/6/09

Numquam ponenda est pluralitas sine necessitate. (William of Occam, Quaestiones et decisiones in quattuor libros Sententiarum Petri Lombardi (ed. Lugd., 1495), i, dist. 27, qu. 2, K)

To the untrained eye, the class, role (WAI-ARIA), item and itemprop (microdata) attributes all seem to do the same thing: they all provide a mechanism for HTML authors to label certain elements with additional, more specific semantics than the bare element possesses.

Everything should be made as simple as possible, but no simpler. (Albert Einstein, On the Method of Theoretical Physics (1933))

http://esw.w3.org/topic/HTML/history

http://mailman.ic.ac.uk/pipermail/xml-dev/1999-January/008386.html

Prefix-based indirection and URI-based distributed extensibility

Personally, I think @class is sufficient, and new, @class-like attributes (@role, @item, @itemprop) are unnecessary. I think the main argument against using @class for these things--the potential for namespace collisions--is a complete and total non-issue. At some point I'll write up my "you don't really need the level of disambiguation you think you need" rant.

I don't understand the Quixotic desire for absolute disambiguation at all costs. After all, at the Web scale and in a copy-paste, view-source world, there's no such thing as absolute disambiguation.

I think we should strive for as much disambiguation as is needed to acheive sensible goals, but no more. With apologies to Daniel Dennett, I’m only interested in the varieties of disambiguation worth wanting. URI-based prefix indirection is overkill.


http://intertwingly.net/blog/2009/04/08/HTML-Reunification#c1239196840

Disambiguation comes to mind.

metacrap


The key word in that sentence is “we”. If you have the cycles to go write each and every last extension, go for it. If not, we need an answer to Julian’s disambiguation point. — Sam, replying to Henri


The TAG, W3C’s group tasked with overseeing the overall architecture of the Web, is (rightly) concerned with how design decisions in HTML affect the rest of the Web stack

Distributed extensibility ends up reducing to a power-struggle between browser vendors who want to dictate what the vocabulary of the Web is—and content creators who do not want to cede this right entirely to the browser.


What distributed extensibility gives us is disambiguation. Julian Reschke, in an Agust 2008 post to public-html

Would we be better off if <canvas> had its Apple origin unambiguosly on it for the rest of the existence of the Web? Would the Web platform be better if it were <apple:canvas xmlns:apple="http://www.apple.com/2004/07/namespaces/webkit/dashboard#"> instead of <canvas>? Henri Sivonen, in his reply to Julian


Ian said,

it uses prefixes, which most authors simply do not understand, and which many implementors end up getting wrong (e.g. SearchMonkey

Shelley replied:

But regardless, the majority of people will include metadata markup by installing a plug-in or module, and making a couple of choices. And if you put together a good ten-minute tutorial for the average developer, they’ll have no problem with "foaf:name".

argumentum ad adminiculum — the tools won’t save us. Ultimately, there isn’t much (if any) difference between the author of a tool that generates markup and someone who authors markup directly. They’re both authors, and they both continually get prefix-based indirection wrong.

As James Graham said, “[E]arly adopters having difficulties is indicative of a feature that will be significantly more problematic when used by the (less well informed/ competent) population of authors as a whole.”

Ultimately it behooves us, as language designers, to make the language as simple to author as possible for the specific use cases at hand.

Prefix-based indirection in URI-based extensibility is

  • much more complex than other disambiguation mechanisms (such as using full URIs, or the reversed-DNS-name thing, or simply choosing Sufficiently Interesting prefixes)

  • increases the likelihood of author error considerably,

  • doesn’t actually provide us with any more disambiguation than is worth wanting anyway.

Laurens Holst, in a reply to Henri, said:

I don’t see any other way to achieve distributed extensibility. Simple prefixes without URIs assigned to them aren’t unique enough. Using only full URIs is not acceptable either; they are so verbose, nobody would use them.


Well, no, the elements won't randomly change their meaning. The only risk is copying and pasting them into a document that doesn't provide namespace definitions for the prefixes. Are you thinking that someone will be using different namespaces but the same prefix? Come on -- do you really think that will happen?

How big a risk is this? I would actually say it's minor. Probably no more of a risk than happened with people making copies of other web page content, and cutting off the end, or forgetting to change all the values once copied.

People can copy and paste JavaScript that references elements with certain identifiers. If those aren't used correctly, the application will also fail. Therefore we should not allow copying and pasting of script? How about CSS, then. Can't copy and paste CSS, because again this action is dependent on another and equal action either in a separate document, or elsewhere in the page.

There is no such thing as risk free copy and paste. And frankly, few people will be doing copying and pasting. Most metadata will probably be added either as part of an underlying tool, like Drupal, or using modules and plug-ins that come with documentation, or insert what's needed dynamically.

-- http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-May/019752.html


I really dont think RDFa will last that long if we persist on using prefixes and xmlns, but maybe that's just me ;)

-- Martin McEvoy http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Jul/0165.html

Maciej on prefixes: http://lists.w3.org/Archives/Public/public-html/2009Jul/0919.html

Maciej on CSS/class="" indirection: http://lists.w3.org/Archives/Public/public-html/2009Aug/0000.html

Hixie on prefix-based indirection: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Aug/0035.html and http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Aug/0055.html

mnot on extensibility http://www.mnot.net/blog/2006/04/07/extensibility via jeremy http://adactio.tumblr.com/post/156764403/what-i-found-interesting-about-html-extensibility

lessons of the web http://www.soundadvice.id.au/blog/2007/06/10/#lessonsOfTheWeb via jeremy http://adactio.tumblr.com/post/156762192/the-reason-for-the-success-of-the-web-is-that-a


http://lists.w3.org/Archives/Public/public-html/2009Oct/0131.html

http://lists.w3.org/Archives/Public/public-html/2009Oct/0141.html



Copyright © 2009 Edward O’Connor. CC BY-SA 3.0.

Local Variables: coding: mule-utf-8 fill-column: 72 sort-fold-case: t End:

changed October 5, 2009