Join GitHub today
Agenda and Minutes
- Status update
p:with-inputwhen it’s used for a connection. For an example please see this page.
- Representation of non-XML documents (please read the section about proxy documents as it is an attempt to specify what we discussed at the 2017-06 FTF meeting)
- Dynamic evaluation (the proposed
- User-defined functions
- Semantics of text value templates: Should we adopt the XSLT-style of tvts, where everything is converted to a text node or should we follow the proposal in the current version of the specs to allow node (via variables) to be inserted in tvts?
- Selected issues from other categories, in particular core spec issues and issues that apply to multiple steps.
- Step library (see the
atomic-stepcategory and the 2017-06 minutes mentioned above). Note: We did not have time to look into the step library this time. This is where we left off in London in June.
- Schedule for next XProc workshop before XML Prague? (Thanks to Jirka we will have a room for Feb. 6th and 7th 2018.)
- Achim Berndzen (AB)
- Gioele Barabucci (GBa)
- Erik Siegel (ES)
- Ari Nordström (AN), Chair of the W3C XProc Next Community Group
- Geert Bormans (GBo)
- Martin Kraetke (MK)
- Hans Hübner (HH)
- Gerrit Imsieke (GI)
- David Maus (DM)
- Norman Walsh (NDW)
- Filed #136 as requested by GBa
- Briefly discussed diagnostics. Some new points re debugging:
- GBa, HH: Maybe have a pipeline-independent option that will specify which ports’ input and output will be written to disk
- GI: If the storage path depends on the name/type/base URI/…, you also have to include iteration position in the path when looping
- AB: Jostein made a similar proposal some time
- GI: Maybe each pipeline should have a special port for debugging configuration?
- DM: Probably doesn’t belong into the core sped
- HH: Error (executed step) locator is crucial
- GBa: 3 different things: 1. Data and context in which the error, or the forced "core dump", occurred (the document at this point); 2. Where did an error happen (source file/line); 3. How did I get there (stack trace).
- AB, ES: XPath location in the pipeline minimum location information
- Maybe add
xml:ids to steps in order to have locators (as tuples of pipeline types and IDs/XPaths, or multiple of these tuples for an execution path on the stack trace) also for dynamic evaluation
- AB: Do we have to specify error attributes and stack trace language?
- GBo: Use injection (and then dynamic execution) for additional validation and logging
- Maybe exclude it from the core spec and have a distinct specification for injection (AB: If the processor is message based, intercepting messages is easy)
Agreement to put injection and execution path location into a different spec.
GBa: In the meantime, I’d ask implementers to add an implementation-specific option so that I can just dump everything that appears on every port into files (maybe as a stack trace / “execution plan” whose items link to the files that the processor stores in the file system)
Consensus to change
p:with-input when used for connections.
Proposal perceived as inelegant or arbitrary by some
GI argues that this is partly due to circumstances (XML vs. non-XML docs, XPath as expression language,
p:…()functions may not be evaluated by steps – the
Proposal (NDW): Instead of letting magic (primary input/output of the processing step is specified to be XML) decide when to process a proxy document as XML or not, have an explicit compound step that accepts any XML or non-XML document, provides a basic XML representation of the document properties and that emits whatever author produces when manipulating this XML, re-attaching any identifiable change to metadata from this XML representation back to the original document. Document properties will be updated from
/c:document-properties/my:prop, where the property
my:propwill be an atomic value (maybe as per an
xsi:typeannotation) or an XML structure, depending on whether its content is flat or not. As a prerequisite:
Change document properties to map QName → XDM item
content-typeproperty might be flagged as an error. Use
The split-sequence issue can be solved with for-each with different output baskets (no requirement any more to have the same output ports in each branch of a p:choose within the p:for-each)
- allow arbitrary outputs (will be added to the outputs of the containing
- maybe the catch error port as error input port?
p:filter / AVTs for XPath-constructing attributes
- Permit AVTs for
@selectfor building XPath expressions?
- Same for
- Someone needs to identify all candidates for attributes that are AVTs
There should be instructions to import at least XQuery and XSLT functions.
Maybe a commercial Saxon is necessary for implementations that use Saxon.
Question: Make support implementation-defined (“I support only import of XSLT”, for example)?
ES: What happens with global variables when the library is loaded?
NDW: Whatever is supplied as value when it is loaded (during static analysis phase).
HH: Rename it
p:eval, in line with everyone else’s naming conventions for these things. Agreement.
Runs in its own context; does not inherit any environment except for the documents and options passed to it.
Agreement that the interface (port / option signature) needs to be specified in advance. This prevents us from inventing output ports as we go within the dynamically created.
NDW: Maybe introduce an option
Dynamic error if it reads an input that wasn’t specified. Dynamic error if it doesn’t provide an output port that was specified...
Otherwise, see the discussion at https://github.com/xproc/3.0-specification/issues/97
@use-when evaluated statically?
Align with XSLT (underscore?)
Semantics of text value templates
- Consensus to not restrict to creating strings/text, but also to enable creating structures (and see whether it creates problems or is too confusing)
#136 Change implicit primary port behavior for p:pipeline: Almost consensus, need to agree on a name for
- #135 User-defined functions per p:variable?: More analysis necessary. Maybe make support of function items optional.
#132 Do we want to bring p:data back?: Consensus to use
<p:document override-content-type"…"/>and see how it works in practice
- #112 What is an XSLTMatchPattern in 3.0? see last comments
- #128 try-catch-finally accepted without discussion
- #111 Document the difference between step-evaluated and pipeline-evaluated expressions: add note
- #104 Think about more implicit connections declined (too complicated, limited use)
- #100 Specify function names/signatures and default result representations for invocations from XDM-compliant environments: postpone, and exclude it from the core spec
- #93 content-type attribute on p:output see comments
- #92 Compare XProc def of text-value templates with current XSLT draft nodes (see above)
- #87 Legacy from 1.0: Sibling shadowing for variables should be allowed allow shadowing and variables everywhere
- #85 Legacy from 1.0: What document properties are preserved/removed by steps in the pipeline see most recent comments
- #84 Legacy from 1.0: Legacy from 1.0: Where do we say that it's an error to attempt to make a connection to a port that doesn't exist? postpone, look at the purported gap in due time
- #77 Legacy from 1.0: clarify how syntactic shortcut for options are used with non-string option values AVTs
#71 Legacy from 1.0: Clarify the distinction between p:input declarations and connections even better
- #69 Legacy from 1.0: Clarify the concept of "URI appearing in an option value" →NDW
- #68 Legacy from 1.0: Clarify variable and option shadowing rules duplicate
- #66 Legacy from 1.0: Reading document properties in a step-evaluated XPath workaround for split-sequence for non-XML documents available, see last comment
- #65 Legacy from 1.0: Allow access to a sequence output via the default collection of the XPath context go with NDW’s proposed resolution
- #61 Legacy from 1.0: Syntax: add @pipe to make defining connections easier as per most recent comment
- #55 Legacy from 1.0: Can maps nest? What's the serialization story? as per most recent comment
#54 Legacy from 1.0: c:param can have content no
- #52 Legacy from 1.0: Describe context for understanding variables and options duplicate
- #51 Legacy from 1.0: Should XProc adopt shadow attributes? deferred
- #44 Legacy from 1.0: 3.8 Consider using XDM everywhere yes, closed (superseded by something else)
- #42 Legacy from 1.0: 3.5 Provide a mechanism for importing user-defined functions superseded by something else
- #37 Legacy from 1.0: # 2.7.2 Syntax: allow <p:pipe port="secondary"/> accepted
- #10 Support importing function libraries yes, superseded by something else
Issues that are related to multiple steps (label
- #78 Legacy from 1.0: Consider adding @timeout to control potentially long-running steps yes, see most recent comment
- #64 Legacy from 1.0: default error port see most recent comments
- #80 Legacy from 1.0: Consider removing p:group from p:try probably keep it
- #27 p:wait-for-change deferred
- #26 p:until deferred
- Consider adding
p:if, now that we dropped the requirement that each step needs to provide a fixed set of output ports for each execution path.
The meeting ended with mutual backslapping because we thought that we solved a lot of issues, some of them fundamental.