[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Random UUID in pure XSLT?

Subject: Re: Random UUID in pure XSLT?
From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 12 Nov 2020 20:33:30 -0000
Re:  Random UUID in pure XSLT?
Hi,

Norm has it right (I think) that following this rule and being able to
trust that a processor should follow this rule (even when it does not), is
an important stabilizing factor in XSLT development, enabling a very useful
separation of concerns whose boundaries run close to the governance
boundaries (who is actually in control of which data set).

And like David I worry what about when the scoping of variables and
parameters becomes an issue in determining what should be at the end of a
URI, whether it is the same, and whether I should care how many times a
processor makes an attempt on it.

As far as the theory goes, I think Dimitre put his finger on it when he
pointed out the distinction between a closed system and an open one. To
what Norm and Dave have said, I think XSLT has been very well served by
maintaining this "closed universe" fiction. Indeed as Dave P has also
hinted, such a regimen of
data control (in which data that is not controlled, is at least well
understood) is more or less essential to a scalable publishing operation.

This all leads me to think that a non-deterministic fn:refresh-document()
function might be useful in certain circumstances, but that we would be
well advised to leave the plain-vanilla document() function (and its ilk
such as doc() and unparsed-text()) deterministic. They are already a way of
sneaking external state into the transformation. (As such, very useful.
Does my Schematron find my listing in the bibliography feed *today*?) I'd
like to keep it easy to observe those boundaries.

Cheers, Wendell










On Thu, Nov 12, 2020 at 11:39 AM Norm Tovey-Walsh ndw@xxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> > I don't expect that anyone wrote XSLT code that relies on these functions
> > being deterministic.
>
> I would be very reluctant to endorse that claim. I have relied on this
> *all the time* in as much as Ibve never given a moment of thought to
> whether or not fn:doc() could possibly return a different answer because
> I know I donbt have to.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Tovey-Walsh <ndw@xxxxxxxxxx>
> https://nwalsh.com/
>
> > Mistakes are a part of being human. Appreciate your mistakes for what
> > they are: precious life lessons that can only be learned the hard way.
> > Unless it's a fatal mistake, which, at least, others can learn
> > from.--Al Franken
>



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

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.