W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > March 2009

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

From: Rob Sayre <rsayre@mozilla.com>
Date: Thu, 05 Mar 2009 20:40:37 -0500
Message-ID: <im8wlxp95at1kcdg7nos7l3m.1236303638134@email.android.com>
To: Tim Berners-Lee <timbl@w3.org>,Henri Sivonen <hsivonen@iki.fi>
CC: Ben Adida <ben@adida.net>,Julian Reschke <julian.reschke@gmx.de>,Mark Nottingham <mnot@mnot.net>,HTMLWG WG <public-html@w3.org>,RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>,public-xhtml2@w3.org,"www-tag@w3.org WG" <www-tag@w3.org>
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
Received on Friday, 6 March 2009 01:41:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:01 UTC