68301 - do node order right

Status: VERIFIED FIXED

(Core :: XSLT, defect, P5)

Description

[Axel Hecht]

I strip this out of the "faster" bug, so we can track this separatly.
And as we are broken here, anyway, we have bugs to fix, not just speed
improvents to do.

<xsl:template match="letter[position()=last()]"> is horked. Testcase coming.

Axel

Comment 1

[Axel Hecht]

Attachment: testcase, xml file

Comment 2

[Axel Hecht]

Attachment: testcase, xsl file

Comment 3

[Axel Hecht]

The reversed order of some axes only matters for the predictes, right?
So the order attribute doesn't need to go to the nodeset, but could be held in
the location path function as a local var?

Axel

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

isn't this dup of 70861 (or the other way around)

Comment 5

[Axel Hecht]

might be. I'll check when I'm back. I'm not quite sure, and can't really dig
the source right now.

Axel

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, lets do a multiple choise :)

I see four ways of doing this:

1. Always return NodeSets sorted.
- We sort nodesets that dosn't need sorting
- If we forget to sort somewhere we'll produce errorous output
+ very consistent

2. Have a flag that indicates if a nodeset is sorted or not. The creator of the
   nodeset is responsible for setting the flag to correct value, but it defaults
   to UNSORTED to avoid bugs.
- An extra variable to keep track of
+ We never sort unless needed

3. When evaluating an expression we send along a "contract" object that
   indicates whether the returned should be sorted or not.
- Have check the contract object in lots of places
- If we forget to sort somewhere we'll produce errorous output
+ Several evaluations produce several sets of ordered nodesets, those can be
  swiftly merge sorted if the contract say that that a sorted nodeset should be
  returned
+ We never sort unless needed

4. Send a long a "hints" object instead of a "contract". Have a flag that
   indicates whether the returned nodeset is sorted.
- Both an extra object and an extra flag needed
+ Dosn't matter if we don't check the "hints" everywhere since they are only
  hints
+ Several evaluations produce several sets of ordered nodesets, those can be
  swiftly merge sorted if the contract say that that a sorted nodeset should be
  returned
+ We never sort unless needed


The hints and contract object could be used to other then sorting, for example 
when evaluating an predicate the object could indicate that evaluation should 
stop as soon as the first node is found.

Expressions that dosn't produce sorted results:
id("a b c")

Expressions that dosn't produce sorter results unless mergesorted during 
evaluation:
foo/following-sibling::bar[...]
foo/previous::bar[...]
./ancestor::foo/bar//baz
(basically most path expressions that contain more advanced axes)
key('myKey', foo)

Comment 7

[Axel Hecht]

this is fixed by now.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

well, i don't really know what this bug is/was about any more. But it's so 
confused now that we should file separate bugs if we need to