Skip to Content.
Sympa Menu

xom-interest - RE: [XOM-interest] XOM 1.1: XPath

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Michael Kay" <mike AT saxonica.com>
  • To: "'Wolfgang Hoschek'" <whoschek AT lbl.gov>, "'Elliotte Harold'" <elharo AT metalab.unc.edu>
  • Cc: 'xom-interest' <xom-interest AT lists.ibiblio.org>
  • Subject: RE: [XOM-interest] XOM 1.1: XPath
  • Date: Fri, 7 Jan 2005 10:11:36 -0000


> Quoting the saxon documentation
>
> http://www.saxonica.com/documentation/documentation.html
> then click on Standards Conformance/Conformance with other
> specifications:
>
> > When a DOM, JDOM, or XOM tree is supplied as the
> transformation input,
> > Saxon does not combine adjacent text nodes into a single node.
> > Adjacent text nodes can occur as the result of user
> modifications to
> > the tree, or as a result of the presence of CDATA sections
> or entity
> > references, depending on the options in force when the tree was
> > constructed.

The fact that this is documented as a non-conformance means by definition
that I'm not happy with the situation and would like to fix it eventually.
My thinking is that it should be done in the same layer that does
"stripping" (really, skipping) of whitespace text nodes. The main difficulty
is that it's one of those areas where the last 1% of conformance can cost
you 10% in performance, and users don't necessarily find that the right
trade-off. (Microsoft's MSXML3, running against a DOM, has never merged
adjacent text nodes, and this doesn't seem to cause many problems.)

Rather than having Saxon create virtual text nodes to represent a sequence
of adjacent XOM text nodes, I think it would be better if XOM had an option
to merge adjacent text nodes as soon as they are added to the tree.

Michael Kay
http://www.saxonica.com/





Archive powered by MHonArc 2.6.24.

Top of Page