Re: [xsl] XSLT 2.0 courses?

Subject: Re: [xsl] XSLT 2.0 courses?
From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 21 Sep 2020 15:37:28 -0000
David,

Yup, just like ($a,$b,$c)[1]. Not thinking of the "return all of $a"
problem.

For that I might (today) write

( ($a[1] ! $a), ($b[empty($a)][1] ! $b), ($c[empty(($a,$b))][1] ! $c) )

although not before thorough testing, and since it fails the clarity test
it would have to be commented with a short essay ... so I might also use
if/then/else, or XSLT.

Cheers, Wendell



On Mon, Sep 21, 2020 at 10:17 AM David Carlisle d.p.carlisle@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
>
> On Mon, 21 Sep 2020 at 15:08, Wendell Piez wapiez@xxxxxxxxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> Hi,
>>
>> Aside from the name question (I'd maybe like first-available()?) the
>> question arises, what would be the difference between
>> first-defined(($a,$b,$c)) and head(($a,$b,$c)) or ($a,$b,$c) => head() as
>> the case may be?
>>
>
> It would need to be an overloaded function like concat taking any number
> of arguments so first-defined($a,$b,$c)  if you ,-join the lists first you
> no longer can return $a if non empty,  head(($a,$b,$c)) is the head of the
> sequence ($a,$b,$c) which is the flattened sequence of items from $a $b and
> $c so would just return the first item in $a not all of $a.
>
> David
>
>
>
>
>> Cheers, Wendell
>>
>>
>> On Mon, Sep 21, 2020 at 9:41 AM Graydon graydon@xxxxxxxxx <
>> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>> On Mon, Sep 21, 2020 at 01:25:56PM -0000, Chris Papademetrious
>>> christopher.papademetrious@xxxxxxxxxxxx scripsit:
>>> > Good point. Perhaps this could be handled by chaining them?
>>> >
>>> > $a otherwise $b otherwise $c otherwise $default
>>>
>>> I think "otherwise" is fine for the pair case!
>>>
>>> It's clearer and easier to read than ($a,$b)[1] and it'll be easier to
>>> search for in documentation.
>>>
>>> Chaining otherwise as you propose doesn't strike me as clearer or easier
>>> to read; the location of the implicit parentheses is extremely important
>>> in that example and as soon as the values are the least bit complex all
>>> the parens will likely need to be made explicit.
>>>
>>> On the other hand, we've already got a concept of sequence, and commas,
>>> so ($a,$b,$c,$default) => first-defined()
>>>
>>> strikes me as clearer and easier to read than chaining "otherwise".
>>> Could even add a two-parameter version so the second parameter defines
>>> how to handle values which are false(). :)
>>>
>>> --
>>> Graydon Saunders  | graydonish@xxxxxxxxx
>>> CC&s oferC)ode, C0isses swC! mC&g.
>>> -- Deor  ("That passed, so may this.")
>>>
>>>
>>
>> --
>> ...Wendell Piez... ...wendell -at- nist -dot- gov...
>> ...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
>> ...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...
>> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
>> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/2739265> (by
>> email)
>>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/174322> (by
> email <>)
>


--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...

Current Thread