Problem reading large amount data from xml tag

[loretta]

I have data within an xml tag that is being truncated when being read
into a javascript variable. On Firefox, I am only getting up to 4096
characters. On IE, I am getting 31324 characters. I can view the xml
source, all the data is there. I am using javascript function
getElementsByTagName to read the data from the tag and then the
firstChild and nodeValue notations to get the data. I can't find any
references to xml size limits, but I am definitely losing data.
Creating large javascript variables is not a problem, I can do that.
Any help is appreciated.

[Peter Flynn]

loretta wrote:

I have data within an xml tag that is being truncated when being read
into a javascript variable.
Within a start-tag or an end-tag?

If you think that tags are the same thing as elements, you may already
be having trouble (see http://xml.silmaril.ie/authors/makeup/)
On Firefox, I am only getting up to 4096
characters. On IE, I am getting 31324 characters. I can view the xml
source, all the data is there. I am using javascript function
getElementsByTagName to read the data from the tag and then the
firstChild and nodeValue notations to get the data. I can't find any
references to xml size limits, but I am definitely losing data.
Creating large javascript variables is not a problem, I can do that.

The XML standard imposes no limits on the length of character data
that may be contained in an element, nor on the length of the data
in an attribute value. In practice, different operating systems and
different application software will have their own limits, possibly
connected to external restrictions like the amount of physical memory
in the machine, possibly due to historical (inherited) practices, or
(at worst) just sloppy programming or badly-specified systems.

When I see values like 4k or 32k I immediately smell a rat :-)

///Peter
--
XML FAQ: http://xml.silmaril.ie/

[Joseph Kesselman]

Standard reminder: If you're working with SAX, remember that SAX may
break text content across several successive calls to characters().
Failing to allow for this may be the single most common XML programming
mistake.

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Martin Honnen]

loretta wrote:

I have data within an xml tag that is being truncated when being read
into a javascript variable. On Firefox, I am only getting up to 4096
characters. On IE, I am getting 31324 characters. I can view the xml
source, all the data is there. I am using javascript function
getElementsByTagName to read the data from the tag and then the
firstChild and nodeValue notations to get the data.

Mozilla's XML parser is known to create a single text node for each
chunk of 4096 characters so there you will certainly encounter the
problem. The data is not lost however, you will simply end up with an
element in the DOM that has several text child nodes.
Workarounds are using e.g.
xmlDocument.getElementsByTagName('tagname')[0].textContent
instead of accessing firstChild and its nodeValue or to force
normalization of the XML document by calling
xmlDocument.normalize()
first, then you can access firstChild.nodeValue as adjacent text nodes
have been merged into one node.
Note that the textContent property is part of W3C DOM Level 3 and only
newer Mozilla versions support that property.

--

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

[Joe Kesselman]

Martin Honnen wrote:

Mozilla's XML parser is known to create a single text node for each
chunk of 4096 characters

If so, they're doing some slightly sloppy buffer management.

SAX is expected to divide text up wherever's convenient for the parser's
input buffers, since SAX was theoretically intended to be a thin layer
between the parser and application. (It should be even thinner, but it's
a bit late to argue about that now.)

But DOM Level 1 Core's description of Text nodes, reiterated in Level 2
and Level 3, says "When a document is first made available via the DOM,
there is only one Text node for each block of text." So it's surprising,
disappointing, and annoying that Mozilla isn't honoring that expectation.

Ignoring this requirement may be giving them a bit of a performance
boost. And well-written DOM code should be able to deal with it,
especially since parsers which retain CDATA-section boundaries will have
intermixed Text and CDATASection nodes which can cause similar hassles.
So if they wanted to offer this as an _optional_ mode, I wouldn't
complain... But if they aren't defaulting to delivering the document in
single-node-per-text-block form, they really aren't fully conforming to
the spec.
--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry