[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Mode in XSLT 3.0

Subject: Re: Mode in XSLT 3.0
From: "Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 24 Jul 2017 15:09:40 -0000
Re:  Mode in XSLT 3.0
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.