Re: [xsl] Where is 'intersect' Operator Defined in XPath 3?

Subject: Re: [xsl] Where is 'intersect' Operator Defined in XPath 3?
From: "C. M. Sperberg-McQueen cmsmcq@xxxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 10 Aug 2022 15:00:56 -0000
"Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> writes:

>> First, it suggests to me that XSLT 3.0 might have some functionality not
>> present in 1.0.  (And I think that suggestion turns out to be true.)
>
> Yes, but is the new functionality 10 times the one in XSLT 1.0?   

I don't have a good way to quantify functionality; do you?

XSLT 3.0 has more element types and attributes (and correspondingly more
concepts to explain) than XSLT 1.0, but not (I think) ten times as many.

That's why I think (and said) that another reason the spec has grown is
that in XSLT 1.0 many things are left unstated because it was
(erroneously) felt that they would be obvious to anyone reading the
spec, while the text of XSLT 3.0 is less naive about being able to pass
things over in silence because the answer is "obvious".

I think this is a good thing.  

The assumption that the spec need not describe some corner cases because
"it's obvious that the answer is [X], because nothing else would make
sense" is philosophically and technically unsound.  But I have in fact
heard that remark or variants of it from more than one spec editor
(including the editor of XSLT 1.0), who could not entertain seriously
the idea that any rational being might not see things the same way they
did.  The results have seldom been ideal.  (Examples omitted.)

Historically, I think it's true that many specs grow in ways similar to
those you observe for the XSLT spec.  Often, second and later versions
of a spec include more functionality; even more often they add prose to
address questions that have arisen in practice.  I don't think answering
questions that have arisen in practice can plausibly be interpreted as
evidence that the second and later versions of a spec are less well
drafted.

-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Current Thread