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