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

Re: [xsl] things about grouping

Subject: Re: [xsl] things about grouping
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Wed, 28 Nov 2012 12:29:43 +0000

>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

Current Thread