The design doesn't allow you to construct a mode by combining template rules
from two different packages, except for the specific case where a using package
adds overriding template rules to a mode that is defined in a used package. If
that's what you're trying to achieve, then it isn't going to work: you're
trying to create packages that aren't sufficiently independent of each other.
The thinking is that if package A uses packages B and C, then B and C were
developed and tested independently and have no knowledge of each other or
dependence on each other. When a template rule in B calls apply-templates, it's
not expecting a template rule in C to be invoked, because it was written with
no knowledge of C.
If B and C are designed to process different kinds of document, but both were
written to use the unnamed mode, then to turn them into packages it is probably
best to add a default-mode attribute to the xsl:package element, as you have
done: but you need to use different mode names in the two packages. This has
the effect that all template rules and apply-templates calls that don't specify
a mode are now using the default mode, which can be different for the two
packages; and since the two modes now have different names, both can be visible
in the using package A.
That's the thinking anyway. How well it works in practice is something that I
hope we will discover as the user community shares its experiences.
Michael Kay
Saxonica
On 22 Jul 2017, at 15:58, Toshihiko Makita
tmakita(_at_)antenna(_dot_)co(_dot_)jp
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi list,
I'm testing to convert XSLT 2.0 stylesheet modules that have xsl:template
with @match attributes to XSLT 3.0 packages. They belong DITA-OT plug-in and
generates XSL-FO from DITA maps and topics.
Most of templates are defined with no @mode attributes which means that they
are defined as default mode.
In XSLT 3.0 package if a template is declared without no @mode attribute, it
is assumed to be "#unnamed" and "#unnamed" mode must be @visibility="hidden".
Consequently if we want declare templates in a library package as public, we
must declare mode explicitly as following:
<xsl:package name="urn:package:a" default-mode="MODE_NORMAL" version="3.0">
<xsl:mode name="MODE_NORMAL" visibility="public"/>
<xsk:template match="v">…</xsl:template>
<xsk:template match="w">…</xsl:template>
</xsl:package>
<xsl:package name="urn:package:b" default-mode="MODE_NORMAL" version="3.0">
<xsl:mode name="MODE_NORMAL" visibility="public"/>
<xsk:template match="x">…</xsl:template>
<xsk:template match="y">…</xsl:template>
</xsl:package>
The first package:
<xsl:use-package name="urn:package:a"/>
<xsl:use-package name="urn:package:b"/>
However XSLT 3.0 specification says that mode name should be unique between
library packages.
https://www.w3.org/TR/xslt-30/#named-components
"The components which can be declared in one package and referenced in
another are: functions, named templates, attribute sets, modes, and global
variables and parameters."
"[Definition: Two components are said to be homonymous if they have the same
symbolic identifier.]"
"[ERR XTSE3050] It is a static error if the xsl:use-package elements in a
package manifest cause two or more homonymous components to be accepted with
a visibility other than hidden."
According to the specification, I found it is not useful to apply xsl:package
for the XSLT 2.0 modules that have default mode templates. Is my
understanding accurate?
--
/*--------------------------------------------------
Toshihiko Makita
Development Group. Antenna House, Inc. Ina Branch
Web site:
http://www.antenna.co.jp/
http://www.antennahouse.com/
--------------------------------------------------*/
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--