Some remarks about the 10 June 2015 Editor's draft

Hi all,

I took a look (a fresh one, after months of XProc abstinence) at the latest Editor's draft (10 June 2015) to catch up with the latest developments and here are some of my remarks. I understand many of this is likely still work in progress by the WG so my apologies if I am just re-iterating some of the known items. Anyway, here it is:

1. Introduction
"[...] the inputs of a step come from the WEB, [...]"
I think the web is just one of the possible external data sources.

2. Pipeline concepts
"A pipeline is a set of connected steps, with outputs of one step flowing into inputs of another."
I am probably nit-picking here, but note that it is perfectly feasible to create an XProc pipeline where none of the contained steps are connected together.

2.1 Steps
"All steps have an implicit output port for reporting errors that must not be declared."
Does the error port have a name? If so, shouldn't it be mentioned here?

2.2 Documents
"Definition: A representation is a data structure used by an XProc processor to refer to the actual document content."
I assume this is the "outside world" presentation - how the document is represented on the XProc pipeline level and not how the XProc processor represents the document internally. Maybe this can be made clearer.

2.3 Inputs and Outputs
Probably a typo: "from the perspective of the compound step's siblings, its outputs are just ordinary outputs and can be connected ***the sames other*** declared outputs"

"Steps may also produce error, warning, and informative messages. These messages are captured and provided on the error port inside of a p:catch."
What about the implicit error output port mentioned in 2.1?

"[...] it is a dynamic error (err:XD1003) if an input document that arrives on the port has a content type that does not match any content type in that set."
What does "matching content type" mean here? Is there a precise definition somewhere?

2.3.1 External Documents
"In Version 2.0 of XProc, how (or if) implementers provide local resolution mechanisms and how (or if) they provide access to intermediate results by URI is implementation-defined."
I probably come late to the discussion here, but what is the rationale for including this in the spec? I think allowing URI-based access to intermediate results is a slippery slope. I think that on the XProc level, the intermediate documents that are meant to flow through the pipeline should remain transient and accessible only by step connections. Otherwise I can only see issues: interoperability, dependency graph, p:set-properties, ... In cases URI dereferencing is needed, I think this can be made explicit (by using special steps for that purpose etc.)

2.5 Connections
"An output port may have multiple consumers and this results in multiple connections. A subset of these connections are the input port connections for various sibling or contained steps."
I don't understand the last "or contained steps" bit. An example?

2.6 Environment
It occured to me that perhaps the environment should also include the step types that are in scope for the step. Otherwise how could the p:step-available() function support nested step declarations?

2.7 XPaths in XProc
"XPath expressions are evaluated by the XProc processor in several places: on compound steps, to compute the default values of options and the values of variables; on atomic steps, to compute the actual values of options."
Replace the final period with etc.?

2.10 Value Templates:
Typo: "An expression within a variable part may contain an unescaped curly bracket within a string ***literals*** or within a comment."

2.10.2 Text Value Templates
"The expand-text attribute may appear on p:inline (and its parents in the case where the p:inline is omitted)."
So expand-text cannot be used on the parent if p:inline is present?
Also, how can p:inline have a parent if it is omitted? :)

2.14.2.1 Examples
"Suppose that XProc version 2.0 changes [...]"
Maybe "a future version of XProc" is better?

3.3 Base URIs and xml:base
"When a relative URI appears in an option value [...]", "In general, whenever a relative URI appears [...]"
How do we know that a relative URI appeared in an option value? Isn't it more the other way around, that the semantics of the option dictates whenter the value is to be interpreted asn an URI?

3.4 Unique identifiers
"A pipeline author can provide a globally unique identifier for any element in a pipeline with the xml:id attribute"
I assume the scope here is the pipeline XML document and not the pipeline (with resolved imports etc.), correct?

3.5 Associating Documents with Ports
"A document or a sequence of documents can be connected to a port in four ways: by source, by URI, by providing an inline document, or by making it explicitly empty"
Does "by source" also include the implicit connections manufactured by the processor here?

4.6 p:try
"The last p:catch must not have a code attribute; it is selected if no preceding p:catch has a matching error code."
Wouldn't "The last p:catch MAY NOT have a code attribute; in that case it is selected if no preceding p:catch has a matching error code." provide better usability?

5.1 p:input
What is the default value for content-types if the attribute is absent?

5.8 p:declare-step
Shouldn't it move closer to the beginning of section 5? It feels really buried in the prose given its importance.

----

XProc 2.0: Standard Step Library

1.1.4 p:compare
"This step takes single documents on each of two ports and compares them using the fn:deep-equal."
The step is declared to accept any content type, so what happens for non-XML documents (where fn:deep-equal() isn't applicable)?

1.1.14 p:insert
1.1.21 p:replace
1.1.22 p:set-attributes
1.2.2 p:hash
1.2.4 p:template
1.2.5 p:uuid
1.2.6 p:validate-with-relax-ng
1.2.7 p:validate-with-schematron
1.2.8 p:validate-with-xml-schema
1.2.10 p:www-form-urlencode
I don't think these steps should support non-XML documents

Regards,
Vojtech