Skip Menu |
 

This queue is for tickets about the XML-LibXML CPAN distribution.

Report information
The Basics
Id: 11127
Status: rejected
Worked: 40 min
Priority: 0/
Queue: XML-LibXML

People
Owner: pajas [...] matfyz.cz
Requestors: samuli.karkkainen [...] elma.net
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.58
Fixed in: (no value)



Subject: $doc->createElementNS('', 'foo') doesn't create xmlns attribute
Download (untitled) / with headers
text/plain 312b
$doc->createElementNS('', 'foo') should create element <foo xmlns=""> which is useful when default namespace is in force, and needs to be disabled for a subtree. Instead element <foo> is created. This is apparently due to test if ( eURI != NULL && xmlStrlen(eURI)!=0 ) in LibXML.xs:createElementNS.
Although your suggestion was so tempting that I've almost committed it to the CVS, I finally realized that the behavior you suggest is not correct w.r.t DOM data model where belonging to a NS doesn't necessarily mean a NS declaration to be present on the node. After createElementNS('','foo'), one indeed obtains an element which doesn't belong to any namespace, not even to the default one. The fact that xmlns='' is not present on that node has nothing to do with it, at least DOM-wise. It even makes no difference if one attaches such a node to an element which has some default namespace. (But yes, after serialization and parsing, one would obtain a different infoset). After calling createElementNS('','foo'), you should use $element->setNamespace('','') or $element->setNamespace('','',1) to enforce xmnls='' on a node. I'm also fixing lookupNamespaceURI(prefix), so that for empty/undef prefix it returns the default namespace URI as required by the DOM Layer 3 spec. Hence, after attaching a node to a tree, you can check if a default namespace decl is in scope and call setNamespace if needed.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.