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

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

I for one very much appreciate the examplesthey make the standard useable for
me as a ready reference for how to apply specific features in the moment when
Im like how do I do this thing I do once a year again?

For a niche standard like XSLT or XPath or XQuery I think this is especially
important because I cant just google and expect to find a reliable answer on
Stack OverflowIll find answers but few are reliable. So being able to go to
the spec is of tremendous value.

I also know from my work on the DITA standard how challenging it is to create
and maintain good examplesits a major source of effort.

So I for one am very grateful to Mike and whole team of editors who have put
so much effort into making these standards so useful.

I also stopped having patience with the standard is too long arguments a
decade agoits just not a useful or relevant measure when everything is
available online.

The OOXML standard is 5000+ page. It is also an essential reference that I use
(or have used) almost every day. Would I ever print those pages? Never. Does
it matter that its so big? No. I can open it in Acrobat and search it
effectively. It has the information I need and thats all that matters.

The important measure, I think, is are there enough words to make the
normative statements clear and precise and can the intended audience
reasonably understand the rules? along with does this standard have all the
features it should have and no features it should not have?

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: Michael Kay mike@xxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wednesday, August 10, 2022 at 4:15 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [xsl] Where is 'intersect' Operator Defined in XPath 3?
[External Email]


>
> But mostly, it tells me that the editor of XSLT 3.0 was consistently
> more careful to be explicit about corner cases than the editor of XSLT
> 1.0.
>

Sometimes this results from including explicit text as an aid to the reader,
sometimes because it is logically necessary.

Consider normalize-space() as an example. This expands from 3 lines in 1.0 to
30 lines in 3.0

In 1.0 the specification reads:

<quote>
The normalize-space function returns the argument string with whitespace
normalized by stripping leading and trailing whitespace and replacing
sequences of whitespace characters by a single space. Whitespace characters
are the same as those allowed by the S production in XML. If the argument is
omitted, it defaults to the context node converted to a string, in other words
the string-value of the context node.
</quote>

In 3.0 the normative part of the specification reads:

<quote>
If the value of $arg is the empty sequence, the function returns the
zero-length string.
</quote>

<remark>XPath 1.0 relies on you knowing the general rules for conversion of
supplied arguments to the required type. A specific rule becomes necessary in
2.0 because many functions adopt a different convention, where supplying an
empty sequence causes an empty sequence to be returned</remark>

<quoteThe function returns a string constructed by stripping leading and
trailing whitespace from the value of $arg, and replacing sequences of one or
more adjacent whitespace characters with a single space, #x20.</quote>

<remark>Very similar to the 1.0 text, but note for example the replacement of
"sequences of whitespace characters" with the rather more pendantic "sequences
of one or more adjacent whitespace characters".</remark>

<quote>The whitespace characters are defined in the metasymbol S (Production
3) of [Extensible Markup Language (XML) 1.0 (Fifth Edition)].</quote>

<remark>Again: the 1.0 text with a little bit more precision</remark>

<quote>If no argument is supplied, then $arg defaults to the string value
(calculated using fn:string) of the context item (.). </quote>

<remark>Very similar to the 1.0 text</remark>

<quote>Error Conditions
If no argument is supplied and the context item is absentDM31 then a dynamic
error is raised: [err:XPDY0002]XP31.
</quote>

<remark>This is a new addition, because the error condition could not arise in
XPath 1.0</remark>

So, the normative text has expanded, on my reckoning, from 63 to 102 words,
mainly in the interests of greater precision and clarity, partly dealing with
conditions that could not arise in 1.0.

The main part of the expansion from 3 lines to 30 is thus in the addition of
material that is technically redundant: mainly examples and notes.

Now it's an open question how much of such redundant explanatory material the
specification should include. What I find hard to understand is where people
(specifically Dimitre) complain at the same time that there is too much of
such material, and too little. It's hard to find a balance that pleases all
readers, but it ought to be possible to find a balance that pleases one -
unless his desiderata are internally inconsistent.

Michael Kay
Saxonica