Re: [xsl] Mode in XSLT 3.0

Subject: Re: [xsl] Mode in XSLT 3.0
From: "Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 24 Jul 2017 15:09:40 -0000
On Mon, Jul 24, 2017 at 02:14:28PM -0000, Eliot Kimber
ekimber@xxxxxxxxxxxx scripsit:
> Ibm not sure I understand the DITA-to-module issue here: Ibm not yet
> up to speed on XSLT 3 modulesb&
[snip]
> In DITA, sets of element types (grammars) are formally defined in
> bmodulesb, which reflect sets of elements with the same architectural
> base and some semantic relationship, either a single structural type
> (map type or topic type) or bmix-inb elements for a specific purpose
> (bdomainsb). These modules are a natural and obvious basis for the
> corresponding implementation modularity.

This is what I thought I'd said, while trying not to haul in the
DITA use of the word "module".

My understanding is that

<xsl:package
  id? = id
  name? = uri
  package-version? = string
  version = decimal
  input-type-annotations? = "preserve" | "strip" | "unspecified"
  declared-modes? = boolean
  default-mode? = eqname | "#unnamed"
  default-validation? = "preserve" | "strip"
  default-collation? = uris
  extension-element-prefixes? = prefixes
  exclude-result-prefixes? = prefixes
  expand-text? = boolean
  use-when? = expression
  xpath-default-namespace? = uri >
  <!-- Content: ((xsl:expose | declarations)*) -->
</xsl:package>

lets you leave off @default-mode, but if you do, you get different
#unnamed modes in different packages.  (Packages are defined to be
mode-independent of each other because for basic information-hiding
software engineering reasons, no package has any idea any other package
exists.  So all the #unnamed modes are inherently package-specific.)

So even a very neatly organized set of DITA packages, one per
DITA-domain, presents the problem of switching modes during processing;
I may know I am in (for example) a table cell, and I want to process the
content of the cell which uses markup from a non-table DITA-domain;
which modes do I want to be doing this processing in?  How do I explain
to the package with the table processing what modes those are?
(Especially since someone might have locally defined an additional
domain.)

I'm presently unable to answer that question and a little flummoxed by
noticing that current oXygen has no notion of xsl:package.  It doesn't
strike me as a trivial question; how do I have a group of packages that
use templates in each other without a clear hierarchy of packages?

(I'd expect this to be even more interesting in something like HL7v3
than it is in DITA.)

-- Graydon (Who is all for a ground-up DITA-OT rewrite in 3, but that's
way off scope for this list. :)

Current Thread