On Wed, Nov 28, 2012 at 12:29 PM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
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.
I think it must have come from. The SQL Standard which uses Except as
the difference operator although Oracle uses the far more palatable
Minus (not sure whether this is instead of rather than in addition to
where one flavour dedups and the other doesn't).
My view is unchanged - it's just another sin SQL commits against the
theoretical domain it is modelling. The situation in SQL is palliated
by the fact that the syntax is always
Select statement
except
Select statement
i.e no abbreviated form to trip over.
I found the following commentary in the form of a book review
http://www.amazon.com/First-Course-Database-Systems-Edition/product-reviews/013600637X/ref=dp_top_cm_cr_acr_txt?ie=UTF8&showViewpoints=1
"These are classics and should be on the bookshelf of everyone who
calls him/herself a computer scientist.
This book is, however, a little disappointing. Most of it is good,
some of it very good. But I do find some flaws in it. One of the
glaring flaws deals with the attempt to extend the relational model
from sets to bags (basically, to allow for duplicate tuples in
relations.) This is the best attempt I've seen at formalizing "bag
theory", but it introduces problems (some minor, others very serious)
that aren't mentioned in the text. This review is too short and not
the right place to expound on these problems. Chris Date's database
text goes into most of them in substantial detail."
As I recall (very very vaguely) the issues centre around situations
where seemingly equivalent expressions don't yield the equivalent
results because they involve multisets. One of Date's arguments (again
I recall very vaguely) seems to be stick to applying set theoretic
constructs to sets and you avoid such anomalies.
Seeing as XPath also applies set theoretic operators to multisets the
same warnings should apply.
I for one would take the performance hit of deduping as a price worth
paying for not having to play computer in order to reason about an
expression I just wrote.
Maybe the language designers sought to adopt SQL practices and
subliminally did so warts n all. I wonder how many mystifying
subtleties of the language that explains?
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.
I will if someone will tell me where and how to sign up to any ongoing effort.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--