[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: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 13 Nov 2020 01:47:31 -0000
Re:  Random UUID in pure XSLT?
> 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.

Good thoughts, Wendell,

What about stock exchange data, where the price and other values change
several times per second? Are we limited (or limiting ourselves) to the
static web resources typical at the time XSLT 1.0 was produced (1999) ? Or
are we embracing the reality of our time?

There are two approaches for capturing real data: pull and push.

With pull, we must know how often the data changes and initiate a new
request for every time interval passed.

With push, we let someone who pulls or produces the data send us the new
data every time it changes or every time an interval elapses and there had
been change -- so this would be very much like streaming, where the item
that is streamed is the latest, up-to-date version of the data we are
subscribed for.

More than 5 years ago I was working at an organization that had implemented
and was successfully using the pull strategy for several dozens of XML data
sources.
Nowadays we have standard implementations of the Observable/Observer (also
publish/subscribe) pattern and related pattern-matching and operators on
streams of events, such as the Reactive Extensions (think Rx.Net, RxJS,...,
etc).

So, the question is not whether the data produced by an Http resource is
static or changing -- it is rather:
*How frequently the data changes, and what is a good strategy to react to
these changes (sync vs. async)*

Thanks,
Dimitre

On Thu, Nov 12, 2020 at 12:33 PM Wendell Piez wapiez@xxxxxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> 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...
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/782854> (by
> email <>)

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.