Hello Dariusz,
it is starting to get complex, so let’s look at the three queries separately.
I think that the first query might be a bug. In my opinion this query should return you an error of some kind, because the sortby clause does not specify a valid node in the current context.
More precisely, the context is DOC - as there is no DATE node in DOC, you should get an error (or at least a warning).
However, it seems that Tamino is very polite and just quietly ignores the sortby clause.
In order to specify a correct sortby clause for DOC it is necessary to use OPERATION/DATE, which brings us to the second query.
In the second query, the DOC elements are sorted into ascending order of the first OPERATION/DATE element in the document.
With the DOCs that you posted above, the lowest value for the first OPERATION/DATE element is 2002-06-03 (in the fourth DOC), then it is 2002-06-05 (in the first DOC), then 2002-06-06 (in the third DOC) and finally 2002-06-08 (in the second DOC).
In my system the ino:id’s have been allocated sequentially, so I get back the DOC elements in the ino:id order 4, 1, 3, 2 - which is correct.
(Although there are DATE elements with “lower” values, they are not in the first OPERATION element in DOC.)
The third query is rather complex. It returns all the OPERATION elements sorted by DATE. Perhaps the missing bit of information here is that the query sorts the OPERATION elements within the DOC elements, and returns the results in ino:id order for DOC.
So you get back the OPERATION elements for DOC (ino:id=1) sorted into DATE order, then all the OPERATION elements for DOC (ino:id=2") sorted into DATE order, and so on.
Perhaps the easiest thing to do next is to ask this: could you please explain what you would like to accomplish with the sorting? Then we can help you to do it.
Best Regards,
Trevor.
#Tamino#webMethods#API-Management