Re: 2014-11-26 Draft Review

Also, maybe we need a section in the introduction that enumerates
changes from XProc 1.0

On Wed, Dec 3, 2014 at 5:52 AM, Alex Miłowski <alex@milowski.com> wrote:
> 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



-- 
--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 14:45:15 UTC