global-context-item() and initial-match-selection()

During the meeting while discussing bug 29705 we established that there was sympathy towards Mike's proposal. Here's my take on it.

The use-case for adding the global-context-item() function is to allow people access to the input document. The input document, however, is part of the initial match selection. The global context item may be the same, but does not have to be.

To resolve the use case, we need therefore at least also a function that accesses the initial match selection.

Thinking about this more, we may consider that:

1) Common case: for the common case, the GCI and the IMS are often the same, adding one function resolves this
2) Impact: processors may implement IMS with more-than-one items as different invocations of the stylesheet, since we currently don't define relations between individual items of the IMS. The only apparent relation is that they must be executed in the same execution scope (i.e., current-time() etc will return the same value). Allowing access to the whole of IMS may have (significant) impact to processors.
3) Usability: the usefulness the initial-match-selection() function may be limited: how would you know which is the current item? There may be ways to achieve this, but it may be of limited use.
4) Alternative: instead of a function to access IMS we can consider a function that accesses the *current* item in the initial match selection, analogous to the fn:current() function, but then global. In this case, we need only one new function, say fn:current-initial-match selection ( or choose a less awkwardly long name). 

My take on this is that:
- Doing only (1) is not enough, as solving only the common case is not good
- Doing (2), adding both functions, seems like a good idea, it feels to me that it is a significant oversight of us that we don't allow users access to the IMS as a whole. I think impact is not as big as it seems
- About (3), to resolve this we would also need a way to find the current IMS position
- About (4), if we can't, or don't want to do (2) and (3), I propose to at least allow the *current* IMS item to be accessible, with this we don't even need a GCI function

In the ideal situation I think we need a triplet:
- fn:global-context-item (access to GCI)
- fn:initial-match-selection (access to IMS as a whole)
- fn:initial-match-selection-position (can be used to find *current* IMS item) 

To limit the impact, provided we don't want the triplet, we need only one (no access to IMS as a whole, when GCI and IMS are equal, this can be used, if GCI is different than IMS, users can still use the <xsl:variable select="." /> approach):
- fn:current-ims-item (access to the current IMS item)

All in all, while I would dearly like the triplet as it is analogous to the rest, I think the last proposal, one single function, may have more chance to be accepted.

Cheers,
Abel

> -----Original Message-----
> From: bugzilla@jessica.w3.org [mailto:bugzilla@jessica.w3.org]
> Sent: Thursday, June 30, 2016 7:23 PM
> To: public-qt-comments@w3.org
> Subject: [Bug 29705] [xslt3.0] global-context-item() function
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29705
> 
> --- Comment #2 from Michael Kay <mike@saxonica.com> --- In discussion,
> Abel pointed out that this would also suggest we should provide
> initial-match-selection() - perhaps disallowing this if the IMS contains
> streamed nodes.
> 
> MK noted that this would be a significant departure in that there is currently
> no way to ask, for example "how many items are there in the initial match
> selection"? - you can only process the items one at a time.
> 
> --
> You are receiving this mail because:
> You are the QA Contact for the bug.

Received on Friday, 1 July 2016 08:55:17 UTC