[xsl] [Part 2] Data-driven design and onion-skin layering: a better way to build systems

["Roger L Costello costello@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Why layering matters
In many imperative systems, variation is handled using:

  *   conditionals
  *   branching logic
  *   flags
  *   configuration checks
  *   duplicated code paths
Over time, shared behavior and local variation become intermingled.
The result is familiar:

  *   harder maintenance
  *   increased complexity
  *   duplication
  *   difficulty understanding what is common vs specialized
The onion-skin model addresses this directly:

  *   shared behavior lives in the core
  *   variation lives in thin outer layers
  *   override and augmentation are handled structurally
This leads to a system where:

  *   the common case is clear
  *   specialization is localized
  *   reuse is natural

________________________________
When this architecture is valuable
This approach is especially valuable when all of the following are true:

  *   the output is driven by structured input
  *   there is a meaningful shared core of behavior
  *   multiple specialized outputs are required
Examples include:

  *   publishing systems
  *   operational or intelligence reports
  *   regulatory or structured documents
  *   multi-organization data interchange
If those conditions are not present (for example, a single-purpose task with
no variation), the advantages may be less apparent.
This is one reason small examples often fail to make the case.
________________________________
Why XSLT fits this naturally
XSLT is a domain-specific language operating over structured data (the XDM
model). It provides, out of the box:

  *   pattern matching over input structure
  *   template-driven processing
  *   push-style execution
  *   import precedence for layering
  *   built-in mechanisms for override and augmentation
A general-purpose language such as Java can certainly implement similar
architectures, but doing so requires explicit construction:

  *   classes and interfaces
  *   dispatch logic
  *   configuration frameworks
  *   control-flow orchestration
In XSLT, much of this is already part of the language model.
In that sense, it offers fewer ways to manipulate the data-but those fewer
ways are often better aligned with the problem.