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

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
      
http://trac.webkit.org/changeset/41476/trunk/WebCore/xml/XMLHttpRequest.cpp
      https://bugzilla.mozilla.org/show_bug.cgi?id=174351#c60

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

5.) 
http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2539
6.) 
http://blog.mozilla.com/rob-sayre/2009/02/23/preferred-atom-10-acceptable-rss/
7.) 
http://thresholdstate.com/threshold/4163/rss-feeds-valid-useful-or-accurate

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.

separately:
> 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:57 UTC