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>, "'xom-interest'" <xom-interest AT lists.ibiblio.org>
  • Cc:
  • Subject: RE: [XOM-interest] XOM 1.1: XPath
  • Date: Fri, 7 Jan 2005 10:39:20 -0000

>
> 1. XPath has namespace nodes. XOM doesn't.

Note that the namespace axis is deprecated (and optional) in XPath 2.0. If
you're intending to produce a subset XPath implementation (not something I
would encourage, given XOM's admirable reputation for being obsessive about
conformance) then leaving out the namespace axis would seem a reasonable
thing to do. XPath 2.0 makes up for the missing functionality with two
functions in-scope-prefixes() and namespace-uri-for-prefix(). However,
in-scope-prefixes() returns a sequence of strings so it only works in the
context of the 2.0 type system.
>
> 2. XPath functions tend to return numbers, booleans, strings, and
> node-sets. In XOM this would need to be expressed as
> returning a list of
> objects, or some such, which I really don't like for reasons
> of type safety.
>
> My thought here is to simply restrict all queries to location
> paths and
> multiple location paths separated by |. (I wish there were a name for
> this.) Is there an alternative to this? Would it be useful to allow
> other XPath expressions that return node-sets, even if
> they're not full location paths?

I think the restriction you are proposing is "all XPath 1.0 expressions
whose result is a node-set". (This isn't the same as "XSLT 1.0 patterns",
because it includes expressions such as ".." or "following-sibling::*").
Other APIs for XPath have provided one method to return a single node,
another method to return a set of nodes.

I would encourage you to design the API so that it extends to anything XPath
2.0 can throw at you even if you initially implement only a subset of XPath
1.0. I think the right way to do this is to have methods that are specific
to the return type expected:

List<Node> XPath.selectNodeSequence("*")
Node XPath.selectNode("..")
double XPath.selectDouble("count(*)")
String XPath.selectString("name(..)")
boolean XPath.selectBoolean("name(..) = 'banana')



>
>
> 3. How are XPath variables bound?
>

I think the answer to this depends on answering another question first:
should it be possible to compile and execute an XPath expression in two
separate steps? This is a performance/usability trade-off and it depends on
the usage scenarios you are trying to cater for. If you want to allow a
separate compile step, then you need to support variables, if not, then you
probably don't.

The JAXP 1.3 API also allows external functions to be bound, which might
seem a little over the top. It depends what you are trying to achieve. Do
you want your XPath engine to be usable, via this API, by a separate XSLT
engine? In that case, you need to provide complete control over all aspects
of context.
>
>
> 4. How are namespace prefixes bound? (especially important for the
> default namespace)
>
> This one's tougher because, unlike the variable binding, XOM really
> can't just punt on this.

Agreed.
>
> The final question is what the API will look like. My current
> thinking
> is that this will be two methods added to the Node class that
> look like
> this:
>
> public Nodes query(String xpath) throws ToBeDeterminedException
> public Nodes query(String xpath, Map namespaceBindings)
> throws ToBeDeterminedException
>

If you're going to have a second argument, I'd suggest you make it a Context
argument that is extensible to support all possible aspects of the XPath
context. In a single-shot interface this should combine the static and
dynamic context; in a 2-stage compile/run interface you should distinguish
the two.

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





Archive powered by MHonArc 2.6.24.

Top of Page