Re: [xsl] How to cope with the complexity of an XSLT program with thousands of template rules?

["Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Jun 02, 2022 at 05:53:12PM -0000, Michael Kay mike@xxxxxxxxxxxx
scripsit:
> > For 3, the right way is the same simple-small-thematic stages, but
> > done with transform() calls so you have independent stylesheets for
> > each step and stop having to worry about mode leakage.  It is way
> > too easy to re-use a mode name over the course of a long project,
> > and if it's all one stylesheet this can result in an absolutely
> > satanic debugging experience.
> 
> Give packages a try as an alternative. Packages give you all the
> isolation you get with fn:transform, but with strongly-typed and
> published interfaces between the packages.

Conceptually, I find transform() is a way to treat a stylesheet as a
function while packages are a way to treat a stylesheet as a class in
the object-oriented sense. Since I already know how to write enough
stylesheet for the conceptual function body and I already have a sense
of how to use functions, the effort cost to replace a mode-driven
pipeline with transform() calls is low.

Packages are not something I know how to do; the specification for
xsl:use-package is extensive. Reading about packages gives me the
inescapable feeling that I'm not smart enough to use this language
feature. I'd need a strong reason to attempt something with such a high
perceived effort cost; writing a library is the only use case I can
think of where it seems like it would be worth it.  The situation I
expect -- convert this to that, this one time, as soon as possible --
isn't going to support the overhead of library writing.

In the use cases I'm used to for pipelines -- converting between XML
vocabularies -- I prefer the stylesheets-as-functions approach because
as a design goal, if I'm doing something complex enough at any one
pipeline step to need package concepts like accept and override I've
failed and need to rethink.  No one stage of the pipeline should ever be
that complicated; Future Me won't be able to debug it.

I would not dare advance that design opinion as a universal; it's a
preference.  And perhaps I will have the opportunity to use packages and
become enlightened.

-- 
Graydon Saunders  | graydonish@xxxxxxxxx
^fs oferiode, pisses swa mfg.
-- Deor  ("That passed, so may this.")