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

The biggest problem is that HTML parsers must reparent elements. This would make discerning in-scope namespaces difficult.

Separately, xmlns forbids elements with undeclared prefixes. Those sorts of restrictions won't fly in HTML as she are spoke. The best one could hope for is a spec that defines an xmlns subset that would work in both HTML and XML.

- Rob


Tim Berners-Lee <timbl@w3.org> wrote:

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