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: "'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 12:31:22 -0000

> >
> > List<Node> XPath.selectNodeSequence("*")
> > Node XPath.selectNode("..")
> > double XPath.selectDouble("count(*)")
> > String XPath.selectString("name(..)")
> > boolean XPath.selectBoolean("name(..) = 'banana')
>
> This is just where Java's string-typedness mismatches with XSLT's
> weak-typedness. This isn't bad. I am worried that selectNode and
> selectNodeSequence blow up when the expression returns a
> String/double/boolean.
>
> The complexity of it worries me, especially when you do
> consider XPath 2
> where there are many more types that might be returned.

Yes, it's not ideal.

Alternative B is to do what Saxon does in its "internal" interfaces: an
XPath 2.0 expression returns List<Item>, Item subclasses into Node and
AtomicValue, AtomicValue subclasses into IntegerValue, StringValue,
BooleanValue and the rest, and StringValue wraps a String, BooleanValue
wraps a boolean, and so on.

Alternative C is to return List<Object> where the Object may be a String, a
Node, a Boolean, etc, and the user has to sort it out.

Michael Kay





Archive powered by MHonArc 2.6.24.

Top of Page