Re: xsl transform() calls and creating SEF files

Yes, you should be able to do this by putting each stylesheet in a separate SEF.

(Note that a stylesheet is a package by definition)

Michael Kay
Saxonica

> On 7 Jul 2021, at 13:25, Graydon Saunders <[email protected]> wrote:
> 
> You can, however, load the stylesheet for fn:transform() from a separate SEF file.
> 
> Two follow-on questions, if I may.
> 
> 1. the core objective here is not so much to use a SEF file as to deploy the application in a state where a) the client can't (however innocently) edit it and b) in the smallest possible number of files.  Maybe there's a better way to do that than SEF files?
> 
> 2. By analogy,
> 
> <xsl:sequence select="
>         transform(map {
>           'stylesheet-location': 'iminapackage.sef',
>           'source-node': $someContent
>         })?output"/>
> 
> ought to work, but implies that every individual stylesheet needs to be in its own package and that package needs to be its own SEF file.  Is that correct?
> 
> Thanks!
> Graydon
> 
> On Wed, Jul 7, 2021 at 8:00 AM Michael Kay <[email protected] <mailto:[email protected]>> wrote:
> Understood.
> 
> But I'm afraid that (a) a SEF file can only hold multiple stylesheets if they are set up as packages, and (b) there's no way for fn:transform() to select a package from within a SEF file. You can, however, load the stylesheet for fn:transform() from a separate SEF file.
> 
> Michael Kay
> Saxonica
> 
> 
> > On 7 Jul 2021, at 01:28, Graydon <[email protected] <mailto:[email protected]>> wrote:
> > 
> > On Wed, Jul 07, 2021 at 12:04:42AM +0100, Michael Kay scripsit:
> >> Surely if you want to package the two transforms into a single SEF, then you know statically what transformation you want to invoke, and if you know statically what transformation you want to invoke, then you don't need fn:transform()? This sounds like a case for a static invocation using packages rather than a dynamic invocation using fn:transform().
> > 
> > I've got (so far) nineteen transforms, plus the containing stylesheet.
> > 
> > There are two use cases for transform() involved.
> > 
> > One is to use a wrapper function, a map of parameters, and a list of named transforms where the names are keys of the parameter map to process documents through a succession of transformations by recursively consuming the list of transform names through the wrapper function.  Having the list of named transforms makes it simple to both enforce a processing order and to adjust the processing by adding or removing items from the list.  (In the meantime, the actual transforms are usable in other contexts via other invocation mechanisms and testable in isolation, both positives in our circumstances.)
> > 
> > Two is to use transform() much like the XSLT 2.0 pattern of chaining variables, where each variable was processing the previous variable's contents with apply-templates and a new mode.  I find the transform version preferable to the mode chain because the individual transforms are self-contained and the "whups, mode leakage" bug category becomes a thing of the past.  Plus "self contained" helps with multiple developers; no SCM I know of handles XML merges really well, and keeping each functional step in its own stylesheet document reduces the amount of flailing at merges.
> > 
> > I didn't consider packages because packages appear to be designed to provide libraries, rather than a processing chain; because packages have significant management overhead, and many of these processing steps are small but need to be distinct, making them seem something that just doesn't belong on package scale; and because I have no idea how to manage the requirement that package names be absolute URIs in a version control system.
> > 
> > It may be the case that all the objections to packages are a consequence of my own lack of understanding, but that's how I got here.
> > 
> > -- Graydon
> > 
> > 
> > _______________________________________________
> > saxon-help mailing list archived at http://saxon.markmail.org/ <http://saxon.markmail.org/>
> > [email protected] <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/saxon-help <https://lists.sourceforge.net/lists/listinfo/saxon-help> 
> 
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[email protected]
https://lists.sourceforge.net/lists/listinfo/saxon-help