On 2009-03 -02, at 01:23, Henri Sivonen wrote:
I'm not suggesting change [to RDFa] for the sake of change. My
interest here is keeping things so that text/html and application/
xhtml+xml can be consumed with a single namespace-aware application-
layer code path using the infoset representation API of the
application developer's choice given a conforming XML+Namespaces
parser for that API and a conforming HTML for that API. That is, I'm
interested in keeping the software architecture for consuming
applications sane. I think language design that implies bad software
architecture can't be good Web Architecture. The single code path
architecture also precludes taking branches on version identifiers
and such.
Concretely, given the software architecture of Validator.nu (which
is SAX2-based and pretty good architecture in the absence of RDFa),
I couldn't add RDFa validation with the xmlns:foo syntax without
either:
1) Resorting to bad software architecture by implementing notably
different above-parser code paths for text/html and XML.
OR
2) Changing text/html parsing to map xmlns:foo to infoset
differently from how already shipped Gecko, Opera and WebKit have
mapped xmlns:foo in text/html to infoset (by considering how they
map to DOM Level 2 and then by applying the DOM Level 3 to infoset
mapping).
Yes, the goal of having one code path on top of a namespace-aware API
is important.
When one has a namespace-aware API, shame not to have the namespaces.
What are the arguments against implementing xmlns: recognition in
*future* HTML5 parsers?
(I can't imagine that there are a lot of people who have accidentally
used the string xmlns: inside attribute names in the past. :)
There would still be a need for kludge code for legacy browsers, but
with time some applications would just propose to work with XHTML and
HTML in newer browsers. (For example, things which need other new
features anyway). Others would keep the kludge code in forever. But
it would be a huge step forward toward solving this issue.
Tim BL
