XML and namespaces

[=?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?=]

I'm having some issues around namespace handling with XML:

>>> 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<href/>'

Note that the namespace wasn't emitted. If I have PyXML,
xml.dom.ext.Print does emit the namespace:

>>> xml.dom.ext.Print(document)
<?xml version='1.0' encoding='UTF-8'?><href xmlns='DAV:'/>

Is that a limitation in toxml(), or is there an option to make it
include namespaces?

-wsv

 

[uche.ogbuji]

Wilfredo Sánchez Vega:
"""
I'm having some issues around namespace handling with XML:
'<?xml version="1.0" ?>\n<href/>'
"""

I haven't worked with minidom in just about forever, but from what I
can tell this is a serious bug (or at least an appalling mising
feature). I can't find anything in the Element,writexml() method that
deals with namespaces. But I'm just baffled. Is there really any way
such a bug could have gone so long unnoticed in Python and PyXML? I
searched both trackers, and the closest thing I could find was this
from 2002:

http://sourceforge.net/tracker/index.php?func=detail&aid=637355&group_id=6473&atid=106473

Different symptom, but also looks like a case of namespace ignorant
code.

Can anyone who's worked on minidom more recently let me know if I'm
just blind to something?

 

[Roberto De Almeida]

I've found the same bug. This is what I've been doing:

from xml.dom.minidom import Document

try:
from xml.dom.ext import PrettyPrint
except ImportError:
PrettyPrint = None

doc = Document()
...

if PrettyPrint is not None:
PrettyPrint(doc, stream=output, indent=' ')
else:
top_parent.setAttribute("xmlns", xmlns)
output.write(doc.toprettyxml(indent=' '))

 

[A.M. Kuchling]

This call is incorrect; the signature is createElementNS(namespaceURI,
qualifiedName). If you call .createElementNS('whatever', 'DAV:href'),
the output is the expected:
<?xml version="1.0" ?><DAV:href/>

It doesn't look like there's any code in minidom that will
automatically create an 'xmlnsAV="whatever"' attribute for you. Is
this automatic creation an expected behaviour?

(I assume not. Section 1.3.3 of the DOM Level 3 says "Similarly,
creating a node with a namespace prefix and namespace URI, or changing
the namespace prefix of a node, does not result in any addition,
removal, or modification of any special attributes for declaring the
appropriate XML namespaces." So the DOM can create XML documents that
aren't well-formed w.r.t. namespaces, I think.)

--amk

 

[uche.ogbuji]

Quoting Andrew Kuchling:
"""
This call is incorrect; the signature is createElementNS(namespaceURI,
qualifiedName).
"""

Not at all, Andrew. "href" is a valid qname, as is "foo:href". The
prefix is optional in a QName. Here is the correct behavior, taken
from a non-broken DOM library (4Suite's Domlette)
<?xml version="1.0" encoding="UTF-8"?>
<href xmlns="DAV:"/>>>>

"""
If you call .createElementNS('whatever', 'DAV:href'),
the output is the expected:
<?xml version="1.0" ?><DAV:href/>
"""

Oh, no. That is not at all expected. The output should be:

<?xml version="1.0" ?><DAV:href xmlnsAV="whatever"/>

"""
It doesn't look like there's any code in minidom that will
automatically create an 'xmlnsAV="whatever"' attribute for you. Is
this automatic creation an expected behaviour?
"""

Of course. Minidom implements level 2 (thus the "NS" at the end of the
method name), which means that its APIs should all be namespace aware.
The bug is that writexml() and thus toxml() are not so.

"""
(I assume not. Section 1.3.3 of the DOM Level 3 says "Similarly,
creating a node with a namespace prefix and namespace URI, or changing
the namespace prefix of a node, does not result in any addition,
removal, or modification of any special attributes for declaring the
appropriate XML namespaces." So the DOM can create XML documents that
aren't well-formed w.r.t. namespaces, I think.)
"""

Oh no. That only means that namespace declaration attributes are not
created in the DOM data structure. However, output has to fix up
namespaces in .namespaceURI properties as well as directly asserted
"xmlns" attributes. It would be silly for DOM to produce malformed
XML+XMLNS, and of course it is not meant to. The minidom behavior
needs fixing, badly.

 

[A.M. Kuchling]

Of course. Minidom implements level 2 (thus the "NS" at the end of the
method name), which means that its APIs should all be namespace aware.
The bug is that writexml() and thus toxml() are not so.

Hm, OK. Filed as bug #1371937 in the Python bug tracker. Maybe I'll
look at this during the bug day this Sunday.

--amk

 

[Alan Kennedy]

[AMK]

"""
(I assume not. Section 1.3.3 of the DOM Level 3 says "Similarly,
creating a node with a namespace prefix and namespace URI, or changing
the namespace prefix of a node, does not result in any addition,
removal, or modification of any special attributes for declaring the
appropriate XML namespaces." So the DOM can create XML documents that
aren't well-formed w.r.t. namespaces, I think.)
"""
[Uche]
Oh no. That only means that namespace declaration attributes are not
created in the DOM data structure. However, output has to fix up
namespaces in .namespaceURI properties as well as directly asserted
"xmlns" attributes. It would be silly for DOM to produce malformed
XML+XMLNS, and of course it is not meant to. The minidom behavior
needs fixing, badly.

My interpretation of namespace nodes is that the application is
responsible for creating whatever namespace declaration attribute nodes
are required, on the DOM tree.

DOM should not have to imply any attributes on output.

#-=-=-=-=-=-=-=-=-=
import xml.dom
import xml.dom.minidom

DAV_NS_U = "http://webdav.org"

xmldoc = xml.dom.minidom.Document()
xmlroot = xmldoc.createElementNS(DAV_NS_U, "DAV:xpg")
xmlroot.setAttributeNS(xml.dom.XMLNS_NAMESPACE, "xmlnsAV", DAV_NS_U)
xmldoc.appendChild(xmlroot)
print xmldoc.toprettyxml()
#-=-=-=-=-=-=-=-=-=

produces

"""
<?xml version="1.0" ?>
<DAV:xpg xmlnsAV="http://webdav.org"/>
"""

Which is well formed wrt namespaces.

regards,

 

[uche.ogbuji]

Alan Kennedy:
"""

Oh no. That only means that namespace declaration attributes are not
created in the DOM data structure. However, output has to fix up
namespaces in .namespaceURI properties as well as directly asserted
"xmlns" attributes. It would be silly for DOM to produce malformed
XML+XMLNS, and of course it is not meant to. The minidom behavior
needs fixing, badly.

My interpretation of namespace nodes is that the application is
responsible for creating whatever namespace declaration attribute nodes
are required, on the DOM tree.

DOM should not have to imply any attributes on output.
"""

I'm sorry but you're wrong on this. First of all, DOM L2 (the level
minidom targets) does not have the concept of "namespace nodes".
That's XPath. DOM supports two ways of expressing namespace
information. The first way is through the node properties
..namespaceURI, .prefix (for the QName) and .localName. It *also*
supports literal namespace declaration atrributes (the NSDecl
attributes themselves must have a namespace of
"http://www.w3.org/2000/xmlns/"). As if this is not confusing enough
the Level 1 propoerty .nodeName must provide the QName, redundantly.

As a result, you have to perform fix-up to merge properties with
explicit NSDEcl attributes in order to serialize. If it does not do
so, it is losing all the information in namespace properties, and the
resulting output is not the same document that is represented in the
DOM.

Believe me, I've spent many weary hours with all these issues, and
implemented code to deal with the mess multiple times, and I know it
all too painfully well. I wrote Amara largely because I got
irrecoverably sick of DOM's idiosyncracies.

Andrew, for this reason I probably take the initiative to work up a
patch for the issue. I'll do what I can to get to it tomorrow. If you
help me with code review and maybe writing some tests, that would be a
huge help.

 

[and-google]

Of course. Minidom implements level 2 (thus the "NS" at the end of the
method name), which means that its APIs should all be namespace aware.
The bug is that writexml() and thus toxml() are not so.

Not exactly a bug - DOM Level 2 Core 1.1.8p2 explicitly leaves
namespace fixup at the mercy of the application. It's only standardised
as a DOM feature in Level 3, which minidom does not yet claim to
support. It would be a nice feature to add, but it's not entirely
trivial to implement, especially when you can serialize a partial DOM
tree.

Additionally, it might have some compatibility problems with apps that
don't expect namespace declarations to automagically appear. For
example, perhaps, an app dealing with HTML that doesn't want spare
xmlns="http://www.w3.org/1999/xhtml" declarations appearing in every
snippet of serialized output.

So it should probably be optional. In DOM Level 3 (and pxdom) there's a
DOMConfiguration parameter 'namespaces' to control it; perhaps for
minidom an argument to toxml() might be best?

 

[Alan Kennedy]

[[email protected]]
[Alan Kennedy]

My interpretation of namespace nodes is that the application is
responsible for creating whatever namespace declaration attribute nodes
are required, on the DOM tree.

DOM should not have to imply any attributes on output.
[[email protected]]
..... you have to perform fix-up to merge properties with
explicit NSDEcl attributes in order to serialize. If it does not do
so, it is losing all the information in namespace properties, and the
resulting output is not the same document that is represented in the
DOM.

Well, my reading of the DOM L2 spec is such that it does not agree with
the statement above.

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html

Section 1.1.8: XML Namespaces

"""
Namespace validation is not enforced; the DOM application is
responsible. In particular, since the mapping between prefixes and
namespace URIs is not enforced, in general, the resulting document
cannot be serialized naively. For example, applications may have to
declare every namespace in use when serializing a document.
"""

To me, this means that, as AMK originally stated, that DOM L2 is capable
of creating documents that are not well-formed wrt to namespaces, i.e.
"cannot be serialized naively". It is the application authors
responsibility to ensure that their document is well formed.

Also, there is the following important note

"""
Note: In the DOM, all namespace declaration attributes are by definition
bound to the namespace URI: "http://www.w3.org/2000/xmlns/". These are
the attributes whose namespace prefix or qualified name is "xmlns".
"""

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.

regards,

 

[uche.ogbuji]

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:
'<?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]

I wrote:
"""
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.
"""

Of course (FWIW) I meant

element.setAttributeNS(xml.dom.XMLNS_NAMESPACE, "xmlns", "DAV:")

 

[Alan Kennedy]

[[email protected]]

> 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".

I think if we're going to get anywhere in this discussion, we'll have to
stick to the convention that we are dealing with some specific values. I
suggest the following

element_local_name = 'href'
element_ns_prefix = 'DAV'
element_ns_uri = 'somescheme://someuri'

Therefore, in Clark notation, the qualified name of the element in the
OPs example is "{somescheme://someuri}href". (Yes, I know that "DAV:" is
a valid namespace URI. But it's a poor example because it looks like a
namespace prefix, and may be giving rise to some confusion.)

So, to create a namespaced element, we must specify the namespace uri,
the namespace prefix and the element local name, like so

qname = "%s:%s" % (element_ns_prefix, element_local_name)
element = document.createElementNS(element_ns_uri, qname)

Now, if we create, as the OP did, an element with a namespace uri but no
prefix, like so

element = document.createElementNS(element_ns_uri, element_local_name)

that element *cannot* be serialised naively, because the namespace
prefix has not been declared. Yes, the element is correctly scoped to
the element_ns_uri namespace, but it cannot be serialised because
declaration of namespace prefixes is a pre-requisite of the Namespaces
REC. Relevant quotes from the Namespaces REC are

"""
URI references can contain characters not allowed in names, so cannot be
used directly as namespace prefixes. Therefore, the namespace prefix
serves as a proxy for a URI reference. An attribute-based syntax
described below is used to declare the association of the namespace
prefix with a URI reference; software which supports this namespace
proposal must recognize and act on these declarations and prefixes.
"""

and

"""
Namespace Constraint: Prefix Declared
The namespace prefix, unless it is xml or xmlns, must have been declared
in a namespace declaration attribute in either the start-tag of the
element where the prefix is used or in an an ancestor element (i.e. an
element in whose content the prefixed markup occurs).
"""

http://www.w3.org/TR/REC-xml-names/

[[email protected]]

> So you try the tack of invoking "pythonicness". Well I have one for
> ya:
>
> "In the face of ambiguity, refuse the temptation to guess."

Precisely: If the user has created a document that is not namespace
correct, then do not try to guess whether it should be corrected or not:
simply serialize the dud document. If the user wants a namespace
well-formed document, then they are responsible for either ensuring that
the relevant namespaces, prefixes and uris are explicitly declared, or
for explicitly calling some normalization routine that automagically
does that for them.

[[email protected]]

> 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.

I'm not guessing anything: I'm asserting that with DOM Level 2, the user
is expected to manage their own namespace prefix declarations.

DOM L2 states that "Namespace validation is not enforced; the DOM
application is responsible. In particular, since the mapping between
prefixes and namespace URIs is not enforced, in general, the resulting
document cannot be serialized naively."

DOM L3 provides the normalizeNamespaces method, which the user should
have to *explicitly* call in order to make their document namespace
well-formed if it was not already.

http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/namespaces-algorithms.html

The proposal that minidom should automagically fixup namespace
declarations and prefixes on output would leave it compliant with
*neither* DOM L2 or L3.

[[email protected]]

> 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:")

Actually no, that statement produces "AttributeError: 'NoneType' object
has no attribute 'split'". I believe that you're confusing "DAV:" as a
namespace uri with "DAV" as a namespace prefix.

Code for creating the correct prefix declaration is

prefix_decl = "xmlns:%s" % element_ns_prefix
element.setAttributeNS(xml.dom.XMLNS_NAMESPACE, prefix_decl, element_ns_uri)

> 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.

It's not a bug, it doesn't need fixing, minidom is not broken.

Although I am sympathetic to your bewilderment: xml namespaces can be
overly complex when it comes to the nitty, gritty details.

 

[Fredrik Lundh]

Is this automatic creation an expected behaviour?

Of course.

Not exactly a bug /.../ So it should probably be optional.

My interpretation of namespace nodes is that the application is
responsible /.../

I'm sorry but you're wrong on this.

Well, my reading of the DOM L2 spec is such that it does not agree with
the statement above.

It's currently a bug. It needs to be fixed.

It's not a bug, it doesn't need fixing, minidom is not broken.

further p^H^H^H^H^H^H^H^H^H

can anyone perhaps dig up a DOM L2 implementation that's not written
by anyone involved in this thread, and see what it does ?

</F>

 

[Paul Boddie]

can anyone perhaps dig up a DOM L2 implementation that's not written
by anyone involved in this thread, and see what it does ?

Alright. Look away from the wrapper code (which I wrote, and which
doesn't do anything particularly clever) and look at the underlying
libxml2 serialisation behaviour:

import libxml2dom
document = libxml2dom.createDocument("DAV:", "href", None)
print document.toString()

This outputs the following:

<?xml version="1.0"?>
<href xmlns="DAV:"/>

To reproduce the creation of bare Document objects (which I thought
wasn't strictly supported by minidom), we perform some tricks:

document = libxml2dom.createDocument(None, "doc", None)
top = document.xpath("*")[0]
element = document.createElementNS("DAV:", "href")
document.replaceChild(element, top)
print document.toString()

This outputs the following:

<?xml version="1.0"?>
<href xmlns="DAV:"/>

While I can understand the desire to suppress xmlns attribute
generation for certain document types, this is probably only
interesting for legacy XML processors and for HTML. Leaving such
attributes out by default, whilst claiming some kind of "fine print"
standards compliance, is really a recipe for unnecessary user
frustration.

Paul

 

[Alan Kennedy]

[Fredrik Lundh]
[Paul Boddie]

> document = libxml2dom.createDocument(None, "doc", None)
> top = document.xpath("*")[0]
> element = document.createElementNS("DAV:", "href")
> document.replaceChild(element, top)
> print document.toString()
>
> This outputs the following:
>
> <?xml version="1.0"?>
> <href xmlns="DAV:"/>

But that's incorrect. You have now defaulted the namespace to "DAV:" for
every unprefixed element that is a descendant of the href element.

Here is an example

#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
document = libxml2dom.createDocument(None, "doc", None)
top = document.xpath("*")[0]
elem1 = document.createElementNS("DAV:", "href")
document.replaceChild(elem1, top)
elem2 = document.createElementNS(None, "no_ns")
document.childNodes[0].appendChild(elem2)
print document.toString()
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

which produces

"""
<?xml version="1.0"?>
<href xmlns="DAV:"><no_ns/></href>
"""

The defaulting rules of XML namespaces state

"""
5.2 Namespace Defaulting

A default namespace is considered to apply to the element where it is
declared (if that element has no namespace prefix), and to all elements
with no prefix within the content of that element.
"""

http://www.w3.org/TR/REC-xml-names/#defaulting

So although I have explicitly specified no namespace for the no_ns
subelement, it now defaults to the default "DAV:" namespace which has
been declared in the automagically created xmlns attribute. This is
wrong behaviour.

If I want for my sub-element to truly have no namespace, I have to write
it like this

"""
<?xml version="1.0"?>
<myns:href xmlns:myns="DAV:"><no_ns/></myns:href>
"""

[Paul Boddie]

> Leaving such
> attributes out by default, whilst claiming some kind of "fine print"
> standards compliance, is really a recipe for unnecessary user
> frustration.

On the contrary, once you start second guessing the standards and making
guesses about what users are really trying to do, and making decisions
for them, then some people are going to get different behaviour from
what they rightfully expect according to the standard. People whose
expectations match with the guesses made on their behalf will find that
their software is not portable between DOM implementations.

With something as finicky as XML namespaces, you can't just make ad-hoc
decisions as to what the user "really wants". That's why DOM L2 punted
on the whole problem, and left it to DOM L3.

 

[Fredrik Lundh]

Leaving such attributes out by default, whilst claiming some kind of

"fine print" standards compliance, is really a recipe for unnecessary user
frustration.

On the contrary, once you start second guessing the standards and making
guesses about what users are really trying to do, and making decisions
for them, then some people are going to get different behaviour from
what they rightfully expect according to the standard. People whose
expectations match with the guesses made on their behalf will find that
their software is not portable between DOM implementations.

and this hypothetical situation is different from the current situation in
exactly what way?

With something as finicky as XML namespaces, you can't just make ad-hoc
decisions as to what the user "really wants". That's why DOM L2 punted
on the whole problem, and left it to DOM L3.

so L2 is the "we support namespaces, but we don't really support them"
level ?

maybe we could take everyone involved with the DOM design out to the
backyard and beat them with empty PET bottles until they promise never
to touch a computer again ?

</F>

 

[Alan Kennedy]

[Alan Kennedy]
[Fredrik Lundh]

and this hypothetical situation is different from the current situation in
exactly what way?

Hmm, not sure I understand what you're getting at.

If changes are made to minidom that implement non-standard behaviour,
there are two groups of people I'm thinking of

1. The people who expect the standard behaviour, not the modified
behaviour. From these people's POV, the software can then be considered
broken, since it produces different results from what is expected
according to the standard.

2. The people who are ignorant of the decisions made on their behalf,
and assume that they have written correct code. But their code won't
work on other DOM implementations (because the automagic namespace fixup
code isn't present, for example). From these people's POV, the software
can then be considered broken.

[Alan Kennedy]
[Fredrik Lundh]

so L2 is the "we support namespaces, but we don't really support them"
level ?

Well, I read it as "we support namespaces, but only if you know what
you're doing".

[Fredrik Lundh]

maybe we could take everyone involved with the DOM design out to the
backyard and beat them with empty PET bottles until they promise never
to touch a computer again ?

:-D

 

[Fredrik Lundh]

[Fredrik Lundh]

and this hypothetical situation is different from the current situation in
exactly what way?

Hmm, not sure I understand what you're getting at.

If changes are made to minidom that implement non-standard behaviour,
there are two groups of people I'm thinking of

1. The people who expect the standard behaviour, not the modified
behaviour. From these people's POV, the software can then be considered
broken, since it produces different results from what is expected
according to the standard.

2. The people who are ignorant of the decisions made on their behalf,
and assume that they have written correct code. But their code won't
work on other DOM implementations (because the automagic namespace fixup
code isn't present, for example). From these people's POV, the software
can then be considered broken.

my point was that (unless I'm missing something here), there are at least
two widely used implementations (libxml2 and the 4DOM domlette stuff) that
don't interpret the spec in this way.

Well, I read it as "we support namespaces, but only if you know what
you're doing".

or "we support namespaces, but no matter how you interpret the word
'support', we probably mean something else. nyah nyah!"

</F>

 

[uche.ogbuji]

Alan Kennedy
"""
Although I am sympathetic to your bewilderment: xml namespaces can be
overly complex when it comes to the nitty, gritty details.
"""

You're the one who doesn't seem to clearly understand XML namespaces.
It's your position that is bewildering, not XML namespaces (well, they
are confusing, but I have a good handle on all the nuances by now).

Again, no skin off my back here: I write and use tools that are XML
namespaces compliant. It doesn't hurt me that Minidom is not. I was
hoping to help, but again I don't have time for ths argument.