Re: CDATA nodes have no name?

Le 03-12-06, =E0 20:31, Daniel Veillard a =E9crit :

> On Sat, Dec 06, 2003 at 03:56:14PM -0500, Marc-Antoine Parent wrote:
>> Anyway, could someone tells me if this has been fixed in latter
>> releases, and what behaviour I should expect from them?
>
>   The fix should be to do the test in a different way.

 =46rom my side, of course; but from this remark, I fear you may be=20
thinking that the problem is only in my code. As it is, the=20
python-libxml binding layer crashes before reaching my code, and a fix=20=

is needed there. Or were you writing this for other maintainers of the=20=

binding layer? I agree that my attempt at correction was quite lame; It=20=

should be fixed by looking at the type.

>> But I am interested in another issue, now:
>> In libxml.py:
>> def nodeWrap(o):
>>     # TODO try to cast to the most appropriate node class
>>     name =3D libxml2mod.name(o)
>>     if name =3D=3D "element" or name =3D=3D "text":
>> ....
>>
>> This crashes on CDATA nodes as they have a name of None. (Or NULL =
from
>> a C standpoint.) I notice that the python code did not change in=20
>> 2.6.1.
>> Do CDATA nodes still return a vacuous name?
>
>   Hum, the data type should be checked first,

Indeed.

>> I find I am a bit confused between libxml_name and libxml_type in
>> libxml.c, as nodeWrap seems to use the former, but take results that
>> look as if they came from the latter.
>>
>> My solution was to correct
>>     if name =3D=3D "element" or name =3D=3D "text":

By the way, apologies: I had been less than clear. My (hacked)=20
correction was to write
     if name =3D=3D "element" or name =3D=3D "text" or name =3D=3D None:
But it would be much better to start with
     name =3D libxml2mod.type(o)
as that function returns "cdata" correctly.

>> but my CDATA object prints out as <xmlNode (None) object at =
0x1061030>
>> and not <xmlNode (cdata) object at 0x1061030> as I would like...=20
>> Though
>> getting at its type or calling getContent() gives me a correct =
answer!
>
>   The type should really be used to make the differentiation, not
> the returned name. For example it's perfectly legal to name element=20
> nodes
> "text" like in <text/> ...

Yes, I do use the type in my own code. I do not expect that =20
libxmlmod.name(o) should return me the name "cdata", also a valid xml=20
element name. However, it would be nice if the repr() of the node gave=20=

the type accurately, which is another issue.

Thank you for your attention,

Marc-Antoine Parent