- From: Norman Walsh <ndw@nwalsh.com>
- Date: Tue, 09 Dec 2014 11:44:37 -0600
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <878uig90qi.fsf@nwalsh.com>
Alex Miłowski <alex@milowski.com> writes:
> Review of XProc 2.0: An XML Pipeline Language [1]:
>
> 1. Introduction
>
> * change "collection of XML input documents." to "collection of
> input documents."
Done.
> * I wonder whether "zero or more" throughout the section is
> necessary. Should "documents" suffice as it is a non-normative intro?
We can give that a try.
> * we should define that document and explain it can be anything
> with a media type
We do say that in section 2.2.
> * 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' :(
Yes on all counts, but not for FPWD.
> 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.
Purely functional? Anyway, alternate wording proposals gleefully
accepted, but this isn't new text so I'm going to leave it for now.
> 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.
Ok.
> * Should the reference to the standard step library ( Section 2,
> “Standard Step Library”) be more explicit?
Yes. Fixed.
> * 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
Ok. In a future draft.
> 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.
Yes. I'm starting to lean back towards having a token XML
representation for non-XML documents. I'm not sure what (if anything)
we can do about vendors that extend the XDM in proprietary ways (he
says without irony).
> 2.9 PSVIs in XProc - needs to go away!
Moved to an appendix, perhaps, but I don't see how it can go away. Are
you proposing that the psvi-required and p:psvi-supported should also
go away?
> 2.14 Versioning Considerations
>
> * Change to 2.0 in "The version of XProc defined by this
> specification is “1.0”."
Uh huh. :-)
> 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)
"Maybe."
> 3.7 Extension attributes
>
> * Future: We should allow RDFa attributes everywhere.
In a namespace, or not in a namespace?
> 3.9 Conditional Element Exclusion
>
> * Has this ever been used in practice?
Yes.
> 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.
I did something like that.
> 4.3 p:viewport
>
> * requires an XML input document ... do we say this?
I have now, albeit rather subtly. I think we'll need to address in
some explicit and consistent way what the input documents can be. I
also added a dynamic error to the p:input section about the use of
select with non-XML documents.
> 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
Yes.
> 4.7 Atomic Steps
>
> * Is this section necessary?
> * If so, it should be earlier in the document.
Ok. We can consider that as part of the general "let's make the ToC
make sense" exercise.
> 4.8.1 Syntactic Shortcut for Option Values
>
> * Future: this section does not belong here and should be much
> earlier in the document
Ok. Ditto.
> 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
I did a little cleanup and added some editorial notes to point to issues.
Be seeing you,
norm
--
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com
Received on Tuesday, 9 December 2014 23:38:06 UTC