Re: Random UUID in pure XSLT?

"Dimitre Novatchev [email protected]" <[email protected]>
Newsgroups gmane.text.xml.xsl.general.mulberrytech
Message-ID <[email protected]>
>  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 [email protected] <
[email protected]> 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 [email protected] <
> [email protected]> 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 😆
>>
>> Thanks,
>> Dimitre
>>
>>
>> On Wed, Nov 11, 2020 at 1:06 PM Wendell Piez [email protected] <
>> [email protected]> 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 [email protected] <
>>> [email protected]> 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 [email protected] <
>>>> [email protected]> 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/random-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 [email protected]
>>>>> <[email protected]> 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>") *
>>>>>>
>>>>>>
>>>>>>
>>>>>> 😆
>>>>>>
>>>>>> HTH, Dimitre
>>>>>>
>>>>>> On Tue, Nov 10, 2020 at 8:36 AM Piez, Wendell A. (Fed)
>>>>>> [email protected] <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> XSL Friends –
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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 it’s available, but I need to
>>>>>>> distribute the capability for SaxonHE and eventually SaxonJS.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We do not have an available implementation of RFC 4122 v4 “random
>>>>>>> UUID” in pure XSLT do we, free to use (and study)? I know the functional
>>>>>>> nature of the language makes randomness, um, problematic (when isn’t it?),
>>>>>>> which sometimes means workarounds – that’s 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)
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/3329386
or by email: [email protected]
--~--
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.