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:


4.) (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.
> 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:54 UTC