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(_at_)wendellpiez(_dot_)com
<
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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(_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/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
--~--