xsl-list
[Top] [All Lists]

Re: [xsl] Random UUID in pure XSLT?

2020-11-12 14:33:45
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(_at_)nwalsh(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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 I’ve never given a moment of thought to
whether or not fn:doc() could possibly return a different answer because
I know I don’t have to.

                                        Be seeing you,
                                          norm

--
Norman Tovey-Walsh <ndw(_at_)nwalsh(_dot_)com>
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...
--~----------------------------------------------------------------
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
--~--
<Prev in Thread] Current Thread [Next in Thread>