|
Re: [xsl] Random UUID in pure XSLT?
2020-11-11 15:53:46
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(_at_)wendellpiez(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_at_)gmail(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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
wapiez(_at_)wendellpiez(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_at_)gmail(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_at_)wendellpiez(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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
dnovatchev(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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)
wendell(_dot_)piez(_at_)nist(_dot_)gov
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
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/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--
|
|