With namespaces in XML 1.0 once you bind a prefix to a namespace using a special xmlns:prefix="namespaceURI" attribute you cannot undeclare the prefix e.g. xmlns:prefix="" is not allowed so a parser should yield a parser error if such a construct occurs. Spidermonkey however does not give a parse error while Rhino does. Test case: var godList = <gods:gods xmlns:gods="http://example.com/2005/05/04/gods"> <god xmlns:god="">Kibo</god> </gods:gods>; print(godList); Spidermonkey's behaviour: loads the file without problems, parses the XML without giving a parse error: js> load('test2005050401.js') <gods:gods xmlns:gods="http://example.com/2005/05/04/gods"> <god xmlns:god="">Kibo</god> </gods:gods> Expected behaviour would be like Rhino's behaviour: js> load('test2005050401.js') js: "C:\SomePath\javascript\test2005050401.js", line 1: uncaught JavaScript runtime exception: TypeError: error: The value of the attribute "prefix="xmlns",localpart="god",rawname="xmlns:god"" is invalid. Prefixed namespace bindings may not be empty.

/cvsroot/mozilla/js/tests/e4x/Namespace/regress-292863.js,v <-- regress-292863.js initial revision: 1.1

Not sure what I (or today's build) is doing wrong, but I don't think I marked the bug assigned.

I believe this bug report is invalid. http://www.w3.org/TR/xml-names11/ does not say that xmlns:...="" is invalid, indeed it seems to allow it.

(In reply to comment #3) > I believe this bug report is invalid. > > http://www.w3.org/TR/xml-names11/ does not say that xmlns:...="" is invalid, > indeed it seems to allow it. But E4X implements XML 1.0 with namespaces and there it is not allowed to "undeclare" a prefix i.e. to use xmlns:prefix="". See <http://www.w3.org/TR/REC-xml-names/#ns-decl> where it says "If the attribute name matches PrefixedAttName, then the NCName gives the namespace prefix, used to associate element and attribute names with the namespace name in the attribute value in the scope of the element to which the declaration is attached. In such declarations, the namespace name may not be empty."

The current test in the test suite actually assumes the correct behavior is no error which is inconsistent with this report. Should I fix the testcase or mark this bug as works for me?

(In reply to comment #5) > The current test in the test suite actually assumes the correct behavior is no > error which is inconsistent with this report. Should I fix the testcase or mark > this bug as works for me? I think that parsing xmlns:pf="" without throwing a parse error is a bug as E4X follows the XML 1.0 and XML 1.0 with namespaces specification and there xmlns:pf="" is not allowed. In my view the test case needs to be fixed if it does not require the parse error to be thrown as the proper outcome of the test.

(In reply to comment #6) > In my view the test case needs to be fixed if it does not require the parse > error to be thrown as the proper outcome of the test. Sorry it took so long. Checking in regress-292863.js; /cvsroot/mozilla/js/tests/e4x/Namespace/regress-292863.js,v <-- regress-292863.js new revision: 1.2; previous revision: 1.1 done

Igor, can you chime in on if this is a real failure or not?

was:E4X; undeclaring namespace prefixes is not allowed in XML 1.0 with namespace but Spidermonkey does not give a parse error adding test to summary for search goodness.

is this related to bug 410740

E4X will be removed again from Spidermonkey (bug 788293)