[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] things about grouping

Subject: [xsl] things about grouping
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx>
Date: Wed, 28 Nov 2012 10:06:14 +0000

On Wed, Nov 28, 2012 at 9:47 AM, David Carlisle <davidc@xxxxxxxxx> wrote:
> On 28/11/2012 07:04, Ihe Onwuka wrote:
>> Well XPath has direct support for union and intersect so for
>> completeness we would expect it to support difference. Thats
>> reasonable isn't it. So lets go to the part of the specification that
>> deals with set theoretic operators and see what it says.
>> The first hint of trouble is in the URL.
>> http://www.w3.org/TR/xpath-functions/#union-intersection-except
>> Lets read on and see why there is support for union and intersection
>> and not difference.
>> op:union        Returns the union of the two sequence arguments,
>> eliminating
>> duplicates.
>> op:intersect    Returns the intersection of the two sequence arguments,
>> eliminating duplicates.
>> op:except       Returns the difference of the two sequence arguments,
>> eliminating duplicates.
>> So difference is supported except (pun intended) it is called except.
>> But (sic) the semantic of except  that has been ingrained in us since
>> childhood is that when you say  A except B, B takes it context from A.
> You are not really suggesting that set difference operation (except) should
> behave differently with respect to the current node than the union and
> intersect operations (or list concatenation are you?

I'm saying that since the set union operator is called union and the
set intersect operator is called intersect then the set difference
operator should be called difference - not except and if the argument
is that's what it is called  in the spec my response is that in this
particular instance I don't think that was a reasonable or rational
thing to do.

> in all these cases A and B are evaluated the same way
> A|B
> A intersect B
> A except B
> A,B
> If I understand your message correctly you are arguing that it would somehow
> have been simpler if in the third case only the current node when evaluating
> B was somehow different, I'm not sure what exactly,
> would you want to evaluate B at every item in A?
> In general XPath operators take _values_ (Xpath sequences) not expressions
> so they are always (conceptually) evaluated before the operator.  A except B
> evaluates A and B and then returns all teh items in A that are not in B.
> The path separator / and filter [] are different in that they are specific
> syntax that changes the current item.

If you are going to support an operator called except then it's
semantics should be that such that it takes it's context from it's
left hand side consistent with the semantic we have grown up with
since childhood and further it should be distinct from set theoretic
operators. If that cannot be supported due to pre-existing conventions
or it leads to bastardisations like A[except B] (which will lead to a
bunch of questions as to why the need for the []), then don't support
it. It's syntactic sugar anyway.

Current Thread