RE: [xml-dev] The limitations of XPath and navigation for XML da

Hi Mike,

You wrote, “What it boils down to with me is that XPath is logically specifying the logic (externally) that is needed to be performed (internally). The external navigation instructions must be specified procedurally to correctly define any of the possible choices for internal operations.”

But it is not XPath requires you to define the detailed step from A to C with /A/B/C. It is the requirement of your application that requires you to give such a detailed step so that you can get the C that appears within B which is under A. If your application, for example, just want to retrieve C no matter where it appears, then even with XPath, you can just say “//C” without giving every step from A to C. So I think the path is actually says what you want instead of instructing the processor how to get it.

Lisa

From: mike@adatinc.com [mailto:mike@adatinc.com]
Sent: Thursday, February 07, 2008 3:40 PM
To: noah_mendelsohn@us.ibm.com; mike@adatinc.com
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] The limitations of XPath and navigation for XML database processing

Hi Noah, you wrote me-

>
>Yes, but I think you're misreading XPath. By that definition, it's
>declarative, though that may not be obvious. Let's look at a simple
>XPath:
>
>/A/B/C
>
>Someone could have specified the languages as: "First you go to the root,
>then you find an A, then within that you find a B". That's a procedural
>language, and it's probably how you're thinking about it. That's not the
>way I look at XPath and I think not the way it's intended to be looked at.
> I believe that the intended way to think about the same expression is:
>"This expression matches any one or more C's that are within B's that are
>within an A that's an immediate child of the root.
>
>Note that this latter interpretation does >not< tell you how to find them.
> One obvious way, is to find all the A's, then within that find all the
>Bs, and so on, but there are other implementation strategies. You might
>read in a whole document, make a hash to find out where all the elements
>are by name, and by the way count the number of occurrences and set up
>parent pointers. You might notice that while there are 100,000 As, there
>are only 2 Cs. Using this information, an XPath optimizer might decide to
>go directly to each of the Cs and follow its parent chain to discover
>whether it in fact satisfies the XPath.
>
>

Your example of XPath /A/B/C being able to be processed internally in any way that is still semantically correct to optimize it could be applied to COBOL and I would not consider COBOL nonprocedural. What it boils down to with me is that XPath is logically specifying the logic (externally) that is needed to be performed (internally). The external navigation instructions must be specified procedurally to correctly define any of the possible choices for internal operations. I think there is both a user and developer perspective for what is nonprocedural or procedural. My article was writing to the user audience.

/Mike