Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

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

Received on Friday, 6 March 2009 00:50:12 UTC