Re: XHR LC comments

* Boris Zbarsky wrote:
>On the server side?

No, I was simply trying to say XHR should not generate output it cannot
parse itself. Either it generates and parses a document, or it neither
generates nor parses a document. If there was a parameter to set, like
LSParser.domConfig.namespaces, to control this, that would be fine, but
I am not suggesting such an addition.

>   var el = doc.createElementNS("ns1", "x:y");
>   el.setAttributeNS("ns2", "x:z", "val");

>Here are the results I see:
>
>   Firefox 3rc1:
>
>     <x:y xmlns:x="ns1" a0:z="val" xmlns:a0="ns2"/>
>
>   Opera 9.25:
>
>     <?xml version="1.0"?><x:y x:z="val" xmlns:x="ns1"/>
>
>   Safari 3.1:
>
>     <x:y x:z="val" />
>
>Ignoring the Safari serialization, which is not in fact ns-wellformed no matter 
>how you slice it, the other two are ns-wellformed XML.  Neither one roundtrips 
>to quite the original document.  Which one is "correct" per the current spec? 

DOM Level 3 Core Appendix B.1 should define how to fix the tree. There
are some imperfections in the other namespace algorithms in the appendix
and it does not say how good the error reporting is, but I believe the
idea is that, either you get an error, or you can serialize the document
without special handling for namespaces. Above Opera's behavior is wrong
since you created an attribute in ns2 but now it's suddenly in ns1. Only
renameNode can cause that.

The behavior of Firefox seems correct to me, except that it does not use
the "ns<index>" pattern to create the new prefix. You picked a document
that cannot exist when building it directly from a plain text document,
so that this does not very strictly speaking roundtrip does not seem an
issue to me.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 19 May 2008 08:24:24 UTC