RE: Comments on XPath Filter 2.0 draft (2002-06-20)

Hi John,

> Hi Merlin and Gregor,
> 
> I didn't originally think that the spec was 'missing' a stack 
> of the values of Z because I interpreted the 'update' method 
> for Z to be in a declarative format, not the imperative 
> format.  It does not seem possible to read the 
> Z-update-bullet-point and not translate it into a 
> stack-driven algorithm in an imperative language.
> 
> The Z-update-bullet-point says that Z should be updated true 
> if P and updated to ***false if not P***, where P = the node 
> under consideration is in any *subtree-expanded* union and 
> all subsequent *subtree-expanded* intersects but no 
> subsequent *subtree-expanded* subtracts.

Yes, but the first sentence of the first inner bullet defines the
condition wheter to apply the update algorithm *at all*:

  "Any time a node is encountered that is in any evaluated 
   node-set S ...[apply update algorithm]"

And this is the problem I tried to demonstrate in my example.

> In Gregor's example, the fourth iteration should be setting Z 
> to false because, in the declaration above, P is false.

Yes, if the algorithm had been applied, it would have updated
Z this way. *But* the condition wheter to apply the algorithm
evaluates to false ...

> Note, however, that P is false for a different reason than 
> given in Gregor's example.  True that the node <DontSelect/> 
> is not in any filter node-set, but it is in the 
> subtree-expanded union.  Since it is not in the subsequent 
> (subtree expanded) intersect, the logical-and fails, making P 
> false and hence Z false.

In my example, I haven't worked out wheter P is false or true
(see above).

> The point I will concede is that the statement "iterate 
> through the input document in document order" seems 
> unnecessary.  The declarative style would simply be to say 
> "Process each node in the document, adding each node to the 
> filter node-set..." .  The 'iterate' part simply reflects our 
> knowledge that iteration is what will happen, particularly if 
> the implementer co-mingles the filtration with canonicalization.

I do not agree that it is sufficient to simply remove the "iterate"
passage. Either we introduce the stack, as Merlin suggests, or we
remove the condition wheter to apply the flag Z update.

[...]

Regards, Gregor