My HTML WG status

I posted about quitting the HTML WG on Twitter, but there’s only so much one can shove into 140 characters. Of course, I realize that most people will probably be uninterested in a longer writing on my reasons, but that’s the advantage of syndication feeds—you can see at a glance whether you want to read beyond the first few sentences of a writing. Or not.

First of all a clarification: I joined the HTML WG once. I quit the HTML WG once. I joined the HTML WG reluctantly, because as I wrote at the time, I’m really not a joiner. I feel I’m best writing in my own space, not participating in a back and forth in email lists; definitely not through quick non-thinking blurbs in an IRC channel, or teleconferences where key players never participate.

I did join, though, and became actively involved. However, I never could figure out the “rules” of the effort, and I found it both discouraging and exhausting. So much so that it drained the energy I needed for the writing I need to do for a living. More importantly, I felt I really wasn’t making a difference, and I’m not sure I was willing to play the game in order to make a difference.

A further point of clarification: My decision to quit did not come about because of any exchange I had yesterday with any person. It was a number of factors that led to my quitting, a primary one being the one I just mentioned, needing to focus on work. I’d already decided to quit before yesterday, but was waiting for a specific thread on RDFa to play out. I will mention, though, that some of the reasons why I’m leaving were echoed in that thread, including the hostility of the WhatWG backchannel IRC, and the lack of respect some members of this group have for members of the HTML WG and other W3C groups.

Some of the the WhatWG members seem to think that I’ve quit the HTML WG more than once, but they are mistaken. I unsubscribed from the WhatWG email lists, because I found the environment hostile. I stopped working on my assessment of metadata use cases, because the HTML5 author, Ian Hickson, suddenly released a new microdata section, changing everything I wanted to write.

I have unsubscribed from the WhatWG mailing list, and that won’t change. I have quit the HTML WG, and I may, but it’s unlikely, rejoin at some later time. But I have not stopped writing about the HTML5 specification. Whether I make a difference or not, my way of “participating”, in the HTML5 effort, and any other, is by writing in this space. And I will continue to do so, in my own time, and in my own way.


What’s shorter than 140 characters?

What can possibly top Twitter and its immediacy, as well as brevity of contact? I think we found out this week, with Google Wave. Tim O’Reilly describes it as what email would be like if invented today. My first reaction, and judging from other responses, is that it’s remarkably similar to Ray Ozzie’s Groove, before Groove became little more than a ghost appendage to Microsoft.

Folks immediately started rumbling about “twitter killer”, but I look at it and see the answer to the question, “What can beat out 140 characters?” The answer is, evidently, echoed keystrokes as people make them.

I watched the presentation video (thank you for that, Google). Technologically, Google Wave is intriguing. What was also intriguing was Google’s strong emphasis on HTML5 during the presentation, including a reference to additions to the HTML5 spec. But the part that caught my attention is that Wave is actually echoing keystrokes. I can imagine the following discussion, happening live:

A: I just saw the demo of Google Wave …

B: Oh, yeah, that was terrific

A:….and it sucked

B: Oh, um, well I thought…

A: You liked it! Are you…

B: …it was innovative

A: …cracked?

Google Wave is ADD heroin.

I was thinking about Google Wave yesterday, as I ran the gauntlet that is known as Watson Street, here in St. Louis. As I dodged little old ladies who pull into the road without looking, and the 30 something guy who cut me off when he should have yielded, or contemplated the new ding in my car from some mother’s precious child opening his or her car door too hard, and too wide, I began to appreciate what Twitter, Google Wave, Blogging, Facebook, and other social media are: real life alternative communities.

Because in real life, we’re all pricks.


A new countdown to DTV

Recovered from the Wayback Machine.

The switch to digital TV within the US will happen in less than three weeks. However, according to the Government run DTV web site, 42% of the TV broadcast market has already made the transition.

If you’re reading this page via the Internet, I’m guessing you’ve already made your DTV switch. However, just in case I’m wrong, or you have family or friends who don’t understand the DTV switch, the FCC has contracted with vendors to provide DTV support centers and events, which can be located in this DTV help center map. There are also DTV converter box coupons still available, though it’s probably too late to get the coupon before the conversion.

As for antennas, based on my own experience, I recommend the Terk HDTVa Indoor Amplified High-Definition Antenna. Once I installed it, I was able to pick up an additional 5 channels, and I’ve had a much more consistent signal from all the channels. It’s one of the larger indoor antennas, but the price is good (I purchased at Amazon, where it’s currently listed for $36.85), as is the performance.

Critters Photography

May 23 at the Zoo

Thoughtful chimp

Amur leopard sleeping

Close up of Amur leopard


A Loose Set of Notes on RDFa, XHTML, and HTML5

There’s been a great deal of discussion about RDFa, HTML5, and microdata the last few days, on email lists and elsewhere. I wanted to write down notes of the discussions here, for future reference. Those working issues with RDFa in Drupal 7 should pay particular attention, but the material is relevant to anyone incorporating RDFa.

Shane McCarron released a proposal for RDFa in HTML4, which is based on creating a DTD that extends support for RDFa in HTML4. He does address some issues related to the differences in how certain data is handled in HTML4 and XHTML, but for the most part, his document refers processing issues to the original RDFaSyntax document.

Philip Taylor responded with some questions, specifically about how xml:lang is handled by HTML5 parsers, as compared to XML parsers. His second concern was how to handle XMLLiteral in HTML5, because the assumption is that RDFa extractors in JavaScript would be getting their data from the DOM, not processing the characters in the page.

“If the object of a triple would be an XMLLiteral, and the input to the processor is not well-formed [XML]” – I don’t understand what that means in an HTML context. Is it meant to mean something like “the bytes in the HTML file that correspond to the contents of the relevant element could be parsed as well-formed XML (modulo various namespace declaration issues)”? If so, that seems impossible to implement. The input to the RDFa processor will most likely be a DOM, possibly manipulated by the DOM APIs rather than coming straight from an HTML parser, so it may never have had a byte representation at all.

There’s a lively little sub-thread related to this one issue, but the one response I’ll focus on is Shane, who replied, RDFa does not pre-suppose a processing model in which there is a DOM. The issue of xml:lang is also still under discussion, but I want to move on to new issues.

While the discussion related to Shane’s document was ongoing, Philip released his own first look at RDFa in HTML5. Concern was immediately expressed about Philip’s copying of some of Shane’s material, in order to create a new processing rule section. The concern wasn’t because of any issue to do with copyright, but the problems that can occur when you have two sets of processing rules for the same data and the same underlying data model. No matter how careful you are, at some point the two are likely to diverge, and the underlying data model corrupted.

Rather than spend time on Philip’s specification directly at this time, I want to focus, instead, on a note he attached to the email entry providing the link to the spec proposal. In it he wrote:

There are several unresolved design issues (e.g. handling of case-sensitivity, use of xmlns:* vs other mechanisms that cause fewer problems, etc) – I haven’t intended to make any decisions on such issues, I’ve just attempted to define the behaviour with sufficient detail that it should make those issues visible.

More on case sensitivity in a moment.

Discussion started a little more slowly for Philip’s document, but is ongoing. In addition, both Philip and Manu Sporney released test suites. Philip’s is focused on highlighting problems when parsing RDFa in HTML as compared to XHTML; The one that Manu posted, created by Shane, focused on a basic set of test cases for RDFa, generally, but migrated into the RDFa in HTML4 document space.

Returning to Philip’s issue with case sensitivity, I took one of Shane’s RDFa in HTML test cases, and the rdfquery JavaScript from Philip’s test suit, and created pages demonstrating the case sensitivity issue. One such is the following:

<title>Test 0011</title>
<div about="">
Author: <span property="dc:creator t:apple T:banana">Albert Einstein</span>
<h2 property="dc:title">E = mc<sup>2</sup>: The Most Urgent Problem of Our Time</h2>

Notice the two namespace declarations, one for “t” and one for “T”. Both are used to provide properties for the object being described in the document: t:apple and T:banana. Parsing the document with a RDFa application that applies XML rules, treats the namespaces, “t” and “T” as two different namespaces. It has no problem with the RDFa annotation.

However, using the rdfquery JavaScript library, which treats “t” and “T” the same because of HTML case insensitivity, an exception results: Malformed CURIE: No namespace binding for T in CURIE T:banana. Stripping away the RDFa aspects, and focusing on the namespaces, you can see how browsers handle namespace case in an HTML document and in a document served up as XHTML. To make matter more interesting, check out the two pages using Opera 10, Firefox 3.5, and the latest Safari. Opera preserves the case, while both Safari and Firefox lowercase the prefix. Even within the HTML world, the browsers handle namespace case in HTML differently. However, all handle the prefixes the same, and correctly in XHTML. So does the rdfquery JavaScript library, as this test page demonstrates.

Returning to the discussion, there is some back and forth on how to handle case sensitivity issues related to HTML, with suggestions varying as widely as: tossing the RDFa in XHTML spec out and creating a new onetossing RDFa out in favor of Microdatacreating a best practices document that details the problem and provides appropriate warnings; creating a new RDFa in HTML document (or modifying existing profile document) specifying that all conforming applications must treat prefix names as case insensitive in HTML, (possibly cross-referencing the RDFa in XHTML document, which allows case sensitive prefixes). I am not in favor of the first two options. I do favor the latter two options, though I think the best practices document should strongly recommend using lowercase prefix names, and definitely not using two prefixes that differ only by case. During the discussion, a new conforming RDFa test case was proposed that tests based on case. This has now started its own discussion.

I think the problem of case and namespace prefixes (not to mention xmlns as compared to XMLNS) is very much an edge issue, not a show stopper. However, until a solution is formalized, be aware that xmlns prefix case is handled differently in XHTML and HTML. Since all things are equal, consider using lowercase prefixes, only, when embedding RDFa (or any other namespace-based functionality). In addition, do not use XMLNS. Ever. If not for yourself, do it for the kittens.

Speaking of RDFa in HTML issues, there is now a new RDFa in HTML issues wiki page. Knock yourselves out.

updatenew version of the RDFa in HTML4 profile has been released. It addresses a some of the concerns expressed earlier, including the issue of case and XMLLiteral. Though HTML5 doesn’t support DTDs, as HTML4 does, the conformance rules should still be good for HTML5.