Re: [xml-dev] Concerned about the increasing reliance on XPath

[Stephen D Green <stephengreenubl@gmail.com>]

I agree that we perhaps lean too much on XPath.

What puzzles me is that there is still a nagging
feeling in my mind that XPaths might not cut it in
the real world and yet hardly anyone has complained
that they do not get adequate reliability with XPath
constraint expressions. Has anyone had any real
success using XPath expressions in a production
system at run-time? Has anyone real life experience
using Schematron or XML Schema 1.1 xpaths in
anger at run-time? I have often used XML Schema
1.0 as part of a run-time coded application such as
an ASP.NET interface as part of a dataset definition
and it works just fine. What if I wanted to extend my
code with some rules expressed in XPath so that I
could let run-time validation happen as data is entered
into my dataset? Would XPath be up to it? Can I get
a meaningfully accurate level of granularity with an
XPath expression? I don't see a problem using XPath
per se since it is part of the XML parser's capabilities,
unless it slows the application down too much. I just
wonder whether I can express real-life constraints
adequately with it. It lets me express roughly what I
want but I do get alarm bells ringing when I find that
to express a real constraint adequately it gets so
complex and might have unforeseen loopholes, side
effects, etc. It looks so promising. I could in theory
add to the out-of-the-box schema validation that comes
with .NET my home-baked Schematron or XSD 1.1
XPath validator (perhaps just using Schematron to wrap
the XPath expressions then using the .NET XPath
facility to call XPath predicate expressions on my
dataset XML every time it changes, just like .NET does
with my XSD 1.0 schema) but does it work well? One
question and worry is: What if an XPath expression
I intended to be a predicate returning true or false in
some situations returns a nodeset or string value?
The problem might be alleviated because I could first
rely on the schema to ensure there are no multiple
occurrence children where a single child was anticipated
and the assume these constraints as prerequisites for my
XPath expressions but what if I leave a cardinality as
multiple in the schema by mistake then never get an
actual multiple occurrence during testing until one day I
do and oops! It makes me nervous to think how I might
rely on XPath.

The problem is it filled a gap with a open standard and
offered such promise as such that XML vocabs could
be written which did not tie people in to proprietary
products. We supplemented a schema with XPath rules
and assumed these could be implemented out of the box.
Have we ascertained that this has been successful in
practice though? Can double-pass validation and triple
pass validation be used at run time? Can XPath express
real constraints and rules for real XML vocabularies (with
namespaces, etc) reliably? I note that it does seem to
have allowed WS-I to produce neat validators for their
web services profiles. Can the same be done for other
profiles or does the choice of XPath impose too much
limitation on the kinds of rules and assertions which can
be expressed? Do we really need something more powerful
and precise? A rules language say? A mixture of OWL and
some kind of standard OWL query language? Or just plain
old code against a prose specification? I haven't noticed
anyone making a fuss of having used XPath to move away
from the latter in real applications. Why is that? Perhaps
it just doesn't happen.

----
Stephen D Green



On 7 May 2011 14:51, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> XPath is a fabulous language. It is incredibly powerful. It is a large, rich language.
>
> I have observed in increasing usage of XPath.
>
> For example, in XML Schema 1.1 the new assert element uses XPath to express constraints:
>
>    <assert test="XPath" />
>
> XPath gives a lot of power to the assert element.
>
> But it also means that a lot of power is needed to evaluate the assert element.
>
> To evaluate that tiny, innocuous assert element you need to implement the entire XPath language.
>
> Suppose the assert element was simplified. The only kind of assertion that can be made is, "The value of the first child element must be greater than the value of the second child element." Here's how we might use it to express the constraint between a meeting's start time and end time:
>
> <greaterThan>
>        <element name="start-time" type="dateTime" />
>        <element name="end-time" type="dateTime" />
> </greaterThan>
>
> Very little power is needed to evaluate this "assertion".  The assertion is expressed entirely in XML markup.
>
> We've lost an enormous amount of power/expressivity. But we've gained in reduced cost of evaluation/processing/coding.
>
> While XPath is nice, it is:
>
>    - not XML
>    - requires huge amounts of processing (i.e., coding) wherever it's used
>
> I am concerned about the increasing reliance on XPath.
>
> My Position: In some cases it would be better to ratchet down capabilities and use XML markup rather than XPath.
>
> I know many people will disagree with my position. Let's have a good discussion of the issue. Here's the issue:
>
> Issue: Is the increasing reliance on XPath a positive or negative trend?
>
> (Implicit in this "issue" is an assumption that there is indeed a growing trend toward using XPath)
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>