xproc / 3.0-steps

Repository for change requests to the standard step library and for official extension steps
10 stars 7 forks source link

Change the default initial-context-item for p:xslt #395

Closed xatapult closed 4 years ago

xatapult commented 4 years ago

Can we change the definition of the initial-context-item for p:xslt from:

<p:option name="global-context-item" as="item()?"/>

to:

<p:option name="global-context-item" as="item()?" select="."/>

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 the initial-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.

ndw commented 4 years ago

Seems reasonable to me. But it has a couple of consequences we should think through.

  1. If there isn't a default readable port, you'll have to specify an alternate value or you'll get an error. And I don't recall if 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.)
  2. It will mean 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?
xatapult commented 4 years ago

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):

xatapult commented 4 years ago

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.

gimsieke commented 4 years ago

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?)

xatapult commented 4 years ago

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)

gimsieke commented 4 years ago

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?

xatapult commented 4 years ago

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

ndw commented 4 years ago

I think that node identity is straightforward to implement; I'm a little less sure how to specify it.

ndw commented 4 years ago

@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.

xatapult commented 4 years ago

It seems that because of streamability the global context item can not be the same as the input document... inconvenient to say the least.

xatapult commented 4 years ago

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)