[xsl] Re: Thoughts about the "Asynchronous XSLT"

Subject: [xsl] Re: Thoughts about the "Asynchronous XSLT"
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 1 Aug 2020 07:43:53 -0000
Thanks for the suggestion, I will certainly look into this.

My  instinct to use promises was because we're primarily interested in
retrieving external resources, which is inevitably done by calling out to
Javascript APIs, and most of those APIs these days manage the asynchrony using
JavaScript promises.

Michael Kay
Saxonica

> On 1 Aug 2020, at 04:08, Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
>
> First of all, congratulations to the Balisage organizers for organizing this
conference even in the current situation.
>
> I read Dr. Kay's paper "Asynchronous XSLT" from the proceedings of
Balisage-2020:
https://www.balisage.net/Proceedings/vol25/html/Kay01/BalisageVol25-Kay01.html
<https://www.balisage.net/Proceedings/vol25/html/Kay01/BalisageVol25-Kay01.ht
ml>
>
> While the described new feature (promises) is impressive and will be a step
in the right direction, people who have used both promises and reactive
extensions (RxJs in particular, a Javascript implementation of Reactive
Extensions:  http://reactivex.io <http://reactivex.io/languages.html> ) point
out certain advantages of using Rx observables over promises:
> Promises produce only one event; Observables produce a stream of events.
> Promises are not lazy; Observables do not fire even after being created,
they start emitting the event stream only upon subscription.
> Working with nested and interdependent promises can be cumbersome and
unwieldy; Much easier and structured when expressed and handled with
observables.
> Promises, once started, cannot be cancelled; Observables were designed
having cancellation in mind.
> Shall we mention multicasting ...
> Here is a brief video that shows this in running code:
https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises
<https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises>
>
> The reason for my message is that it is still not too late to make an
informed design decision that takes into consideration the established best
approach towards implementing the handling of asynchrony in almost all major
programming languages, and, to have a written evidence that this problem had
at least been raised and (hopefully) discussed.
>
> To quote http://reactivex.io/languages.html
<http://reactivex.io/languages.html> , Rx has been implemented in these
languages, platforms and frameworks:
> Languages
> Java: RxJava <https://github.com/ReactiveX/RxJava>
> JavaScript: RxJS <https://github.com/ReactiveX/rxjs>
> C#: Rx.NET <https://github.com/Reactive-Extensions/Rx.NET>
> C#(Unity): UniRx <https://github.com/neuecc/UniRx>
> Scala: RxScala <https://github.com/ReactiveX/RxScala>
> Clojure: RxClojure <https://github.com/ReactiveX/RxClojure>
> C++: RxCpp <https://github.com/Reactive-Extensions/RxCpp>
> Lua: RxLua <https://github.com/bjornbytes/RxLua>
> Ruby: Rx.rb <https://github.com/Reactive-Extensions/Rx.rb>
> Python: RxPY <https://github.com/ReactiveX/RxPY>
> Go: RxGo <https://github.com/ReactiveX/RxGo>
> Groovy: RxGroovy <https://github.com/ReactiveX/RxGroovy>
> JRuby: RxJRuby <https://github.com/ReactiveX/RxJRuby>
> Kotlin: RxKotlin <https://github.com/ReactiveX/RxKotlin>
> Swift: RxSwift <https://github.com/kzaher/RxSwift>
> PHP: RxPHP <https://github.com/ReactiveX/RxPHP>
> Elixir: reaxive <https://github.com/alfert/reaxive>
> Dart: RxDart <https://github.com/ReactiveX/rxdart>
> ReactiveX for platforms and frameworks
> RxNetty <https://github.com/ReactiveX/RxNetty>
> RxAndroid <https://github.com/ReactiveX/RxAndroid>
> RxCocoa <https://github.com/kzaher/RxSwift>
> .
> Why don't we make XSLT part of this large family, where all developers
already know, use and understand the functions and operators, and will be able
with minimum effort to also use the same in XPath/XSLT?
>
> Or is this really challenging because of existing inherent problems in
XSLT?
>
> --
> Cheers,
> Dimitre Novatchev
> ---------------------------------------
> Truly great madness cannot be achieved without significant intelligence.
> ---------------------------------------
> To invent, you need a good imagination and a pile of junk
> -------------------------------------
> Never fight an inanimate object
> -------------------------------------
> To avoid situations in which you might make mistakes may be the
> biggest mistake of all
> ------------------------------------
> Quality means doing it right when no one is looking.
> -------------------------------------
> You've achieved success in your field when you don't know whether what
you're doing is work or play
> -------------------------------------
> To achieve the impossible dream, try going to sleep.
> -------------------------------------
> Facts do not cease to exist because they are ignored.
> -------------------------------------
> Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)
> -------------------------------------
> Sanity is madness put to good use.
> -------------------------------------
> I finally figured out the only reason to be alive is to enjoy it.

Current Thread