[Bug 27648] [xslt 3.0] Dynamic Component References

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27648

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[xslt 3.0] (Editorial)      |[xslt 3.0] Dynamic
                   |Component references        |Component References

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
On reflection, I think the problem raised here runs a little deeper than I
first thought.

There are three cases, I believe, where we allow dynamic references to
component names: these are fn:key, fn:accumulator-before/after, and
fn:function-lookup. We don't really have a story on how dynamic component
references are resolved in the presence of package-level overrides.

If we wanted to make it precisely analagous to static component references,
then we would have to examine the call stack: if template A in package PA calls
template B in package PB, B calls C in PC, and C calls function-lookup('F'),
then we would look first for function F declared in PC, then for overrides of F
in PB, then for overrides of F in PA. This seems complex and onerous
(especially for processors that generate code rather than working as
interpreters), and it's a little difficult to see how it works if the "calls"
are references to global variables rather than function or template calls.

fn:key() is not a problem because keys are private to a package and cannot be
overridden.

For fn:function-lookup(), I think it would be quite acceptable to say that it
searches only within the package containing the call on function-lookup,
disregarding any overrides.

That leaves accumulators. I can see three ways forward:

(a) define the dynamic binding algorithm to take account of the call stack as
proposed above, with all its potential difficulties.

(b) revert to a syntax for invoking accumulators where the accumulator name is
bound statically. Perhaps (b1) by making an accumulator declare a function, as
we did before, or (b2) by replacing the functions accumulator-before and
accumulator-after with instructions along the lines of call-template.

(c) change accumulators to be like keys: always private to a package, with no
override allowed. If you want to expose accumulator values to other packages,
define a function that wraps the call on accumulator-before/after; if you want
to override an accumulator, override the wrapping function with a call to a
different accumulator.

We should also take into account the "applies-to" mechanism, or its
replacement, wich establishes an association between accumulators and source
documents. If we tell the system to evaluate accumulator A against document D,
which A do we mean, in the case where there are overrides?

Taking all these factors into account, and given where we are in the
development cycle, my preference is for (c) as the least disruptive change.
This means: no change to the syntax other than removing xsl:accumulator as a
permitted child of xsl:override; no need to define complex new semantics for
dynamic component binding; it's not a serious restriction of capability; and
there's already a good precedent in the way we do keys.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 18 December 2014 08:51:22 UTC