RE: XML Encoding of XPath: Examples

[Charles Reitzel <creitzel@mediaone.net>]

Yes, I am working on it - a bit at a time.  I have worked out a basic inheritance hierarchy for expressions that, at first glance, looks highly compatible with Wayne's XML representation.  I still need to study his proposal in detail.  I'd suggest that an API that parses an XPath expression and provides access to its parts is the easy way to generate the XML.

Expression 
  SimpleExpression 
    NCName 
    QName 
    LiteralString 
    LiteralNumber 
    Operator 
        RelationalOperator
         EqualityOperator
         AndOperator
         RootOperator
    NodeType
       ProcessingInstruction
       Text
       Comment
        Node
    Axis
    NameTest 
    Function 
    Variable 

CompoundExpression 
    Union 
    Filter 
    LocationPath 
    Step 
    Predicate 
        And
        Or
        Equality 
        Relational

After allowing for abbreviated forms of some of the above, I think parsing an XPath expression in string form into a data structure composed of nested expressions isn't bad.  I think the details of all the calls necessary for creating expressions from parts (i.e. the factory methods) still needs some work.  I'm thinking these should come after an initial parser implementation so the data structure can be validated.  The right factory methods should pretty much fall out.  

Like Wayne, I'm shopping for test XPath expressions!

Also on my issues list is copyright issues.  I didn't end up using much, if any of the SAC code, as I ended up keeping XPath names.  I find it easier to compare to the XPath spec.  So I am planning on just using David Megginson's anti-copyright:

        "// No warranty; no copyright -- use this as you will."

Before we can declare minimal victory, however, methods for adding parsing and evaluation helpers will be necessary to support additional functions and XPath extensions.

With decent expression parsing and construction tools, we'll be able to deal with data model inconsistencies.  After thinking about the problem, my feeling is that this will only be a problem when dealing with string functions that cross node boundaries or select partial nodes.  The details of implementation will depend on whether evaluation is against a DOM or a SAX stream.  But the basic concepts will stay the same: coelesce adjacent text nodes (per XPath data model) prior to string function evaluation.  Emit text nodes according to function results and XPath data model.  For SAX, it may mean that implementations will have to keep the current element's text nodes around until the end tag has been found.  But perhaps nothing more dramatic.  This is in addition to keeping (at a minimum) the ancestor path for the current node around.

Please respond with any errors or ommissions in the expression hierarchy and any constructive critiques of the game plan.

take it easy,
Charles Reitzel


At 03:47 PM 3/15/01 -0800, Evan Lenz wrote:
>Dan Diebolt wrote:
>> Am I missing something here? Why would it
>> be desirable to reform XPath into XML?
>> What problem would this address?
>
>It would address the problem of the programmatic manipulation of XPath
>expressions. I don't think anyone's suggesting that XSLT should use an XML
>syntax for XPath, but it would be nice if one could *view* an XPath
>expression as XML, in order to leverage all of the familiar XML processing
>tools, eg. DOM, SAX, and XSLT (which, of course, includes XPath itself).
>
>One particular use case that I've come across is the manipulation of
>existing XSLT stylesheets. XSLT can work quite well to make these
>manipulations, but it does not work well for string parsing in general, and
>parsing XPath expressions in particular. If I had, say, an extension
>function that returned a root node containing the XML tree representation of
>a particular XPath expression, then I could query and/or manipulate that
>XPath expression just as I would any other tree. Another extension function
>would allow me to serialize that tree back into XPath syntax.
>
>This same general problem is addressed in this recent xml-dev thread:
>http://lists.xml.org/archives/xml-dev/200103/threads.html#00178
>
>Hope this helps,
>
>Evan Lenz
>XYZFind Corp.


take it easy,
Charles Reitzel