Re: reparing XML Namespaces without breaking existing content

HI Norm,

Thanks for the thoughtful reply.

On May 29, 2008, at 1:11 PM, Norman Walsh wrote:

> / Robert J Burns <rob@robburns.com> was heard to say:
> | There has recently been extended discussion of namespaces within the
> | HTML WG and other WGs and I'd like to suggest these are some issues
>
> I think it would be possible to describe a technical middle-ground for
> XML 2.0 and HTML to share a common model for distributed extensibility
> and namespaces. The technical details are tricky, but pale in
> comparison to the social/political details.
>
> It would require two large, robust communities to agree that a
> compromise on core issues is preferable to simply forking the world of
> angle-bracket markup languages.
>
> Personally, I think the world would be vastly better if we could
> arrange for such a compromise to take place, but I don't currently see
> how to get there.

I completely agree with you on these points. I would like to see HTML5  
add namespace support that is compatible with XML Namespaces and to  
some extent compatible with IE 5-7 text/html namespacing mechanism.

> That said, I have concerns about your specific suggestions.
>
> The central feature of your points seems to be the idea that
> unqualified attributes on an element should be treated as though they
> were qualified with the same namespace as their parent.

Indeed that is the gist of the proposal. However, I'm also calling for  
a backwards compatible re-conceptualization of the treatment of those  
attributes as in a null namespace (in other words a coordinated effort  
across namespaces in CSS, XPath, DOM).

> What problem does that solve?

It establishes a one-to-one correspondence between namespace and  
vocabulary. The lack of this one-to-one correspondence creates  
needless additional work for authors and provides no benefit that I  
can see whatsoever.

>
> That's neither backwards nor forwards compatible

My proposal is to make a change that is both backwards and forwards  
compatible. No existing content would break.

> and seems at odds
> with:
>
>  <x:foo bar="1" x:bar="2"/>
>
> which is, though perhaps odd, entirely valid.

It is definitely at odds with that, because although XML Namespaces  
declares that valid, there's this has long been a precedent that there  
should be no two attributes for the same vocabulary on the same  
element. There's no other way to interpret that example than to enable  
this invalid markup (though declared valid in XML Namespaces). That  
construct doesn't help authors because if they do that they now have a  
processing error at the worst and a processing inoperability at best.  
Which value for bar should get passed to the processor for the  
namespace corresponding to the prefix 'x'? Is it '1' or '2'? Why would  
XML Namespaces want to enable that?

Take care,
Rob

Received on Thursday, 29 May 2008 13:50:11 UTC