2014-11-26 Draft Review

Review of XProc 2.0: An XML Pipeline Language [1]:

1. Introduction

   * change "collection of XML input documents." to "collection of
input documents."

   * I wonder whether "zero or more" throughout the section is
necessary.  Should "documents" suffice as it is a non-normative intro?

   * we should define that document and explain it can be anything
with a media type

   * For thought for the future:

       - it would be nice if we could unify "compound step" and
"multi-contianer step
       - a better diagrams for figure 1 etc.?
       - all our examples use 'p:pipeline' :(

2. Pipeline Concepts

   * Not sure I agree with this:

       "Unless otherwise indicated, implementations must not assume
that steps are functional (that is, that their outputs depend only on
their inputs and options) or side-effect free."

      ... side-effect free, no guarantee ...
      ... but there is a functional story to tell.

2.1 Steps

   * Change:
      "[Definition: An atomic step is a step that performs a unit of
XML processing, such as XInclude or transformation, and has no
internal subpipeline. ] Atomic steps carry out fundamental XML
operations and can perform arbitrary amounts of computation, but they
are indivisible. An XSLT step, for example, performs XSLT processing;
a Validate with XML Schema step validates one input with respect to
some set of XML Schemas, etc."

      to:

      "[Definition: An atomic step is a step that performs a unit of
processing on its input, such as XInclude or transformation, and has
no internal subpipeline. ] Atomic steps carry out fundamental
operations and can perform arbitrary amounts of computation, but they
are indivisible. An XSLT step, for example, performs XSLT processing ;
a Validate with XML Schema step validates one input with respect to
some set of XML Schemas, etc.

    * Should the reference to the standard step library ( Section 2,
“Standard Step Library”) be more explicit?

    * In 2.1.1, break the paragraph at "For example, consider the pipeline"

    * For thought for the future:
        - too dense
        - too terse
        - too many important topics in quick succession

2.8 XPath Extension Functions

    * For thought for the future: it is clear to me, at least, that we
need a document-node() representation for non-XML documents.  One easy
way out of that document is some minimal xml representation for all
non-XML documents that yields minimal metadata.  Yet, doing so paints
us into a corner.  Some venders choose to extend the XDM to handle
specific types like JSON.  We can't do that universally so that is
also another dead end.  Some careful thought is required here.

2.9 PSVIs in XProc - needs to go away!

2.14 Versioning Considerations

    * Change to 2.0 in "The version of XProc defined by this
specification is “1.0”."

3.5  Associating Documents with Ports

    * Future:  It occurs to me that we may want to allow p:inline to
support non-XML text/* media types (see 5.12 p:inline)


3.7 Extension attributes

   * Future: We should allow RDFa attributes everywhere.

3.9 Conditional Element Exclusion

   * Has this ever been used in practice?

4. Steps

    * This is no longer true:

    "This section describes the core steps of XProc.

Several of the steps defined in this specification refer to other,
evolving XML technologies (XSLT, XQuery, XSL-FO, etc.). Where this
specification identifies a specific version of a technology,
implementers must implement the specified version or any subsequent
edition or version that is backwards compatible. At user option, they
may support other, incompatible versions or extensions."

    How about:

    "This section describes the container and multi-container steps of
XProc.  The atomic steps are described in a separate specification
..."

    and delete the second paragraph.

4.3 p:viewport

    * requires an XML input document ... do we say this?

4.6.1 The Error Vocabulary (and other places)

    * Future: we might want to consider how c:error and other bits are
turned into things like JSON

4.7 Atomic Steps

   * Is this section necessary?
   * If so, it should be earlier in the document.

4.8.1 Syntactic Shortcut for Option Values

  * Future: this section does not belong here and should be much
earlier in the document

5.6 p:serialization

   * Future: we may wish to consider how serialization is generalized


I haven't an substantial comments on the steps specification [2]
except for items for future consideration:

   * p:load/p:store need to handle non-XML
   * p:http-request needs to output non-XML documents

[1] https://xproc.github.io/specification/langspec/xproc20/head/xproc20/
[2] https://xproc.github.io/specification/langspec/xproc20/head/xproc20-steps/



-- 
--Alex Miłowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Wednesday, 3 December 2014 13:53:13 UTC