RE: apply-templates invocation

Here's a new attempt at describing my view on apply-templates invocation, you can disregard my previous mail.

This discussion originated from a wake-up call after I drafted a PDF which showed the different ways of invoking a stylesheet. Previous WG discussions have shown that we want to simplify this, but I am not convinced anymore that it is difficult or that we should. Most rules are in place for good reason and primarily because they are dispersed throughout the spec it has become difficult to untangle them.

I would like to look at a way forward that largely maintains the status quo (minimal disruption) but that simplifies our understanding of the rules. 

<proposal>

1) Create a new section on "eligible initial mode"

An *eligible initial mode* is a mode in the principal package that is public or final, is the unnamed mode, or is a mode that is used in the default-mode attribute. For simplified packages (packages with xsl:stylesheet or xs:transform at their root), an *eligible initial mode* is either the unnamed mode or any mode that appears in a mode attribute in xsl:template.

Note
If declared-modes is true, the unnamed mode must be declared to be an eligible initial mode, see XTSE3085.

Note
The visibility of a mode can be controlled by the visibility attribute on the xsl:mode declaration or by changing the visibility through xsl:expose and xsl:accept. The default visibility is private.

Note
These rules deliberately allow a private mode to be eligible, in casu the unnamed mode or a mode specified in the default-mode attribute. This serves the use-case where the designer of a stylesheet wants to force users into a single entry point. Historically this is the unnamed mode, but a programmer may elect a different (private) mode as the entry point for the stylesheet through the default-mode attribute. To disallow invocation with the unnamed mode, a programmer should use declared-modes="yes" without declaring the unnamed mode.

2) Define the apply-templates invocation in terms of *eligible initial mode*

The initial mode *MUST* be an *eligible initial mode*. If no initial mode is given for apply-templates invocation, it defaults to the default-mode attribute in the top-level element, or if absent, to the unnamed mode.

[ERR XTDE0045] If the invocation of the stylesheet specifies an initial mode that does not match the expanded QName of an *eligible initial mode, then a dynamic error occurs.

Note
It is implementation-defined how processors allow users to select an initial mode. 

</proposal>


By splitting the rules this way, I think (hope) we help in understanding them, talking about them and simplifying the problematic XTDE0045 (which lies at the root of this discussion).

The rules above follow the status quo and specifically do not try to special-case the unnamed mode any further that it already is. I realize that this won't simplify the tables that I drew, but it may simplify our thinking about it.

Note that Michael's observation that xsl:expose should not apply to the unnamed mode should still be considered, but in itself does not apply to apply-templates invocation.

Cheers,
Abel



> -----Original Message-----
> From: Abel Braaksma [mailto:abel.braaksma@xs4all.nl]
> Sent: Thursday, November 10, 2016 5:35 PM
> To: 'Michael Kay'; 'XSL Working Group'
> Subject: RE: apply-templates invocation
> 
> I have been thinking about this a while and it would be nice if we should
> simplify things if we can, but I would prefer it if we can do so without
> sacrificing (too much) usability.
> 
> But I find it difficult to simplify this. Michael's proposal is a step in the right
> direction, but I am uncertain it will really be a simplification. Since most of this
> discussion came from me drawing the tables I drew, perhaps we can simplify
> the tables and come to the conclusion that it isn't so difficult after-all?
> 
> As an alternative, perhaps we can split the XTDE0045 into simpler errors? Or
> even generalize it? For instance:
> 
> [XTDE0045] It is an error to invoke a stylesheet with an initial mode that is not
> visible, does not exist or is otherwise not eligible as initial mode.
> 
> Then below it we specify the possible causes, we can do so in a Note, as it is
> already specified elsewhere. Implementors can make variants of the error to
> clarify it to users (as I am sure they already do for a lot of other standard
> errors).
> 
> Here are some other thoughts I have:
> 
> On (A):
> During our discussion we thought that we were fuzzy about default-mode
> attribute to be allowed as a surrogate for the initial mode, but we actually are
> very explicit about it in the section on apply-templates invocation:
> 
> "If no initial mode is supplied, then the mode used is that named in the
> default-mode attribute of the (explicit or implicit) xsl:package element of the
> top-level package or in the absence of such an attribute, the unnamed
> mode."
> 
> This also suggests that the *initial mode* can be anything that is also allowed
> in the *default-mode* attribute. This means that a private mode, if set in the
> default-mode attribute, can be used as initial mode.
> 
> On (B):
> I'd prefer to leave it as-is.
> 
> On (C2):
> This currently is the case, i.e. we say:
> "Note that there is an unnamed mode in every package, and the unnamed
> mode always has private visibility."
> 
> And later: "Because the unnamed mode always has private visibility, it cannot
> be overridden in another package."
> 
> 
> 
> 
> > -----Original Message-----
> > From: Michael Kay [mailto:mike@saxonica.com]
> > Sent: Tuesday, November 01, 2016 12:19 PM
> > To: XSL Working Group
> > Subject: apply-templates invocation
> >
> > As we saw from Abel's analysis, the current situation is extremely
> > complicated, and I think tthings can be simplified.
> >
> > Here's my latest proposal for a way forward that I think involves
> > minimum disruption.
> >
> > (A) default-mode. The sole purpose of this attribute is to define a
> > default for the mode attribute of any xsl:template[@match] or
> > xsl:apply-templates element that lacks a mode attribute, within its
> > scope. We don't design APIs but we should not encourage API designers
> > to make this the default for the initial mode on stylesheet invocation.
> >
> > (B) declared-modes.
> >
> > OPTION B1: My own preference would be to drop this attribute in the
> > interests of simplification, replacing it with a rule that named modes
> > must be declared if referenced within xsl:package but are implicitly
> > declared otherwise.
> >
> > OPTION B2: make this apply to named modes only. The unnamed mode is
> > implicitly declared with the equivalent of an <xsl:mode/> declaration
> > with no attributes.
> >
> > OPTION B3: leave as is.
> >
> > (C) mode visibility. Proposal:
> >
> > (C1) Named modes have visibility controlled using @visibility and
> > xsl:expose, in the same way as other components. The default
> > visibility for named modes, whether explicitly or implicitly declared,
> > is private. xsl:expose can be used to modify the visibility only if the mode is
> explicitly declared.
> >
> > (C2) The unnamed mode always exists and is effectively private (though
> > as it does not have a name, it does not really have a visibility
> > either; but it's private in the sense that a using package cannot reference it
> or override it).
> >
> > (C3) The initial mode specified on stylesheet invocation must be one of:
> >
> > (a) an explicitly named mode with visibility public or final, or
> >
> > (b) an implicitly-declared named mode (assuming declared-modes="no")
> >
> > (c) the unnamed mode - this may be used as the initial mode even
> > though it is nominally private.
> >
> > WHAT NEEDS TO CHANGE?
> >
> > Let's assume B2 for the moment.
> >
> > (I) 3.4.5.1 changes by adding the highlighted text:
> >
> > The declared-modes attribute of xsl:package determines whether or not
> > *named* modes that are referenced within the package must be
> > explicitly declared. If the value is yes(the default), then it is an
> > error to use a mode name unless the package either contains an
> > explicit xsl:mode declaration for that mode, or accepts the mode from
> > a used package. If the value is no, then this is not an error.
> >
> > * Note: This applies to mode names appearing in xsl:template/@mode,
> > xsl:apply-templates/@mode, @default-mode, and xsl:expose/@names. It
> > does not apply to the unnamed mode, where a mode declaration is always
> > optional.
> >
> > (II) change the definition of XTSE3085 as follows:
> >
> > [ERR XTSE3085] It is a static error, when the effective value of the
> > declared- modes attribute of an xsl:package element is yes, if the
> > package contains an explicit reference to a named mode that has not
> > been declared
> >
> > For the purposes of the above rule:
> >
> >  • A mode is declared if either of the following conditions is true:
> >   • The package contains an xsl:mode declaration for that
> mode.
> >   • The mode is a public or final mode accepted from a used
> package.
> >  • The offending reference may occur in any of the following:
> >   • The mode attribute of an xsl:template declaration
> >   • The mode attribute of an xsl:apply-templates instruction
> >
> > Note: it is never necessary to declare the unnamed mode in an explicit
> > xsl:mode declaration, except to give it attributes such as on-no-match
> > or on- multiple-match or streamable.
> >
> > (III) change the rules for default-mode (3.7.2) so that any named mode
> > that it refers to must be explicitly declared.
> >
> > (IV) change the rules for xsl:expose so that it only applies to named
> > modes that are explicitly declared. Specifically (a) any explicit mode
> > name in xsl:expose must refer to an explicitly declared mode, and (b)
> > a wildcard in xsl:expose never matches an implicitly declared mode
> > (nor does it match the unnamed mode).
> >
> > (V) change XTDE0045 as follows:
> >
> > [ERR XTDE0045] A dynamic error occurs if the invocation of the
> > stylesheet specifies a named initial mode that is neither (a) an
> > explicitly declared mode in the top-level package with visibility
> > public or final, nor (b) a mode that is implicitly declared by virtue
> > of its presence in the mode attribute of a template rule defined in
> > the top-level package (which can only happen if the effective value of
> declared-modes is "no").
> >
> > and add a note: Although the unnamed mode is private to a package in
> > the sense that it cannot be referenced or overridden in a using
> > package, it is nevertheless always available as an entry point for
> > apply-templates invocation, whether or not it is explicitly declared.
> >
> > Michael Kay
> >
> >
>

Received on Wednesday, 16 November 2016 16:16:37 UTC