Re: Random UUID in pure XSLT?

>  I don't know how FP purists model this, but it seems to me that the
content of a web page is a function of two things: the URL, and the time

This is the view of the *InternetArchive* <https://archive.org/web/>, but
this is also too simplistic. What about load-balancers, caches and
replicas, just to name a few? It is possible that two instances of the same
Http request, issued at the same moment may result in different responses,
based on the issuer's location, topology of the network (routers etc.), the
decision of the load balancer, the existence of mirror-sites, the state of
database (backups and restores), ..., etc., etc...

The fact that the relationship (excluding time and other factors, to make
it as simple as possible) URL ==> Response is not a 1:1 relationship, means
that there are classes of equivalence (of URLs) such that for any URL
belonging to a given class of equivalence, the response is the same.

We are not to know, generally, what exactly these classes are -- this is
the hidden semantics of the designated Http resource.

Isn't trying to produce a deterministic SendHttpRequest function, just
wishful thinking?

Cheers,
Dimitre

On Wed, Nov 11, 2020 at 2:35 PM Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> I don't know how FP purists model this, but it seems to me that the
> content of a web page is a function of two things: the URL, and the time.
> So probably we should be treating unparsed-text() as if there is an
> implicit parameter timestamp() which is potentially different on each call;
> though since order of execution is unpredictable, forcing the calls to
> happen at different times still requires some sleight-of-hand.
>
> Where are the theorists when we need them?
>
> Michael Kay
> Saxonica
>
> On 11 Nov 2020, at 22:03, Dimitre Novatchev dnovatchev@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > According to the spec, unparsed-text() is deterministic, which means
> that two calls with the same argument should return the same result. You're
> relying on a Saxon non-conformance, I fear!
>
> It seems to me that tagging the function unparsed-text() as
> "deterministic" was rather inaccurate... And definitely not useful, if we
> need hacks as workarounds for its limitations...
>
> Generally, determinism can have meaning within a closed system, the system
> of Internet Http resources is an open one.
>
> Thus, the Saxon non-conformance for me is a feature, not a bug!
>
> Cheers,
> Dimitre
>
>
>
>> According to the spec, unparsed-text() is deterministic, which means that
>> two calls with the same argument should return the same result. You're
>> relying on a Saxon non-conformance, I fear!
>>
>> Except that if you make the call in a loop, Saxon will probably loop-lift
>> it, thus becoming conformant and making your code deliver a stream of
>> identical UUIDs.
>>
>> You can probably get round it by using
*unparsed-text("https://uuidgen.org/api/v/4
>> <https://uuidgen.org/api/v/4>?x=" || position())*
>>
>> Michael Kay
>> Saxonica
>>
>> On 11 Nov 2020, at 18:32, 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)