- From: <bugzilla@jessica.w3.org>
- Date: Tue, 13 Sep 2016 08:26:37 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29818 Bug ID: 29818 Summary: [xslt30] Visibility and Applicability of Accumulators Product: XPath / XQuery / XSLT Version: Candidate Recommendation Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XSLT 3.0 Assignee: mike@saxonica.com Reporter: mike@saxonica.com QA Contact: public-qt-comments@w3.org Target Milestone: --- This arises from the decision that use-accumulators on xsl:source-document, xsl:merge-source, and xsl:mode should apply to unstreamed documents as well as to streamed documents. For these cases, there is a package that we can call the "originating package of the document" - for xsl:source-document, xsl:merge-source it's the package containing the instruction, for xsl:mode (which controls accumulators for documents in the initial match selection) it's effectively the top-level package. When use-accumulators="#all" is specified, it means all accumulators declared in the originating package. Note that these accumulators necessarily have distinct names. (The term "originating package" is new, but the concept already exists in effect for whitespace stripping rules. For most kinds of source document, the whitespace stripping rules of some package apply, and we can refer to that package as the "originating package" of the document). Now, accumulator-before() and accumulator-after() require that the accumulator name supplied is both visible in the package containing the function call, and applicable to the tree containing the context item. I wonder why the first condition is necessary. Now that the only accumulators available are those declared in the originating package, the requirement that the accumulator is visible in the invoking package seems to have no useful purpose. And it leads to potential confusion: what if the originating package declares an accumulator A and the invoking package declares a different accumulator also called A? So I would like to suggest dropping the requirement that the accumulator named in accumulator-before/after be visible in the package containing the function call. Now consider documents/trees that aren't originated using these three instructions: for example, documents read using doc()/document()/collection(); documents created using xsl:document, temporary trees created using xsl:variable; documents created using parse-xml(), parse-xml-fragment(), analyze-string(), json-to-xml(). Which accumulators are applicable? We currently say "all accumulators", but do we mean this in the sense of "#all", or do we mean all accumulators declared in any package of the stylesheet? If accumulator-before(N) or accumulator-after(N) is used, then N is currently taken as a reference to an accumulator defined in the package containing the accumulator-before/after call. Given the changes to use-accumulator, it now feels more consistent that it should be taken as a reference to an accumulator declared in the package where the document originates. For all the above cases (exception noted below) the "originating package" is fairly obvious and not difficult to define, e.g. for doc() it is the package in which the call to doc() appears. This approach seems consistent with the fact that the whitespace stripping rules that apply to a document are the rules in its originating package. The exception noted above is a temporary tree constructed using a global xsl:variable. Here there are two candidates for the "originating package": it could be either the declaring package of the global variable, or its containing package. If package A declares a variable V, and package B uses package A, and package B contains a reference to V which is interpreted as a reference to V(B) (that is, the global variable named V whose declaring package is A and whose containing package is B), then does accumulator-before("C") refer to an accumulator declared in B or an accumulator declared in A? I think it's probably most consistent to make it B - the containing package rather than the declaring package. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 13 September 2016 08:26:50 UTC