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

Re: [xsl] except (was: Keys with duplicates should be simple)

Subject: Re: [xsl] except (was: Keys with duplicates should be simple)
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Sun, 2 Feb 2014 21:04:28 +0000

> So while I agree with you on the whole, I also make an exception for
> 'except'. It just isn't that bad. Indeed, there is an entire
> profession of people (I think they're called 'mathematicians') who
> consider such verbal stunt work to be just a day at the office.

Indeed, I'm a little curious as to why "except" causes problems. I think we
chose "except" rather than "difference" because "except" would be more
meaningful to non-mathematicians.

We often get people on XSLT forums who are sufficiently unfamiliar with
boolean logic that they use "and" and "or" incorrectly. For example, they will
use "and" to mean "union", as in

select="para and section"

which is natural enough if you understand English and don't understand maths.
I don't think it would have been prudent to design a language in which "and"
meant "union". So in general, maths is a better guide to these operators than

But as for "except", it seems very natural to me:

select="* except para"

seems to reflect normal English usage, such as "all vehicles except bicycles".
(Allowing plurals would make it more readable, but that's asking a bit

Perhaps you are reading "except" as "that are not", i.e. a negated predicate
rather than a set difference). In English this reading would often work, as in
"all vehicles that are not bicycles". But in English grammar, what follows
"except" is not a predicate that qualifies what precedes it: you cannot say
"all vehicles except blue". So I think the XPath usage is aligned with English
usage in this instance.

I'm not sure I followed the thread carefully enough, but I think the usability
problem in this case was not in fact the "except" operator, but rather the use
of "para" to mean "child::para" rather than "self::para". That's probably an
inevitable price you have to pay for conciseness: wherever you allow defaults,
they will sometimes be wrong.

Michael Kay

Current Thread