Gary, My perspective as an XForms user: XQuery is designed for querying and working with document structures, which makes it a great fit for declarative client-side DOM manipulation--as I recall, the XQuery implementation in Fleur.js lets users manipulate the HTML5 DOM directly (even though it's not well-formed XML). XQuery is a superset of XPath, so client-side XQuery is the pathway to adding support for XPath 3.0 and XForms 2.0 features to XSLTForms.
Tim -- Tim A. Thompson Metadata Librarian Yale University Library On Tue, Mar 30, 2021 at 2:00 PM Gary Kopp <[email protected]> wrote: > Thanks, Alain. Your explanation is very helpful, and thought-provoking. I > imagine other new outsiders will also find it helpful. > > > > A question, if you will indulge someone that doesn’t fully understand the > XForms technology landscape yet. Why do we need a new XQuery engine? I > believe XQuery on the server side is already well supported (but I could be > misunderstanding something). It seems Fleur.js will allow also XQuery on > the browser side, but I personally don’t see a use case for that. I’m sure > I’m missing something… > > > > --Gary > > > > *From:* Alain Couthures <[email protected]> > *Sent:* Tuesday, March 30, 2021 11:20 AM > *To:* Gary Kopp <[email protected]>; > [email protected] > *Subject:* Re: [Xsltforms-support] Declarative4all Overview? > > > > When developing web applications, XForms, because it has been specified to > be implemented in browsers, is not enough. > > > > XSLTForms is a client-side XForms implementation using XSLT 1.0 as a trick > to transform XForms pages into HTML pages with CSS and Javascript. It works > within browsers... > > > > XSLT 1.0 is still supported in major browsers, but vendors would like to > get the corresponding memory space for new features instead... XSLTForms > must evolve... > > > > Since 1.5, XSLTForms uses its own HTML5 notation for XForms. It allows > authors, if they prefer this, to write forms directly without the XSLT step > being required, which, is now also available in Javascript for Nodejs! BTW, > Cordova supports this HTML5 notation, too. > > > > The XPath engine of XSLTForms is also evolving. The corresponding parser > has been rewritten from XSLT 1.0 to Javascript. This parser has been > extended to support XQuery 3.1. Then, a new XQuery engine has been created, > named Fleur.js, for both browsers and Nodejs. > > > > We, also, have Nodejs to easily develop and run light HTTP servers. It > allows XQuery at server-side (with Fleur.js) to access files, query other > web servers, ... and XForms at client-side (with XSLTForms) to render and > modify data. > > > > Next step: Fleur.js for XSLTForms is now in alpha... > > > > So, Declarative4all is a project to host all that stuff and more... It is > the not-private part of the dev environment, actually... > > > > --Alain > > Le 29/03/2021 20:22, Gary Kopp <[email protected]> a écrit : > > > > > > I’m new to XForms with eXist and quickly realized I needed XSLTForms to > get started. I found XSLTForms 1.3 on Github and thought I was done, > although I was concerned that it hadn’t been updated for years. Then I was > given a link to Declarative4all and now see that XSLTForms is alive and > quite well. But I’m a little confused – is Declarative4all just an > xsltforms.js upgrade, or is there more to it from a functional standpoint? > Is there a summary statement somewhere of what Declarative4all actually is? > > > > --Gary Kopp > > _______________________________________________ Xsltforms-support mailing > list [email protected] > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > > _______________________________________________ > Xsltforms-support mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xsltforms-support >
_______________________________________________ Xsltforms-support mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xsltforms-support
