Re: DOM3 Core: changing .prefix of namespace declarations

On Dec 18, 2005, at 3:04 PM, Bjoern Hoehrmann wrote:

>
> Hi,
>
>   http://lists.w3.org/Archives/Public/www-archive/2005Dec/0017.html  
> has
> some observations how FireFox 1.5, Opera9, ASV6, SVG# 0.4, and Batik
> handle changing the .prefix attribute of Attr nodes that are namespace
> declarations. My reading of DOM Level 3 Core is that only FireFox con-
> forms to the specification. I don't think that this behavior is  
> obvious
> though, and it seems the specification should be clarified what is re-
> quired here.
>
> I think DOM Level 3 Core is confusing about the range of checks DOM
> implementations have to perform to prevent states that would render a
> document namespace-illformed, create/setAttributeNS for example  
> prevent
> certain states, but that can be worked around by manipulating .prefix,
> .value, etc. So I'm not really sure whether FireFox's behavior is
> actually desired...

My own recent experience with Batik was very negative.  When I edited  
documents with inkscape and tried to get Batik to accept them, I had  
to remove every xml namespace declaration and prefix use before I  
could get it to work.  I wouldn't therefore even count Batik until it  
can parse XML documents with xml namespace declarations and usages of  
xml:space, for example, in them (and I think there were other things  
broken as well).  I have no experience with ASV6.

Many of the checks done by DOM to make sure namespaces are legal are  
deferred to normalization or serialization.  While there are real  
checks that occur before then to try to keep obvious problems from  
occurring, they are inherently incomplete and only the normalization  
or serialization can finally sort things out by considering things in  
their final context, and the prefix value could wind up getting  
totally ignored.

 From my brief glance at it, I believe the Firefox behavior is  
conformant and conformant is desired.  I believe a serializer or  
normalizer might add back the xmlns attribute because the identity is  
established by the namespaceURI and that particular namespaceURI can  
only be mapped to the xmlns prefix.

I am also happy if this is the worst problem you are having :-),  
because only fundamentally broken code would seem to be performing  
this operation setting the prefix of a reserved namespaceURI to a  
forbidden value to see the differences -- as I mentioned before, I  
have seen much worse problems in the DOM implementations.

Again, I do not find the specification confusing.  I think expecting  
checks to occur that are not specified is what you call confusing.   
The spec seems fairly clear in most cases what checks occur and the  
rest would not occur.

Ray Whitmer
ray@personallegal.net

Received on Monday, 19 December 2005 17:18:00 UTC