Re: Random UUID in pure XSLT?

"Wendell Piez [email protected]" <[email protected]>
Newsgroups gmane.text.xml.xsl.general.mulberrytech
Message-ID <[email protected]>
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 [email protected] <
[email protected]> 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 <[email protected]>
> 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/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.