IE and Mozilla recognize CDATA nodetype differently

[Aziz]

Hi Folks
I am trying to access an HTML code stored as CDATA section in the xml
file listed bellow:

<?xml version="1.0"?>
<results count="5">
<![CDATA[
<table><tr><td> Hello World</td></tr></table>
]]>
</results>

The xml tree is the responseXML part of an XmlHttpRequest and is stored
in a the javascript object xmldoc. While trying to test the node type
of the children of the "results"-Element I got different results with
IE and Mozilla:

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>CDATA

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>NULL

I added a non empty text node to the result element:
<results count="5">
blalba text
<![CDATA[...

Now I get this:
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>TEXT
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>CDATA

Does someone have an explanation for this behaviour?

I am using Mozilla 1.5 and IE 6

Cheers,
Aziz

[Digital]

Aziz -

You need to keep in mind that Mozilla has a very rough time conforming to
standards. Especially when dealing with XML. You will need to run a "fixer
utility" on your XML data before Mozilla can understand it. Here is the
problem:

<parent>
<child1/>
<child2/>
<child3/>
</parent>

What you have there is a parent with 3 children to every XML parser in the
world but Mozilla's. In Mozilla you have a parent with 7 children. Mozilla
treats each line break as a child. In order to combat this you need to loop
through every child and if the nodeType = 3 and the nodeName = '#text' and
the number of childNodes > 1 then you know that what you have there is a
fake child and you can remove that node.

~Digital~

"Aziz" <ra*******@goog lemail.com> wrote in message
news:11******** *************@g 44g2000cwa.goog legroups.com...

Hi Folks
I am trying to access an HTML code stored as CDATA section in the xml
file listed bellow:

<?xml version="1.0"?>
<results count="5">
<![CDATA[
<table><tr><td> Hello World</td></tr></table>
]]>
</results>

The xml tree is the responseXML part of an XmlHttpRequest and is stored
in a the javascript object xmldoc. While trying to test the node type
of the children of the "results"-Element I got different results with
IE and Mozilla:

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>CDATA

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>NULL

I added a non empty text node to the result element:
<results count="5">
blalba text
<![CDATA[...

Now I get this:
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>TEXT
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>CDATA

Does someone have an explanation for this behaviour?

I am using Mozilla 1.5 and IE 6

Cheers,
Aziz

[Digital]

To clarify it isn't the line break per se but any white space between tags
generates another child. e.e. <parent> <child>First Born</child>.... The
space between <parent> and <child> will give you that extra child node in
the XML parser.

"Digital" <re****@spam.co m> wrote in message
news:tv******** **********@torn ado.rdc-kc.rr.com...

Aziz -

You need to keep in mind that Mozilla has a very rough time conforming to
standards. Especially when dealing with XML. You will need to run a
"fixer utility" on your XML data before Mozilla can understand it. Here
is the problem:

<parent>
<child1/>
<child2/>
<child3/>
</parent>

What you have there is a parent with 3 children to every XML parser in the
world but Mozilla's. In Mozilla you have a parent with 7 children.
Mozilla treats each line break as a child. In order to combat this you
need to loop through every child and if the nodeType = 3 and the nodeName
= '#text' and the number of childNodes > 1 then you know that what you
have there is a fake child and you can remove that node.

~Digital~

"Aziz" <ra*******@goog lemail.com> wrote in message
news:11******** *************@g 44g2000cwa.goog legroups.com...

Hi Folks
I am trying to access an HTML code stored as CDATA section in the xml
file listed bellow:

<?xml version="1.0"?>
<results count="5">
<![CDATA[
<table><tr><td> Hello World</td></tr></table>
]]>
</results>

The xml tree is the responseXML part of an XmlHttpRequest and is stored
in a the javascript object xmldoc. While trying to test the node type
of the children of the "results"-Element I got different results with
IE and Mozilla:

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>CDATA

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>NULL

I added a non empty text node to the result element:
<results count="5">
blalba text
<![CDATA[...

Now I get this:
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>TEXT
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>CDATA

Does someone have an explanation for this behaviour?

I am using Mozilla 1.5 and IE 6

Cheers,
Aziz

[Martin Honnen]

Digital wrote:

You need to keep in mind that Mozilla has a very rough time conforming to
standards. Especially when dealing with XML.
Are you trolling?
Here is the
problem:

<parent>
<child1/>
<child2/>
<child3/>
</parent>

What you have there is a parent with 3 children to every XML parser in the
world but Mozilla's. In Mozilla you have a parent with 7 children.

Does "every XML parser in the world" include the DOM implementation in
PHP 5?

Doing

$xmlMarkup = <<<EOD
<parent>
<child1/>
<child2/>
<child3/>
</parent>
EOD;

$xmlDocument = new DOMDocument();
if ($xmlDocument->loadXML($xmlMa rkup)) {
echo 'Number of child nodes: ' .
$xmlDocument->documentElemen t->childNodes->length;
}
else {
echo 'Parse error.';
}

there gives

Number of child nodes: 7
Does "every XML parser in the world" include the DOM implementation in
Opera 8? Doing

var xmlDocument = new DOMParser().par seFromString([
'<parent>',
' <child1/>',
' <child2/>',
' <child3/>',
'</parent>'
].join('\r\n'), 'application/xml');

alert(xmlDocume nt.documentElem ent.childNodes. length);

there alerts 7.

The same with Opera 9.
Does every XML parser in the world include the Java parser that guy
<http://groups.google.c om/group/comp.lang.java. programmer/msg/b2073fbf8a38066 9?hl=en&>
is using?

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Aziz]

Thanks for the help. I have modified my PHP server side code to provide
the xml response as a string with no \n or \r.

To clarify it isn't the line break per se but any white space between tags
generates another child. e.e. <parent> <child>First Born</child>.... The
space between <parent> and <child> will give you that extra child node in
the XML parser.

"Digital" <re****@spam.co m> wrote in message
news:tv******** **********@torn ado.rdc-kc.rr.com...

Aziz -

You need to keep in mind that Mozilla has a very rough time conforming to
standards. Especially when dealing with XML. You will need to run a
"fixer utility" on your XML data before Mozilla can understand it. Here
is the problem:

<parent>
<child1/>
<child2/>
<child3/>
</parent>

What you have there is a parent with 3 children to every XML parser in the
world but Mozilla's. In Mozilla you have a parent with 7 children.
Mozilla treats each line break as a child. In order to combat this you
need to loop through every child and if the nodeType = 3 and the nodeName
= '#text' and the number of childNodes > 1 then you know that what you
have there is a fake child and you can remove that node.

~Digital~

"Aziz" <ra*******@goog lemail.com> wrote in message
news:11******** *************@g 44g2000cwa.goog legroups.com...

Hi Folks
I am trying to access an HTML code stored as CDATA section in the xml
file listed bellow:

<?xml version="1.0"?>
<results count="5">
<![CDATA[
<table><tr><td> Hello World</td></tr></table>
]]>
</results>

The xml tree is the responseXML part of an XmlHttpRequest and is stored
in a the javascript object xmldoc. While trying to test the node type
of the children of the "results"-Element I got different results with
IE and Mozilla:

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>CDATA

xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>NULL

I added a non empty text node to the result element:
<results count="5">
blalba text
<![CDATA[...

Now I get this:
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[0].nodeType -->
MN=>TEXT,IE =>TEXT
xmldoc.getEleme ntsByTagName("r esults")[0].childNodes[1].nodeType -->
MN=>CDATA,IE =>CDATA

Does someone have an explanation for this behaviour?

I am using Mozilla 1.5 and IE 6

Cheers,
Aziz

[aziz.hammadi]

Hi all
After seeing all those problems with XML and Mozilla, I am just asking
myself , if Mozilla is
really that good Browser. In Order to be compatible with all Browsers,
I use now reponseText with AJAX to transport the http response and not
responseXML . I still can not imagine that Mozilla does not support
xmlResponse like IE.
Any idea?

Cheers
Aziz

[Thomas 'PointedEars' Lahn]

az**********@gm ail.com wrote:

[...]
After seeing all those problems with XML and Mozilla, I am just asking
myself , if Mozilla is
really that good Browser. [...]

You *are* trolling. FOAD.
PointedEars

[VK]

az**********@gm ail.com wrote:

Hi all
After seeing all those problems with XML and Mozilla, I am just asking
myself , if Mozilla is really that good Browser.

Mozilla Foundation has nothing to do with the "unwanted nodes" problem.
They just strictly implement the relevant W3C standard.

By W3C an XML structure is being preserved in that exact state as it
came to you. By IE XML structure is being optimized by parser, which
means much lesser problems but the original XML changed.

There is a long lasting discussion about what is more
programmaticall y-wise correct at
<http://bugzilla.mozill a.org/show_bug.cgi?id =26179> where you are
welcome to join.

I'm not a participant of that discussion but I really like proposals to
make "exact nodes preservation" an option one would be able to turn on
and off.

The chances to have it ever blessed by W3C are very weak though, so all
kind of "TreeWalker s" still remain a must.