search

wendellpiez / XMLLunchbox

Develop, package and deliver an XML application on BaseX, with Saxon, in a Docker container: RestXQ over XQuery, with XSLT 3.0 anywhere
The Unlicense
12 stars 2 forks source link

What is XSLT doing in the LunchBoX? #3

Open ebeshero opened 5 years ago

ebeshero commented 5 years ago

The README makes interesting comments about relationships between XQuery and XSLT that it might explicate with greater clarity. The point of the experiment seems to be that XSLT is doing some hard work on top of comparatively simple XQuery expressions: "These little XQueries are easy to write - especially if all the logic happens in an XSLT you call out to. The combination has all the flexibility and power of XML, XSLT and XQuery working together and complementing each other."

Can you/we provide a bit of overview on the kind of XSLT you imagine running to complement the XQuery, and a scenario where this might be useful?

djbpitt commented 5 years ago

@ebeshero @wendellpiez In MVC terms, do we think of the XML as the model, XQuery as the controller, and XSLT as managing the view?

wendellpiez commented 5 years ago

@ebeshero I think different developers will have different takes on when to use XQuery and when to use XSLT. It might be there are no correct answers. I could offer some guidelines to describe when I -- an XSLT expert -- will turn to XSLT instead of XQuery -- whenever XSLT is easier and/or more graceful, is my answer, but this just goes to show the assessment is very relative. For me, XSLT will exert its considerable attractions sooner than for many others. (Or maybe I just know how good it can really be.) Some people like XQuery and there is nothing wrong with that. (And admittedly there are some sorts of things - typically the simpler things - for which it can be quite elegant -- while for all of its inner elegance, XSLT can be very verbose and 'ceremonious'.)

So the answer is, yes, but it probably requires a wiki page or a similar softer approach rather than making the readme more complex. Were that in place (maybe you could frame something up?) I could probably add to it.

As for MVC, I would describe the XML as the model, the web facing HTML as the view, and the XSLT/XQuery together as the controller. However, since there are subpipelines, this same architecture is replicated at lower levels (within/between phases of XML processing), so for example the I Ching transformation goes through several model-to-view steps where each view is a model for the next step.

Because the XSLT calls are embedded in XQuery, it makes sense to think of entire XSLT transformations as functions from the XQuery point of view -- typically filters or mappers or filter-mappers together (or filter-mapper-sorters etc). You pass trees of XML to these functions and you get trees of XML back. And because the XQuery environment holds all of it in memory, you have a great deal of flexibility on how you then work it. (So, models and views together make new views, which become new models.)

All of this goes considerably beyond the little demos, but this architecture is capable of much more. :-)

ebeshero commented 5 years ago

@wendellpiez I'd be happy to try to envision how the two might fit together optimally. I learned both of these from @djbpitt and I'm grateful now to be relatively "ambidexterous" as others I know tend strongly to favor XSLT or only do XQuery for everything. One of things we might experiment with is when XSLT is best applicable to working over collections of XML documents vs. indexible XQuery--or at what point XSLT functions can best intervene in a pipeline of processes. I'm not sure how to pack and unpack the LunchBoX yet but I wonder what kinds of processing will be optimized for containerized work. I want to learn more about Docker anyway!