# XProc Workshop, 5-6 September 2018, Leipzig

• Scribe: Norm
• Break for lunch at 13:00, recess for the day at 18:00
• Present: Norm, Achim, David, Jim, Hans, Gerrit, Fränze, Martin, Erik, Geert, Ari
• Next meeting, February 5/6 colocated with XML Prague

Norm: Achim suggested we should try to have a 1.0 spec ready for “last call” by February. I think that’s a good plan. I everyone else thinks that’s a good plan, I think the most important thing we can do at this meeting is resolve the open issues.

General agreement.

Achim proposes that we discuss the static vs dynamic options and variables first.

## Issues

### Static and dynamic options and variables

Related issues #473 and #506

Achim begins with a little overview of static options and variables.

Erik observes that the current draft excludes import and import-functions from the prologue. It probably doesn’t have to.

(Coffee is finally ready, Geert breaks out the Belgian chocolates, the meeting stumbles to a temporary halt.)

Consequences of the current discussion:

• No static variables outside the prologue
• No shadowing of static variables or options (See #506 which is greatly simplified by this resolution.)

Below, the group goes through the issues; we’re skipping the step-related issues and the scribe isn’t attempting to capture discussion on every issue that we decided not to discuss.

### #29 Standardize cx:message attribute

Discussion becomes more broad; are p:timeout and p:message actually options, or are they “just attributes” that are magic.

Consensus seems to be drifting towards making them options.

Lots of observations about the fact that time isn’t really something XProc is concerned with. But this is just a question of pragmatism.

Implementation of timeout should be an optional feature.

Some discussion of p:depends which cannot be an AVT or an option because it effects the graph during construction.

Martin proposes a step for this purpose. One that reports the time taken.

Proposal: In 3.0, p:timeout is just an attribute and must be constant.

General agreement.

Further discussion of the compound step solution.

Proposal: In 3.0, p:message will be an “ordinary option”; it can be set with an AVT or via a p:with-option.

This introduces p:with-option on compound steps.

### #142 Add severity to c:error attributes

Related to #397, Proposal for a unified validation reporting language.

Erik volunteers to investigate. David observes that it would be good to have a group of validation experts describe a reporting language; it should consider SVRL.

### #267 Add a standard serialization method for binary

The answer for JSON is “json”. For binary, don’t specify a method, it’s determined by the content type.

Consensus reached and added as a comment to the issue: In the absence of a serialization method, the content-type should be considered. For application/octet-stream, the content should be written out without change. For other content-types, the results are implementation-defined.

### #333 Granularity of static errors

This is a late-stage editorial task.

Deferred.

### #342 Granularity of XD- and XC-type errors

This is also a late-stage editorial task.

### #371 Nodes as document-properties and p:document-properties-document()

Some discussion of authoring freedom: it’s my map I should be able to put anything I want in the map.

The counter-argument for usability is the convenience function that lets someone convert maps with strings into maps with QNames.

Consensus: we’ll leave maps as map(xs:QName,item()*). Leaving the issue open because there is still places where we’ve got map(xs:QName,item()).

### #388 Attributes and options with map value

Need to add this to the spec. Need to make it clear that they aren’t AVTs but they are evaluated as expressions. This applies to the options on user-defined steps that have an “as” attribute.

### #399 Document the various flavors of cast-content-type

We should come back to this tomorrow if there’s time.

### #427 Option "serialization" on p:output is not inline with current discussion

The serialization map needs to be map(xs:QName,item()*).

### #428 Option "serialization" on p:output for atomic steps

After discussion, consensus: We should have two declarations (stanzas) for p:declare-step, one for pipelines and one for atomic steps. We should restrict what can occur on p:output in the atomic step case.

### #451 Introduce a file system path → URI normalization function?

Some discussion of what to use for the base URI in the relative case. The “current working directory” would perhaps be best, but it’s not a universal concept. Using the static base URI is more common, but less useful.

• c:\path\to\file => file:/c:/path/to/file
• \\hostname\path\to\file => file://///hostname/path/to/file

It also escapes some characters, resolves ../, collapses multiple slashes, etc.

Next step: someone write up the details of the spec.

### #471 Note the possibility of different rules for step signatures

Nothing controversial here, really, but needs to be written up.

Some discussion of how this works; there’s a separate static analysis phase, etc. It’s a subprocess of some kind.

### #473 Scoping of static variables and options

From discussion this morning, they have lexical scopes and you cannot shadow static variables, even with a non-static variable.

### #482 Describe context node for p:document and p:inline

Some discussion about removing the rule that says that primary output ports have to be connected.

Proposal: remove the restriction that primary output ports must be connected. Simultaneously say that AVTs and TVTs get their context item from the default readable port.

Achim suggests a pipe attribute on p:document and p:inline to specify a different port. It did not garner support.

### #508 @expand-text of descendants of (implicit) inlines

Much discussion of a number of competing requirements:

• Inheriting the [p:]expand-text behavior
• Toggling expand text on-and-off within a p:inline
• Constructing pipeline documents in p:inline

Consensus: [p:]expand-text just controls the expand text feature; it has no effect within p:inline; if you want to toggle expansion on and off within a p:inline, use p:inline-expand-text which isn’t allowed anywhere else and can’t be quoted.

### #512 DTD-Validation with no designated grammar

Consensus: the proposal is correcgt; turning on dtd-validation enables a validating parser. Remove the “if it contains a doctype” condition.

Perhaps add a note saying that a document without a doctype declaration can never be DTD valid.

### #511 We need to say more about p:document-properties (and friends)

• If the item isn’t a document, then it’s properties are empty.
• If the document came from an XPath expression, then the processor should provide the base-uri and content-type properties.
• If a document is put in a variable, that should still work.

We need to say more about how the magic of document properties works. How implementations keep track of properties is implementation-dependent.

### #526 Current expand-text attribute refers to TVTs but not AVTs

Need to expand the description of expand-text to say that it applies to both TVTs and AVTs but only within a p:inline.

Consensus is to keep the name [p:]expand-text and p:inline-expand-text

### #11 Add a 'report' output port to all validation steps

General agreement about the report port.

Gerrit would be satisfied if the c:errors document appeared on the report port. It would be nice if the error location was available.

### #81 Fix http-request

Notes:

• The c:request becomes the parameters map
• The headers become either a new header map or a map-value’d ‘header’ key in the parameters map
• Maybe put href and method as separate options
• The input document(s) become the payload if applicable
• How do we send headers for multi-part parts?
• As document properties? Mixes document properties and request params
• As a sequence of c:body elements, and you’re responsible for serializing the parts? Doesn’t support unencoded, binary bodies.
• As a new step that composes a multipart payload?