RE: XML Encoding of XPath: Examples

[Evan Lenz <elenz@xyzfind.com>]

Wayne Steele wrote:
> Eric van der Vlist wrote:
> >Having used HP polish notation a lot in my early days, I would have
> >thought of an XPath expression as a stack and would have embedded the
> >location steps instead of keeping them at the same level...
>
> That was my original thought.
> Modeling Location Steps as functions, and using a prefix notation.
> I ended up with something like
>    child::foo/attribute::bar
> looking like
>    <attribute name="bar">
>       <child name="foo">
>          <contextNode />
>       </child>
>    </attribute>

How interesting. I don't know exactly what Eric had in mind, but I was
thinking that the containment would work the other way around.

Instead of the above, you'd have something like:

<child name="foo">
   <attribute name="bar"/>
</child>

Eric, is this the kind of containment you had in mind?

I haven't worked out the implications of doing this, but it would feel more
natural and look more familiar to users of, say, TREX.

At my place of employment, XYZFind Corp., we use our own XML query language,
which provides a subset of XPath's capabilities (rough equivalents to child,
descendant, and attribute axes, plus a range of other features such as
keyword search and numeric range search). We currently don't define XYZQL in
terms of XPath, so we don't have the burden of figuring out how to express
other axes or talk about axes at all.

But if all you have are these down-reference-only axes (roughly akin to the
abbreviated XPath axes and XQL/XQuery path expressions), then explicit
containment in the XML encoding of such queries seems quite natural.

For example, something like /foo/bar[contains(.,"baz")] would look like this
in XYZQL:

<foo>
  <bar>baz</bar>
</foo>

And //foo/*/@bar[contains(.,"baz")] would look like this (namespace declared
elsewhere):

<xyz:any>
  <foo>
    <xyz:one>
      <xyz:attribute>
        <bar>baz</bar>
      </xyz:attribute>
    </xyz:one>
  </foo>
</xyz:any>

(Another superficial similarity to TREX here is the unified treatment of
elements and attributes.)

This sort of containment is what I would at first imagine in an XML encoding
of XPath. However, it may be too non-intuitive or confusing once the other
XPath axes are introduced, not to mention predicates. And you make a valid
point that XPath is defined as a *series* of steps, rather than a hierarchy.
If this kind of encoding can't work for full XPath, maybe there could be an
XML syntax for XQuery path expressions that could use an approach such as
this.

Jonathan Robie mentioned that the XSL WG originally tried using an XML
syntax for node selection but changed their minds (probably a good thing).
Does anyone know if there's any publicly available documentation of this
work?

In any case, at my company we've found that queries that "look" like the XML
we're querying (and hence look like query results) have been very easy for
people to learn, as well as easy to construct queries given instances. It
has also been very easy to use XSLT to generate HTML forms for querying
certain document types, generating queries from user entries, and
iteratively constructing queries based on results from previous queries.

Wayne, thanks for your work thus far; it looks quite promising.

Evan Lenz
XYZFind Corp.
http://www.xyzfind.com (free download available)