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

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

An example of the reasons for my exacerbations with XPath
and my own questions about reliance on it

I've been trying XPath expressions which would be tests I
could apply to some XML for validation during processing
(of a dataset in some ASP.NET, in this case, which seems
a sensible use case).

Here is an example fragment

<a xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version-id="0.4"
    xmlns="http://example.com";>
...

In XPath 1.0
/default:a/@version-id = 0.4 returns true
but  /a/@version-id = 0.4 returns false

In XPath 2.0
/default:a/@version-id = 0.4 returns an error (prefix not bound)
and  /a/@version-id = 0.4 returns true

(I tried these out in Oxygen and I trust the results)

In my own case I'd start off with XPath 1.0 as it is there out-of-the-box
in my particular toolbase but later I would imagine there might be a
reason to progress to XPath 2.0. It would look to me is if all the XPaths
would need review in that case and some awkward gotchas might occur
and developers might have to learn about lots of subtle and barely explicable
nuances and differences between the versions, etc. I'd be reluctant to
encumber them with this by chosing this approach to validating the XML
beyond what I get with XSD but overall there doesn't seem to be an
easier/better alternative so I'd probably still go ahead.

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