-
Notifications
You must be signed in to change notification settings - Fork 0
Minutes 05 06 September 2018
- 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.
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.
#340 Formalize "injecting" trace information into a pipeline
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.
Added examples to the issue:
-
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
Discussion about whether or not AVTs and TVTs should have access to a context node through the default readable port.
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.
See #397 for more information about the standard reporting language.
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?
Follow Adam’s lead from http://expath.github.io/expath-cg/specs/http-client-2/
A big thank you to Gerrit and le tex for hosting us!