[xsl] Re: A proposal:xsl:result-document asynchronous attribute

["Dimitre Novatchev" <dnovatchev@xxxxxxxxx>]

"Francis Norton" <francis@xxxxxxxxxxx> wrote in message
news:3E6CCCC0.5090700@xxxxxxxxxxxxxx
> Hi Jenni,
>
> Jeni Tennison wrote:
>
> >The big problem with using POST in XSLT is that it is neither safe (it
> >may cause changes on the server) nor idempotent (it may return
> >different results each time you make the same request).
> >
> How could xsl:result-document *not* cause changes on the server?
>
> >XSLT and XPath
> >are designed (for the most part; <xsl:message> is the exception) to be
> >side-effect free, such that if you have:
> >
> >  <xsl:variable name="foo">
> >    <xsl:result-document href="foo.html"><foo /></xsl:result-document>
> >  </xsl:variable>
> >
> >it should not matter whether a processor evaluates the content of the
> >$foo variable declaration once or many times -- it should always
> >return the same result.
> >
> I sometimes think that language designs can become fetishistic about
> things like idempotency

Not in the case of a functional language  -- distinguishing between a side
effects - free function and one that has side effects -- here this is a
matter of sanity.

[snip]

> Useful languages end up having to deal
> with things that change state. Even a "purely" functional language like
> Haskell has monads.

The notion of a Monad class is not something belonging just to Haskell -- it
is general and applies to any functional language.


> I think at the very least it would be useful to
> report a success or error on executing the GET, and if you concede even
> that then idempotency has gone for this function.
>
> >Likewise, if you have two instructions, it
> >should not matter which is actually evaluated first (as long as their
> >results are composed in the correct order).
> >
> That's true. I'd say bite this bullet, XSLT would simply document the
> fact that there would be certain cases, for example inside
> xsl:apply-templates or xsl:for-each, where execution order is guaranteed
> to be uncertain and non-portable.

It is exactly the opposite -- it is the norm that the order of execution of
two independent instructions is uncertain (not guaranteed). Exceptions of
this norm must be clearly marked -- hence the "Do notation" in Haskell. Such
exceptions, if not supported by the language standard and not relying on a
sound theoretic basis, would generally be non-portable.

Note that here I'm describing the use of *independent* instructions. Where
there is a dependency (e.g. a variable can be used only in scope), there's
certain order implied. The whole concept of a Monad also uses well-defined
dependencies.



>
> >We *could* manage the multiple-evaluation problem in XSLT in the same
> >way we do for GET by saying that the result of two POST requests with
> >the same URL and deep-equal message bodies must be identical. This
> >would force implementations to cache and reuse the results of each
> >POST. I think that the ordering problem would be harder to manage, and
> >that it's likely to lead to subtle bugs due to different processors
> >following different evaluation orders.
> >
> Or just say that this function is not idempotent. Which, in reality, it
> isn't - you might get a time-out one time and success the next.

Just to say that a function has side effects is not sufficient. There must
be good mechanisms that support the use of functions with side effects,
otherwise the result of evaluation will be unpredictable.

This is where the Monad implementation *is necessary*.

It is possible to implement (something like) a general Monad in XSLT if
there are higher order functions and at least some kind of primitive
controlled lazy evaluation.

Such an implementation has been produced using FXSL. It provides a reliable
way of dealing with functions with side effects.

[snip]

> >To summarise: if you're GETting, use document(); if you're POSTing,
> >you shouldn't be doing so within XSLT because it's not safe or
> >idempotent and therefore undermines the side-effect-free nature of
> >XSLT.
> >
> >
> I think there comes a time when you should draw a line and say there's a
> useful, stateful XML world out there and we should find as clean a way
> as possible to let XSLT users interact with it.

While this sounds like a justified remark, it remains simply wishful
thinking if proper mechanisms to ensure reliable and predictable use of
functions with side effects are not in place.


It is highly unlikely that XSLT 2.0 will offer such a mechanism, as it lacks
standard support for higher-order functions.

For the time being such support will be provided by the FXSL monadic
implementation.

Before publishing the initial implementation I'm trying to collect a number
of good-use examples, like maintaining state, update-in-place Arrays, IO
from external files, synchronous exceptions.

I would greatly appreciate any other suggestions of possible use of a
monadic implementation from interested users.



=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list