Closed xatapult closed 4 years ago
Seems reasonable to me. But it has a couple of consequences we should think through.
global-context-item="{()}"
will work or not. I have this sneaking feeling that it won't because of something about AVTs and items. (But I'd be happy to be told I'm mistaken about that.)global-context-item
will almost always be set, even if the author isn't thinking about it. Does that have implications for the behavior of stylesheets that don't intend to interact with the global context item?What i would like to see here is that at least the common stylesheets (the ones that take a single XML document as input) work as they would work when run outside of XProc.
Here is a proposal for some rules that do the trick (I think):
global-context-item
is not set, this automatically becomes the global-context-item
. Setting the global-context-item
of course overrides this.global-context-item
is set, you'll have to do this explicitly. Another thing we need to talk about with regards to this is node-identity: If I supply the same document from the pipeline to both the p:xslt
's source port and the global-context-item
, is there node-identity between these two?
This is not an academic discussion, because if there's no node-identity some very common XLST design patterns (with match patterns using variables) become impossible.
I think your proposal is closely aligned to both a) how an XSLT 3 stylesheet is invoked if multiple documents are on the source port and b) to user expectations if there is a single document on the source port.
Node identity between such an automatically set global context item and the document on the source port must be guaranteed.
(Aside, to be raised in a different issue that might block this issue: I’m very unhappy with our decision not to make available the collection of documents on the source port as the default collection for an XSLT 3 invocation. We have many XSLT 2 stylesheets meant to run in an XProc 1 processor that refer to the default collection. How can we continue to refer to the collection of these documents if we change the XSLT version in these stylesheets to 3.0?)
Node identity between such an automatically set global context item and the document on the source port must be guaranteed.
IMHO we should also strive to make this true for explicitly provided documents on the global-context-item
option (if technically possible)
If this is not clear implicitly or explicitly: In the XSLT processed by p:xslt
(and potentially also other steps), every node that is passed as part of an option (for example, a sequence of documents passed as a parameter) that is also given on an input port should share node identity with the corresponding node on the source port. Or if the same node is passed in two different options, I think there also should be node identity.
Do we say anything about node identity when using, for example, p:variable
or p:identity
?
Do we say anything about node identity when using, for example, p:variable or p:identity?
AFAIK, no.
Totally agree with you, but I wonder what the implementers have to say about this
I think that node identity is straightforward to implement; I'm a little less sure how to specify it.
@gimsieke I think you should start a new issue for the default collection question. I don't recall what motivated our decision to change that.
It seems that because of streamability the global context item can not be the same as the input document... inconvenient to say the least.
We have consensus about the solution as described https://github.com/xproc/3.0-steps/issues/395#issuecomment-625055692
node-identity inside the XSLT between the global-context item and the input document is processor dependent (unfortunately)
Can we change the definition of the
initial-context-item
forp:xslt
from:to:
If you don't do this it means that when this option is not set, for global variables there is no context item. So you can't by default do something entirely normal (at least in my stylesheets) as
<xsl:variable name="..." select="/*/@something/>
. You would have to explicitly set theinitial-context-item
option to.
.This is also how Saxon behaves by default (when used directly from oXygen or from the command line), but it turns out to be a handy default set by Saxon, not something the spec defines. I think it's important to do this because people expect this when they run an XSLT 3 stylesheet: it is what they're used to.