- From: Michael Kay <mike@saxonica.com>
- Date: Thu, 13 Oct 2016 22:53:12 +0100
- To: Abel Braaksma <abel.braaksma@xs4all.nl>
- Cc: Public XSLWG <public-xsl-wg@w3.org>
As we said on the call, the tables are very useful in revealing the level of complexity that exists in the spec. And I can't help feeling that the complexity isn't well justified by any powerful capability we are providing. There are basically two ways of reducing complexity: we could remove features, or we could reduce the number of interactions between different features. The things that immediately come to mind are: * default-mode. The way this is described in 3.7.2, and the way I primarily think of it, is as a purely lexical default for the mode attribute of xsl:template and xsl:apply-templates elements within its scope. Its use as a default for the initial mode seems to have crept in by a side door, and I suggest we get rid of it. In fact, I suggest we say nothing about the default for the initial mode; leave it as an API matter. * declared-modes. Does this really add value? And if so, is that value really worth the cost in complexity? How about dropping the attribute and making it mandatory to declare modes with xsl:package, optional with xsl:stylesheet? Looking at the various tables in the PDF, I think the rules then become: Determining which modes must be declared * Within a package rooted at xsl:package - every mode referenced in @mode or @default-mode must be declared, including the unnamed mode if it is referenced explicitly or implicitly. * Within a package rooted at xsl:stylesheet - there is no requirement to declare any modes. Determining whether a mode is considered available for use as initial mode * The unnamed mode is always available * A named mode is available if its visbility is public or final Determining which mode is the initial mode for invocation * The initial mode is whichever mode is selected via the API. Defaults are API-determined, but the recommended default is the unnamed mode. This seems a lot simpler with no significant loss of functionality. Michael Kay Saxonica > On 13 Oct 2016, at 08:03, Abel Braaksma <abel.braaksma@xs4all.nl> wrote: > > This proved more complex, or at least more challenging than I at first envisioned. In the attachment are a few tables and some text. Mainly they describe: > > 1) The various invocation methods (apply, call, function) > 2) Which modes must be declared > 3) Whether a particular mode is available as initial mode > 4) The actual effective initial mode > > I hope it is useful, and if not, I hope at the very least we get some insight in our methods of invocation ☺. > > Cheers, > Abel > <Invocation methods table.pdf>
Received on Thursday, 13 October 2016 21:53:45 UTC