Re: [xsl] Random UUID in pure XSLT?

Subject: Re: [xsl] Random UUID in pure XSLT?
From: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 11 Nov 2020 21:53:41 -0000
>  Dimitre, I don't know! XSLT too can be beautiful in its way don't you
think?

Absolutely, however when solving a non-XML-processing problem, using XPath
(a functional, expression language) seems much more elegant to me.

A matter of taste, of course.

Cheers,
Dimitre

On Wed, Nov 11, 2020 at 1:35 PM Wendell Piez wapiez@xxxxxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Dimitre, I don't know! XSLT too can be beautiful in its way don't you
> think?
>
> Cheers, Wendell
>
> On Wed, Nov 11, 2020 at 4:12 PM Dimitre Novatchev dnovatchev@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> Hi Wendell,
>>
>> > Meanwhile an XSLT implementation of UUID v4 was not as fearsome as I
>> had supposed it would be. (We'll see how it stands up.)
>>
>> I would aim at a pure XPath implementation, XSLT is not interesting
>> enough p
>>
>> Thanks,
>> Dimitre
>>
>>
>> On Wed, Nov 11, 2020 at 1:06 PM Wendell Piez wapiez@xxxxxxxxxxxxxxx <
>> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>> Hi Dimitre,
>>>
>>> Yes indeed and I am glad to have all of these in the kit.
>>>
>>> This would be a much simpler question if I could guarantee anything
>>> about the users ... however not only may they be unable to call Java,
they
>>> might also be off line at runtime. So I have to be able to offer options.
>>>
>>> Meanwhile an XSLT implementation of UUID v4 was not as fearsome as I had
>>> supposed it would be. (We'll see how it stands up.)
>>>
>>> Thanks again,
>>> Wendell
>>>
>>>
>>> On Wed, Nov 11, 2020 at 3:35 PM Dimitre Novatchev dnovatchev@xxxxxxxxx <
>>> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>>> Hi Wendell,
>>>>
>>>> Dimitre, suggesting the web service option, offers
>>>>
>>>> > for $i in 1 to $N
>>>> >    return  unparsed-text("https://uuidgen.org/api/v/4";)
>>>> >
>>>> > I'll try this ... but what prevents an XSLT engine giving me the same
>>>> result each time? (Oh I see.)
>>>>
>>>> Dr. Kay suggested a fix that will block the deterministic-compliance
>>>> attempts of a hypothetical XPath 3.0+ (or XSLT 2.0) implementation;
>>>>
>>>> for $i in 1 to 100
>>>>   return unparsed-text(concat("https://uuidgen.org/api/v/4?x=";, $i))
>>>>
>>>>
>>>> I say "hypothetical" above, because even Saxon (the 9.9.1.7 versions
>>>> used in Oxygen) is non-compliant and produces all-different results for
>>>> this transformation:
>>>>
>>>> <xsl:stylesheet version="3.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
>>>>   <xsl:output method="text"/>
>>>>
>>>>   <xsl:template match="/">
>>>>     <xsl:sequence select=
>>>>       "for $i in 1 to 100
>>>>          return unparsed-text('https://uuidgen.org/api/v/4')"/>
>>>>
>>>>   </xsl:template></xsl:stylesheet>
>>>>
>>>>
>>>> Interestingly, I have an old version: Saxon 9.1.01, which is compliant
>>>> to the XSLT 2.0 specification and needs the URL-tail addition in order
to
>>>> get its determinism bypassed.
>>>>
>>>> HTH, Dimitre
>>>>
>>>>
>>>> On Wed, Nov 11, 2020 at 12:19 PM Wendell Piez wapiez@xxxxxxxxxxxxxxx <
>>>> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Dimitre, suggesting the web service option, offers
>>>>>
>>>>> for $i in 1 to $N
>>>>>    return  unparsed-text("https://uuidgen.org/api/v/4";)
>>>>>
>>>>> I'll try this ... but what prevents an XSLT engine giving me the same
>>>>> result each time? (Oh I see.)
>>>>>
>>>>> Update since yesterday -- I've had some apparent success coding up an
>>>>> implementation of UUID v4 using fn:random-number-generator() ... results
so
>>>>> far are here (comments welcome):
>>>>>
>>>>>
>>>>>
https://github.com/wendellpiez/oscal-tools/blob/issue10-uuid-util/xslt/uuid/r
andom-util.xsl
>>>>>
>>>>> The functions are deterministic -- they return the same UUID (or UUID
>>>>> sequence of specified length) for the same seed. In my application, this
is
>>>>> actually a feature.
>>>>>
>>>>> Thanks for all the info and help so far this is great!
>>>>>
>>>>> Cheers, Wendell
>>>>>
>>>>> On Wed, Nov 11, 2020 at 1:32 PM Dimitre Novatchev dnovatchev@xxxxxxxxx
>>>>> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>>>
>>>>>> >  how can I go about producing random UUIDs, in dozens or hundreds,
>>>>>> inside an XSLT pipeline, without extension functions in Saxon.
>>>>>>
>>>>>> This is actually very easy and doesn't require the use of any
>>>>>> extension functions:
>>>>>>
>>>>>> *unparsed-text("https://uuidgen.org/api/v/4
>>>>>> <https://uuidgen.org/api/v/4>")*
>>>>>>
>>>>>> or if you need N of them:
>>>>>>
>>>>>> *for $i in 1 to $N*
>>>>>> *   return  unparsed-text("https://uuidgen.org/api/v/4
>>>>>> <https://uuidgen.org/api/v/4>") *
>>>>>>
>>>>>>
>>>>>>
>>>>>> p
>>>>>>
>>>>>> HTH, Dimitre
>>>>>>
>>>>>> On Tue, Nov 10, 2020 at 8:36 AM Piez, Wendell A. (Fed)
>>>>>> wendell.piez@xxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>>> XSL Friends b
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Today I write from the day job, where I am researching the question
>>>>>>> of how can I go about producing random UUIDs, in dozens or hundreds,
inside
>>>>>>> an XSLT pipeline, without extension functions in Saxon. The Java
>>>>>>> randomUUID() function works nicely when itbs available, but I need
to
>>>>>>> distribute the capability for SaxonHE and eventually SaxonJS.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We do not have an available implementation of RFC 4122 v4 brandom
>>>>>>> UUIDb in pure XSLT do we, free to use (and study)? I know the
functional
>>>>>>> nature of the language makes randomness, um, problematic (when isnbt
it?),
>>>>>>> which sometimes means workarounds b thatbs all fine. Indeed so
would
>>>>>>> calling out to a web service if it is known to be reliable. I have
thought
>>>>>>> about handing a list of UUIDs in at runtime, but as I said, there may
>>>>>>> sometimes be hundreds and perhaps thousands, which makes that approach
seem
>>>>>>> a bit scary.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Any thoughts or perspective would be most welcome.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks, Wendell
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
>>>>>>> EasyUnsubscribe
>>>>>>> <http://lists.mulberrytech.com/unsub/xsl-list/782854> (by email)

Current Thread