Re: Fwd: Pattern matching error in xsl:key

Chapman Flack <chap-JULfBfA8satPFr4CO1/[email protected]> Sun, 6 Sep 2020 16:22:50 -0400
Newsgroups gmane.text.xml.saxon.help,gmane.text.xml.xsl.general.mulberrytech
Message-ID <[email protected]>
On 09/06/20 15:03, Ihe Onwuka wrote:
>> Maybe you would find XML Query more to your liking?
> ......what I posted earlier about offering patronising explanations.

It was offered as a straight suggestion. There are two very closely related
languages with very similar capabilities, and one of them is free of the
property you don't like.

I will freely admit that I too find XML Query more comfortable to read and
to write, for some of the same reasons; I generally write XSLT only when
some external constraint makes it necessary, or when it is clearly better
suited to a particular task.

When I do (have to) write XSLT, I do spend time double checking where things
represent data and where they represent code. But I understand it was a
deliberate design objective that XSLT be itself represented as XML, and
the fact that the same lexical XML can be code in some cases and not in
others is a consequence of that, and I just need to know which cases are
which.

If you say in JavaScript:

  '4.0'.endsWith(eval('4.0'))

the result is false. Both strings here have the same lexical form; the
second one has to be understood as code, because it occurs inside eval().
You know that because you know how eval() works, not because the string
looks different. There, too, you can add quotes and

  '4.0'.endsWith(eval('"4.0"'))

will be true. In XSLT you know the select='4.0' in a <param> represents
code, because you know how <param> works.

Compared to JavaScript, XSLT gives you more choices how you could rearrange
that to express most precisely what you mean. Among

<param name='source' select='"4.0"'/>
<param name='source' as='xs:string'>4.0</param>
<param name='source' select='4.0 cast as xs:string'/>

the first two give you the same result, with the second one arguably
expressing the intent more clearly; the third would give a result you
don't want in this case, but could be the clearest way to express
intent in some other case where that was the wanted behavior.

It seems to me that the object of the game in any language is, ok, if
I am going to write this thing in language X for whatever reason, how
do I use the features of language X to express the intent as clearly
as I can?

Getting back to the original intent you were trying to express, this
thread has presented some workable and clear ways to express it.

Regards,
-Chap