Re: [Xsltforms-support] Evaluating long calculations asynchronously in background

[Mats E. <mat...@li...>]

Hi Alain,
Thanks for your feedback!
> XSLTForms supports xf:setnode as an extension. So, with both
    xf:setvalue and xf:setnode, at first glance, I prefer a
    @mode="synchronous/asynchronous" implementation (as in
    xf:submission).
One of the advantages I saw with the xf:submission + proxied XMLHttpRequest option is the submission-done notification event, which allows chaining subsequent actions. I now realize however, that a similar notification event is triggered by the xf:insert action (xforms-insert), so if the @asynchronous attribute could be applied on this action, the extension attribute approach would probably be the more interesting option. Furthermore, it looks like both xf:setvalue and xf:setnode could be replaced by an xf:insert action if the XPath 3.0 functions fn:parse-xml() and fn:parse-xml-fragment() were available in XLSTForms (for use in the xf:insert/@origin attribute), in cases where the notification event is important. This seems doable as well...
> I have not been working with Web Workers yet but I read that there
    are limitations like these. XSLTForms already has its own XPath
    engine but is currently using native XML engines (an independent XML
    engine, fully written in Javascript, is already in good progress!).
    Why do you think that XSLT would also be required or is just it that
    XSLT would be nice to have available too?
Concerning XSLTProcessor, large XSLT transforms can be long running so it would be nice if such could be run in a background thread. Furthermore, the transform() xpath function is already part of the XSLTForms core function library, and I'm thinking this entire library should ideally be available also in the web worker context. I see there are some javascript implementations of XSLTProcessors on the web (not sure if Saxon CE is possible to use -- I'm trying to clarify). 
By the way, which XML DOM level is required by XSLTForms' XPath implementation for navigating on XForms instance documents, do you know? So far it looks like the browsers' native XML DOM Parser is not available in web worker context...
      
/ Mats