Re: [xsl] things about grouping

[Michael Kay <mike@xxxxxxxxxxxx>]

>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. 
This applies to all employess except directors. All my kids except 
Jimmy. I know people that were involved in drafting that specification 
read this group. So I am going to out myself as a whining quiche eater 
and ask the obvious question. Why.

I think you are making two points:

(a) the choice of keyword. Working groups sometimes have agonizing 
debates over the choice of keyword, and sometimes it goes through on the 
nod without significant discussion. If memory serves, in this case there 
wasn't much discussion. This might have been because there was a lot of 
controversy about introducing the keyword "union" as a synonym for the 
existing "|", which was done because some people on the XQuery group had 
spent much of their lives writing SQL and felt strongly about the 
choice; when working groups have decided one controversial question, 
they are often inclined to accept other parts of the same proposal 
without much discussion. If there had been a discussion I guess it would 
have been between those who wanted to use the language of mathematics 
and those who wanted something closer to English; there is no knowing 
which view would have prevailed, because committees don't apply a 
consistent policy on such issues, they decide each question on its 
merits. As it is, the English conjunction was chosen over the 
mathematical set operator.

(b) the context for evaluation. I have some sympathy with you here 
because there are many cases in XQuery where I expect the context to 
change and it doesn't. Most notably, I often (after years of practice) 
make the error of writing "for $x in E return @a" (where it should be 
$x/@a). Similarly a "where" clause in XQuery doesn't change the context. 
What you are seeing here is another design conflict; XSLT and XPath tend 
to be context-sensitive, XQuery tends not to be. It's a usability 
trade-off. There's no doubt that failing to understand when context 
changes and when it doesn't is a major source of programming errors 
whichever approach is taken, and arguably mixing the two approaches is 
the worst of all possible worlds. I think your reasoning about "except" 
is that you expect it to behave like "where not" - which it does, 
because "where not" doesn't change the context either.

I would strongly recommend that you get involved in the process of 
defining these languages and specifications. You will find many cases 
where you are able to make a difference simply by alerting the group to 
problems that it might not otherwise have noticed. You will also find 
cases where you are extremely frustrated because some other apparently 
intelligent person passionately takes a view that is different to your 
own; if you put aside the frustration and try to understand their 
argument you will often come to appreciate that what is obviously right 
and good depends on where you are starting from.

Michael Kay
Saxonica