Category: Standards

Web and tech standards

Categories
Books HTML5 Writing

Summer roads

I did continue with my effort on the HTML WG, but I no longer feel either comfortable or welcome in the email list, so not sure what I’ll be doing with HTML 5 from this point.

Chances are, I’ll just focus on preparing a couple of Formal Objections, which don’t require any email communication, other than posting a link. I hate pulling out, as I am concerned about the lack of diversity among those making the decisions about HTML5. I’m still concerned, because there is little diversity, and even less empathy, but I’m a chorus of one: it’s not fun to fight battles when no one is covering your back.

On to other things…

I have a new book contract with O’Reilly. I’ll have more on the subject and title at a later time. Both I and my editor, Simon St. Laurent, think it will be a kick ass book. It really has a great table of contents.

I’m still working on my own self-publishing book, but more slowly, to free up time for the O’Reilly book. I also have an article to write for a popular web design site, which I hope to get finished in a few weeks. All this on top of the work I’m still doing at this site, and my books site. Freeing up time is a silver lining for decreasing HTML5 involvement–though Formal Objections can take a considerable amount of time to create. Less time, though, then reading emails about how mean I am to the HTML 5 guys.

I am a bad, bad girl.

To US folks, Happy 4th of July. To everyone else, Happy 4th of July. Maybe some new photos over at MissouriGreen for you all later.

Categories
HTML5 Specs W3C

The “WhatWG’s Mine is Mine” Design Principle kerfuffle

I’m not part of the HTML WG, but still follow along. Enough to see that one of the big ongoing debates lately is about the HTML WG’s Design Principles draft document. There are too many threads to link, but I would suggest the following as good places to start:

I think some people, i.e. Laura and Larry, expect the Design Principles to be used as rules, rather than as means of explaining

My own opinion of the document, and the discussion surrounding the document, is that the HTML WG Design Principles document is imprecise, vague, and vulnerable to use by self-justifying entities—OK, if you just want a fuzzy feel-good document that looks good in the press, but not something you want to see from a formal W3C Note, which is what the Design Principles wants to be…when it grows up. Definitely not something you want to see used to enforce, or justify, design decisions.

There have been numerous objections to the Design Principles document, in the past and in the current debate, not all of which have been addressed. In my opinion, though, what’s more important is that provisions in the HTML WG Design document have been used to shoot down discussion and debate about namespace support in HTML, support for RDFa, and the introduction of the microdata section:

But I don’t want RDFa to hog all of the focus. Other groups and interests have also been gently schooled in the HTML Design Principles:

So, what do we know about the Design Principles? Ian Hickson in the HTML WG mailing list:

I think the text in the Introduction of the editor’s draft of the HTML Design Principles as of rev 1.26 is quite accurate, and that the rest of the text in that document meets the goals set out in the introduction admirably. I think that it is ridiculous to think that language design can ever be based on strict objective rules, and I do not think that the design guidelines claim that this is what is attempted (indeed quite the opposite). In fact, that’s what the term “design principles” means.

Thank you for that clarification, Ian. Oh, Henri, about that DOM Consistency principle you frequently mention…

Categories
HTML5 RDF Specs W3C

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.

Categories
RDF Standards XHTML/HTML

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:

<!DOCTYPE HTML PUBLIC "-//ApTest//DTD HTML4+RDFa 1.0//EN" "http://www3.aptest.com/standards/DTD/html4-rdfa-1.dtd">
<html
xmlns:t="http://test1.org/something/"
xmlns:T="http://test2.org/something/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<head>
<title>Test 0011</title>
</head>
<body>
<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>
</div>
</body>
</html>

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 one; tossing RDFa out in favor of Microdata; creating 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.

updateA new 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.

Categories
HTML5 W3C

Joining the HTML5 Working Group

I should be working on my book, if I don’t want my pitiful little reserve to be sucked dry before I’m finished. At the same time, though, I feel engaged with the discussion about “microdata” et al in relation to the HTML5 working group. And I figure the writing I’m doing providing new use cases and examining the differences between the HTML5 editor’s proposal and RDFa, can be useful to my book. There’s some other stuff happening at the HTML WG related to accessibility I’m also interested in, and I’m keeping a watchful eye on SVG/HTML5.

Sam Ruby has suggested I join the HTML Working group, as an Invited Expert. It doesn’t cost anything, though I am concerned about the time commitment. I’m not a joiner, per se, but I do have strong opinions about certain aspects of the specification. Now if only some big company that isn’t teetering on the edge or ruin would hire me to be their standards wonk.

What? No takers? Afraid of being singed by the Bird?

Wusses.

Anyway, I’ll put in my request to the HTML WG and we’ll see if I’m acceptable to the powers-that-be.