xpath processing.

[Tarun Garg <ta...@ebprovider.com>]

We are trying to develop an application where the databases would be
modelled and queried as xml documents. So instead of writing SQL queries,
the user can specify the XPath. One way to achieve this could be that we
actually make an xml document for the entire database, and then use Xalan to
return the desired node set. But of course such an approach has its
limitations. Efficiency, how would you insert...and others.
The other ( and the proposed) method could be that a processor actually
converts the XPath into the required SQL queries. The vision being that the
data source could be something else other than a database server too. If
every such data source can be modelled as an XML document, the user only
needs to be comfortable with XPath rather than so many different query
languages. Once XQuery stabilises, that can be a good option too, but
probably that would be too elaborate for our needs.
For the time being, our plan is to stick to XPath and the schema for a
particular database would also be specified for us. We can chose a schema to
suit our processor needs.
Instead of writing the entire application ground up, we can actually use
some code from the XPath module of Xalan. This module parses XPath and has
the semantic information stored in it which we can use to make the data
source specific queries.
Of course, the obvious question here is how.
I have seen the xalan design given here
 http://xml.apache.org/xalan-j/design/design2_0_0.html)
That is quite a broad level design.
On the code level, what I could make out is that the Lexer tokenizes the
expression, then the Compiler converts it into some sort of operation codes
and eventually an expression tree. After that it actually applies the
expression tree on the node and returns the result. This is only a rough
 and probably inaccurate) view I've been able to form.
Is there any place where I can actually read about the kind of algorithm
this module follows. In fact it would suffice if I were to understand
exactly what does that array of operation codes mean. Basically the
semantical knowledge that this module has generated after parsing the string
( if it resides somewhere else than the opcodes).
Thanks for at least patiently reading it till here.
ANY help, directions, suggestion, advice, criticism, pointers is welcome.
( of course the last resort would be to do the entire parsing again,
but....)

Thanks and regards.

Re: xpath processing.

[Gary L Peskin <ga...@firstech.com>]

Tarun Garg wrote:

> Is there any place where I can actually read about the kind of algorithm
> this module follows. In fact it would suffice if I were to understand
> exactly what does that array of operation codes mean. Basically the
> semantical knowledge that this module has generated after parsing the string
> ( if it resides somewhere else than the opcodes).
> Thanks for at least patiently reading it till here.
> ANY help, directions, suggestion, advice, criticism, pointers is welcome.
> ( of course the last resort would be to do the entire parsing again,
> but....)

Have a look at org.apache.xpath.compiler.OpCodes.  This shows how the
XPathParser populates the m_opMap byte array which represents the parsed
version of the XPath expression.

Also, you might want to include some code at the end of the
XPathParser.initXPath method that dumps out the m_opMap byte array. 
Then, you could create various XPaths and see how they are represented
in m_opMap.

HTH,
Gary