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

["Eliot Kimber eliot.kimber@xxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

For me the lesson is to not depend exclusively on the Functions and Operators
spec when looking up how to achieve a particular result with XPath.

I donbt mean to appear to be either pedantic in my assertion of where things
should be or ungrateful for the specs as they are, which are by the standards
of standards remarkably well crafted and useful documents.

I was just surprised to not find the definition of a thing referred to as an
operator in the F&O specb&

Because the 3.1 F&O is so useful and easy to navigate I have come to depend on
it heavily.

Cheers,

E.

_____________________________________________
Eliot Kimber
Sr Staff Content Engineer
O: 512 554 9368
M: 512 554 9368
servicenow.com<https://www.servicenow.com>
LinkedIn<https://www.linkedin.com/company/servicenow> |
Twitter<https://twitter.com/servicenow> |
YouTube<https://www.youtube.com/user/servicenowinc> |
Facebook<https://www.facebook.com/servicenow>

From: C. M. Sperberg-McQueen cmsmcq@xxxxxxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Monday, August 8, 2022 at 4:24 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [xsl] Where is 'intersect' Operator Defined in XPath 3?
[External Email]


"Dimitre Novatchev dnovatchev@xxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> writes:

> Thus the language is in such a state that not all operators can be
> found in a single document ...

I think that may depend on how one chooses to define 'operator'.

In general, the operators named in the Functions and Operators spec seem
to operate on values of the datatypes defined by XSD; there are some
functions that take sequences of values as arguments, but no named
operators on sequences of values.

Union, intersection, and set difference on node sequences are not
covered in the F&O spec; unless I have overlooked them, neither are "to"
(as in "1 to 100"), "and", "or", "not", "if" ... "then" ... "else",
"instance of", "treat as", "castable as", "cast as".

These are all keywords in XPath and must be (and are) defined in the
XPath spec.

Perhaps some illogicality arose in the division of labor made when the
detailed documentation of the function library was split off from the
XPath spec into a separate document.  Or perhaps there is a definition
of "operator" somewhere that explains all.

In either case, it doesn't seem quite as accidental as Mike Kay's
self-depreciating account might suggest.

Michael Sperberg-McQueen




> On Mon, Aug 8, 2022 at 10:14 AM Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>  I'm afraid the distribution of text between the various specs often owes
more to the question of who stepped up to do the editorial work than to any
top-down design of the document suite.
>
>  Michael Kay
>  Saxonica
>
>  > On 8 Aug 2022, at 16:54, Norm Tovey-Walsh ndw@xxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>  >
>  > "Eliot Kimber eliot.kimber@xxxxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> writes:
>  >> I was looking in the XPath 3.1 functions and operators docbso I think
>  >> my question still standsbwhy do I not find a definition of the
>  >> intersect operator in the Functions and Operators spec?
>  >
>  > I donbt know if therebs a good editorial reason, or if itbs simply
a
>  > matter of oversight. I donbt think it would have been unreasonable to
>  > expect an bop:intersectb function described in F&O with a pointer
from
>  > the bintersectb operator in XPath to that function. But thatbs not
the
>  > way the XPath spec got written. B/\_(c)_/B/
>  >
>  >> And also why does a google search not find the entry in the XPath
>  >> spec?
>  >
>  > According to a bit of spam that drifted past me today, Google/Alphabet
>  > are engaged in a broad program of mind control over the entire human
>  > race. Perhaps theybre distracted a bit from the search engine business.
>  >
>  >                                        Be seeing you,
>  >                                          norm
>  >
>  > --
>  > Norman Tovey-Walsh <ndw@xxxxxxxxxx>
>  >
https://urldefense.com/v3/__https://nwalsh.com/__;!!N4vogdjhuJM!Hvyteb2R_Tp0L
BssKuvFkM6LY6ql9U2bfUSJJYhwdwSzT1FnCm7wk6xX9_iPp3968teLPjwDvBaPJh48Nlr0su7dni
pxjml4hiZS1XxIhmA$<https://urldefense.com/v3/__https:/nwalsh.com/__;!!N4vogdj
huJM!Hvyteb2R_Tp0LBssKuvFkM6LY6ql9U2bfUSJJYhwdwSzT1FnCm7wk6xX9_iPp3968teLPjwD
vBaPJh48Nlr0su7dnipxjml4hiZS1XxIhmA$>
>  >
>  >> Because things are the way they are, things will not stay the way they
>  >> are.--Bertolt Brecht
>  >


--
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
https://urldefense.com/v3/__http://blackmesatech.com__;!!N4vogdjhuJM!Hvyteb2R
_Tp0LBssKuvFkM6LY6ql9U2bfUSJJYhwdwSzT1FnCm7wk6xX9_iPp3968teLPjwDvBaPJh48Nlr0s
u7dnipxjml4hiZSvwFKjJE$<https://urldefense.com/v3/__http:/blackmesatech.com__
;!!N4vogdjhuJM!Hvyteb2R_Tp0LBssKuvFkM6LY6ql9U2bfUSJJYhwdwSzT1FnCm7wk6xX9_iPp3
968teLPjwDvBaPJh48Nlr0su7dnipxjml4hiZSvwFKjJE$>