Re: Mode in XSLT 3.0

On Tue, Jul 25, 2017 at 11:01:46PM -0000, Michael Kay mike@xxxxxxxxxxxx
scripsit:
> It's not clear to me what you are trying to achieve by using packages.
> The design intent of packages is that a package can be developed
> without any knowledge of, or dependency on, packages other than those
> it explicitly uses. If template rules for the same mode are
> distributed across two packages, neither of which uses the other, then
> the behaviour of one package would be affected by the presence of a
> package of which it has no knowledge. That goes directly against the
> design objectives for packages.

That kind of independence is just what's wanted; the idea is that there
are swappable/customizable components to the vocabulary.  So one
instance of a deployment of the vocabulary could be using CALS tables
and another one could be using XHTML tables and the table processing
could be swapped in as a "table" package independent of the other
processing.  That would be just ideal, distinct modes and all.

Everything else shouldn't have to know or care how the tables are
implemented or processed.  Or customized; keeping the customization in
the specific package would be a handy thing, and it looks like packages
support that easily.  Could want to drop in the custom-CALS package to
replace the default-CALS package just as easily.

> I think you're starting from the position that if the XML vocabulary
> that you're dealing with is partitioned into modules, then it ought to
> be possible to mirror the independent modules in the XML vocabulary
> with independent packages in the stylesheet. I would suggest that if
> these packages are to be truly independent, then they have to use
> different modes for their template rules.

I'm entirely fine with different modes.  What I'm after is a way to use
a construct like apply-templates with a list of modes which might apply,
rather than creating a (potentially massive) cascade of
one-variable-per-mode processing passes, since that's (aside from being
ugly and maybe inefficient) requiring the stylesheet to have knowledge
of the package contents.

(I think) it'd be better to have something like:

<xsl:apply-templates mode="#all-public-package-modes"/>

or

<xsl:variable name="inScopePackages" as="anyURI+" select="get-used-package-names()"/>

<xsl:apply-templates mode="{return-public-modes($inScopePackages)}" />

I realize neither of those constructs are available but I feel
like I'm missing something as a way to both find out what the public
modes associated with a package are, and to then apply templates on
the basis of that mode or modes.  (Or to find out what the names of the
packages available for use are.)

Generally when XSLT seems this difficult I'm doing something wrong.

-- Graydon