Alan Kennedy:
"""
These namespace declaration nodes, i.e. attribute nodes in the
xml.dom.XMLNS_NAMESPACE namespace, are a pre-requisite for any
namespaced DOM document to be well-formed, and thus naively
serializable.
The argument could be made that application authors should be protected
from themselves by having the underlying DOM library automatically
create the relevant namespace nodes.
But to me that's not pythonic: it's implicit, not explicit.
My vote is that the existing xml.dom.minidom behaviour wrt namespace
nodes is correct and should not be changed.
"""
Andrew Clover also suggested an overly-legalistic argument that current
minidom behavior is not a bug.
It's a very strange attitude that because a behavior is not
specifically proscribed in a spec, that it is not a bug. Let me try a
reducto ad absurdum, which I think in this case is a very fair
stratagem. If the code in question:
>>> document = xml.dom.minidom.Document()
>>> element = document.createElementNS("DAV:", "href")
>>> document.appendChild(element)
<DOM Element: href at 0x1443e68>
>>> document.toxml()
'<?xml version="1.0" ?>\n<ferh/>'
(i.e. "ferh" rather than "href"), would you not consider that a minidom
bug?
Now consider that DOM Level 2 does not proscribe such mangling.
Do you still think that's a useful way to determine what is a bug?
The current, erroneous behavior, which you advocate, is of the same
bug. Minidom is an XML Namespaces aware API. In XML Namespaces, the
namespace URI is *part of* the name. No question about it. In Clark
notation the element name that is specified in
element = document.createElementNS("DAV:", "href")
is "{DAV:}href". In Clark notation the element name of the document
element in the created docuent is "href". That is not the name the
user specified. It is a mangled version of it. The mangling is no
better than my reductio of reversing the qname. This is a bug. Simple
as that. WIth this behavior, minidom is an API correct with respect to
XML Namespaces.
So you try the tack of invoking "pythonicness". Well I have one for
ya:
"In the face of ambiguity, refuse the temptation to guess."
You re guessing that explicit XMLNS attributes are the only way the
user means to express namespace information, even though DOM allows
this to be provided through such attributes *or* through namespace
properties. I could easily argue that since these are core properties
in the DOM, that DOM should ignore explicit XMLNS attributes and only
use namespace properties in determining output namespace. You are
guessing that XMLNS attributes (and only those) represent what the user
really means. I would be arguing the same of namespace properties.
The reality is that once the poor user has done:
element = document.createElementNS("DAV:", "href")
They are following DOM specification that they have created an element
in a namespace, and you seem to be arguing that they cannot usefully
have completed their work until they also do:
element.setAttributeNS(xml.dom.XMLNS_NAMESPACE, None, "DAV:")
I'd love to hear how many actual minidom users would agree with you.
It's currently a bug. It needs to be fixed. However, I have no time
for this bewildering fight. If the consensus is to leave minidom the
way it is, I'll just wash my hands of the matter, but I'll be sure to
emphasize heavily to users that minidom is broken with respect to
Namespaces and serialization, and that they abandon it in favor of
third-party tools.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://fourthought.com
http://copia.ogbuji.net http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/
--
http://mail.python.org/mailman/listinfo/python-list
