XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

> 
> 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/