W3C home > Mailing lists > Public > public-html@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: Tue, 10 Mar 2009 19:55:05 -0400
Message-ID: <49B6FDD9.40201@mozilla.com>
To: Sam Ruby <rubys@intertwingly.net>
CC: Tim Berners-Lee <timbl@w3.org>, Henri Sivonen <hsivonen@iki.fi>, 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>, Chris Wilson <Chris.Wilson@microsoft.com>
On 3/5/09 10:04 PM, Sam Ruby wrote:
> +cc: Chris Wilson
> Rob Sayre wrote:
>> The biggest problem is that HTML parsers must reparent elements. This
>> would make discerning in-scope namespaces difficult.
> This argument doesn't resonate with me.  If properly spec'ed there 
> certainly would be cases where the answer wasn't obvious; but if the 
> spec simply were to chose one interpretation in such cases, then it 
> doesn't seem to me that it would be difficult to implement to that 
> spec interoperably.

I agree that it is possible to effectively specify something confusing. 
The question is whether the specified behavior will create a prisoner's 
dilemma. If enough users won't understand the specification, and create 
content that unintentionally violates it, that's what will happen. I 
know you are aware of most of these examples, but I'll include them here 
for others:

1.) http://www.flickr.com/photos/richardgiles/109523955/
2.) http://www.feedparser.org
3.) https://bugzilla.mozilla.org/show_bug.cgi?id=174351#c46

4.) https://bugzilla.mozilla.org/show_bug.cgi?id=287793 (feed now 
contains "o:p" in escaped HTML... victory?)


You get the idea.

>> 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.
> html5 permits all sorts of things that isn't permitted in xml.  To my 
> mind the best that one could hope for is a spec that defines a syntax 
> for HTML5 that is a near superset of what xml+xmlns allows.
> I've heard two other arguments that make considerably more sense to 
> me.  One is that adding such support for namespaces would increase 
> computational path length and/or memory requirements, at a time when 
> all browser vendors are attempting to focus on performance 
> improvements.  I doubt that this has been properly benchmarked, but 
> this argument makes some sense to me. 

xmlns is poorly designed in this regard, since an element's prefix can 
be rebound in the very last attribute of said element.  I believe the 
MSXML team showed this to be true. However, it doesn't seem like it 
would be a big deal if normal HTML didn't have to worry about that.

> My read is that if a suitable standard were defined and agreed to, 
> Microsoft would be willing to move in that direction over subsequent 
> releases of IE.  What they would not be willing to do is to have no 
> namespace support at all.  Chris is welcome to correct me here.

I would be interested to see a proposal.

> Anne has sometimes talked about an XHTML5 which was based not on 
> XML1.0 but rather on something he refers to as XML5.
> http://code.google.com/p/xml5/
> http://annevankesteren.nl/2007/10/xml5
> I think that solution merits further exploration. 

I do not want to gate HTML work on revising XML, but I also think that 
proposal is worth exploring.

- Rob
Received on Tuesday, 10 March 2009 23:55:59 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:45 UTC