R
Racinet Georges
Hi there,
I've got a problem with the way ElementTree 1.3a3-20070912 handles
attributes
with the default namespace feature (please feel free to redirect me if
this isn't the
proper place to discuss such matters).
'<ns0:a xmlns:ns0="foo"><ns0:b id="1" /></ns0:a>'
Notice that the 'id' attribute does not belong to the "foo" namespace.
If I got the XML 1.0 specification right, this is perfectly normal
(Quoting http://www.w3.org/TR/REC-xml-names/#defaulting) :
"Default namespace declarations do not apply directly to attribute
names;
the interpretation of unprefixed attributes is determined by the
element on
which they appear.
(...)
The namespace name for an unprefixed attribute name always has no
value."
Now, trying to serialize this back with the default_namespace feature
of ET 1.3,
I get an error, as predicted by the online documentation
Traceback (...)
ValueError: cannot use non-qualified names with default_namespace option
Since this is a parse/serialize round-trip, I think that this
behaviour isn't right, and that
unprefixed attributes should go through. Actually, shouldn't
attributes even be outside
of the scope of the default namespace feature ?
Is there hope for future improvements about this ?
I saw some FIXME comment in the source. The svn head version (rev 528)
seems to be identical in that respect, by the way.
Removing in ElementTree.py the part where the ValueError is been raised
seems to solve the issue at first sight :<a xmlns="foo"><b id="1" /></a>
but this lets also unprefixed elements go through, which is unwanted:<a xmlns="foo"><b id="1" /></a>
I wouldn't care in my application, whose output is xhtml, though.
Regards,
--
Georges Racinet, http://www.racinet.fr
Zope/CPS/Plone expertise, assistance & development
GPG: 0x4862FFF7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iQEVAwUBSjojWeAffZJiF+Z4AQLzpQf+Jf4meVHd5HsB5/DJRMWdSvIT9eCixYXM
WzzW0uXFtF3cJbKptz/KF+elDAdTWvVS3BMPxR/54/Ggz4ItsUR3iBeeh2tH+sp3
OCskxQCpmXvWg9ZfOON26q3M74tXQMnoc5RoSghdLfE0aElwkQpxJhPaIrQL9+zo
7flFK3cTHcoaOje71m/tN+gA2nK3Tgf3Y2LFYgPbc+hQg9ZhOCQ4TVpIP478hQZY
i5i7S15UZ+Ii0u6XQTHpBchvWdMFiW6jhz353tfeJm6v3tZdN3G6m/GKGMNfb7+K
rbbhbPDqwp0mWGIlL6rLR12BUtV1F4tOOOV2EneZY/pMn8bcbyV6Aw==
=0tcE
-----END PGP SIGNATURE-----
I've got a problem with the way ElementTree 1.3a3-20070912 handles
attributes
with the default namespace feature (please feel free to redirect me if
this isn't the
proper place to discuss such matters).
'<ns0:a xmlns:ns0="foo"><ns0:b id="1" /></ns0:a>'
Notice that the 'id' attribute does not belong to the "foo" namespace.
If I got the XML 1.0 specification right, this is perfectly normal
(Quoting http://www.w3.org/TR/REC-xml-names/#defaulting) :
"Default namespace declarations do not apply directly to attribute
names;
the interpretation of unprefixed attributes is determined by the
element on
which they appear.
(...)
The namespace name for an unprefixed attribute name always has no
value."
Now, trying to serialize this back with the default_namespace feature
of ET 1.3,
I get an error, as predicted by the online documentation
Traceback (...)
ValueError: cannot use non-qualified names with default_namespace option
Since this is a parse/serialize round-trip, I think that this
behaviour isn't right, and that
unprefixed attributes should go through. Actually, shouldn't
attributes even be outside
of the scope of the default namespace feature ?
Is there hope for future improvements about this ?
I saw some FIXME comment in the source. The svn head version (rev 528)
seems to be identical in that respect, by the way.
Removing in ElementTree.py the part where the ValueError is been raised
seems to solve the issue at first sight :<a xmlns="foo"><b id="1" /></a>
but this lets also unprefixed elements go through, which is unwanted:<a xmlns="foo"><b id="1" /></a>
I wouldn't care in my application, whose output is xhtml, though.
Regards,
--
Georges Racinet, http://www.racinet.fr
Zope/CPS/Plone expertise, assistance & development
GPG: 0x4862FFF7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
iQEVAwUBSjojWeAffZJiF+Z4AQLzpQf+Jf4meVHd5HsB5/DJRMWdSvIT9eCixYXM
WzzW0uXFtF3cJbKptz/KF+elDAdTWvVS3BMPxR/54/Ggz4ItsUR3iBeeh2tH+sp3
OCskxQCpmXvWg9ZfOON26q3M74tXQMnoc5RoSghdLfE0aElwkQpxJhPaIrQL9+zo
7flFK3cTHcoaOje71m/tN+gA2nK3Tgf3Y2LFYgPbc+hQg9ZhOCQ4TVpIP478hQZY
i5i7S15UZ+Ii0u6XQTHpBchvWdMFiW6jhz353tfeJm6v3tZdN3G6m/GKGMNfb7+K
rbbhbPDqwp0mWGIlL6rLR12BUtV1F4tOOOV2EneZY/pMn8bcbyV6Aw==
=0tcE
-----END PGP SIGNATURE-----