Hi Gerrit,
I was considering also generating provenance data for all the
custom steps called during the pipeline but the provenance data
quickly explodes and as I have no requirement for that right now,
I'm going with the tighter scope and just record the URI of the
XProc file that serves as the entry point for the pipeline.
I was thinking about the step name and type as potential identifiers to fallback to if the step didn't have a URI. I don't think that will be an issue with my current scope and context but if I need to use a p:library as the starting point then I think I'll need to record p:type as well as the URI. This is for a personal project, so I have no concrete business requirements to meet. It would be interesting to hear from anyone who does have experience of this in a real-world context.
For now, I have a step that generates a bundle of provenance data for a pipeline, which I call at the end of pipeline, and insert as a child of the root element of the result. Optionally, I could not insert it and instead return it via a port named 'prov'. At the moment, inserting it isn't a problem but I can easily conceive of situations where it would be.
Kind regards,
Sheila
Thank you Norm and Gerrit for drawing my attention to those issues.
This goes back to my ambition to record helpful provenance metadata when practical. In this case, I'm exploring how to identify the pipeline. It's purely for my own consumption at this point, although I can imagine contexts where it might actually be useful to an auditor (in banking, for example).
One of the aspects of this that I find quite
On 16 July 2025 09:00:28 BST, "Imsieke, Gerrit, le-tex" <gerrit.imsieke@le-tex.de> wrote:The other issue is that something like doc(static-base-uri())//p:declare-step/@name doesn’t work for steps that are declared in a p:library or in another p:declare-step. A processor could expose the names and types in extension functions, or we could contemplate introducing p:step-name() and p:step-type() functions. Sheila, how are you going to implement the reflection framework that you are conceiving? If reflection messages are added to the pipelines by transforming their XML content before they are executed, you might as well generate the my:stepname and my:steptype variable declarations in the course of this transformation. Gerrit On 16.07.2025 09:18, Norm Tovey-Walsh wrote:Sheila Thomson <discuss@bluegumtree.com> writes:I have another reflection question. Is there a way to get any of the following from within a step about itself: * name (/p:declare-step/@name) * type (/p:declare-step/@type) * URII think the static-base-uri() will give you the URI of the step but that might not be its location on the filesystem (someone could have used xml:base on it) and it might not be the only step with that base URI, it could be within a p:library, for example. Name and type are not really available. On one level, they’re an artifact of the surface syntax. After the pipeline has worked out what the steps are (from their types) and how the inputs and outputs are connected together (from their names), neither the type nor the name are really needed anymore. You could fake it in a somewhat ugly fashion by having a convention: <p:declare-step name="main" type="ex:mystep" …> <p:variable name="my:stepname" select="'main'"/> <p:variable name="my:steptype" select="QName('ex:mystep')"/> But I assume this is for status and debugging messages and you’d rather not have the chance of a copy-and-paste error giving you misleading details. I expect my implementation keeps the names and types around, but they aren’t exposed anywhere, as far as I can recall. Be seeing you, norm -- Norm Tovey-Walsh <ndw@nwalsh.com> https://norm.tovey-walsh.com/He would like to start from scratch. Where is scratch?--Elias Canetti