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