W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > August 2013

Re: bare bones requirements v2 document

From: James Fuller <jim@webcomposite.com>
Date: Sun, 4 Aug 2013 23:00:51 +0200
Message-ID: <CAEaz5msPt-NrdHm+n+=pfBj0GcpGLoFXAD8f+K6V-EW--=qEhg@mail.gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Cc: XProc WG <public-xml-processing-model-wg@w3.org>
ack - I will incorporate your much better words into the latest doc.

thx, J


On 4 August 2013 22:56, Norman Walsh <ndw@nwalsh.com> wrote:
> James Fuller <jim@webcomposite.com> writes:
>> I've dusted off the old document, updated it and annotated where we
>> need to provide more detail.
>
> Great. Thanks, Jim.
>
>> http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml
>
> I formatted it for the convenience of others:
>
>   http://www.w3.org/XML/XProc/docs/requirements-v2-jim.html
>
>> we need to discuss;
>>
>>    *  what we will include from other doc (Alex/Murray) in this
>
> I think Alex has agreed to work on the table of use cases/solutions as a note.
> I don't think anything else from that document, useful though it was for our
> discusions, needs to be published.
>
>>    * I would like to get a proposal for each the outstanding requirements
>
> I'd like to simply reword them as requirements. It isn't necessary,
> IMHO, to propose a solution with the requirement. It's ony necessary
> to crisply state the requirement so that solutions can be judged
> against it.
>
>>    * need to review unsatisfied v1 use cases for inclusion
>
> I'm not convinced this is necessary.
>
>>    * need to flag what we will address in bugzilla with v2.0
>
> Ok.
>
> In parallel with your effort, I've been drafting a mail message that outlines
> the requirements as I recall them. If you feel like copying any of this prose
> into the document, feel free.
>
>
> Requirements and use cases for XProc V.Next
> ===========================================
>
> Requirement: Abandon support for XPath 1.0
> ------------------------------------------
>
> Supporting XPath 1.0 and XPath 2.0 complicates the specification. In
> the V1.0 timeframe, it was necessary to consider implementations that
> might be based on XPath 1.0. That is no longer the case. XProc V.next
> must be based on the XQuery 1.0 and XPath 2.0 Data Model or its
> successors.
>
> Requirement: Simplify parameters
> --------------------------------
>
> The V1.0 parameters story is too complicated. XProc V.next must
> dramatically simplify parameters.
>
> Requirement: Support non-XML documents
> --------------------------------------
>
> Experience has shown that real-world pipelines encounter non-XML
> documents. The limitation that V1.0 can only pass XML between steps
> has proved to be inconvenient. Several workarounds have been invented
> for special cases. XProv V.next must allow non-XML documents to pass
> through a pipeline.
>
> Likely non-XML content types: JSON, Turtle, JSON-LD, Images.
>
> Requirement: Document metadata
> ------------------------------
>
> Some documents have associated metadata. For example, documents have a
> content type. XProc V.next should provide a mechanism for associating
> arbitrary metadata with documents.
>
> Requirement: Explicit dependencies
> ----------------------------------
>
> Sometimes the flow of control in a pipeline is not manifest from the data
> flow analysis and sometimes arranging for the data flow analysis to manage
> every dependency would require great complexity.
>
> There must be a simple mechanism for asserting that step A must run
> before step B, even if B has no data flow dependency on A.
>
> Requirement: Fully general XDM values
> -------------------------------------
>
> Variables, options, and parameters must be able to hold aribtrary XDM
> values, including sequences and nodes.
>
> Requirement: Steps with varying numbers of inputs and outputs
> -------------------------------------------------------------
>
> Some pipeline steps (split, join, nvdl, eval) don't naturally have a
> fixed number of inputs and outputs. It should be possible to write
> pipelines such that the number of inputs and outputs varies.
>
> Requirement: Improved status/debugging information
> --------------------------------------------------
>
> Pipelines should have a simple mechanism for writing status and
> debugging messages.
>
> Requirement: Syntactic simplifications
> --------------------------------------
>
> V1.0 is more verbose than necessary. We should consider simplifications.
>
> * Attribute value templates must be supported option shortcuts
>
> * <p:pipe step="name"/>
>
>   should bind to the primary output port of the step named 'name'. It
>   is an error if there is no such primary output port.
>
> * <p:pipe port="secondary"/>
>
>   should bind to the 'secondary' port of the step on which the default
>   readable port occurs. It is an error if there is no such step.
>
> * <p:input port="portname"/>
>
>   should be a shortcut for an empty binding.
>
> * <p:input port="portname" href="..."/>
>
>   should be a shortcut for a document binding to the URI specified in href.
>
> * No non-default outputs
>
>   all standard steps should have at least one primary output port.
>
> * Allow data types on variables, options, and parameters
>
>   it should be possible to specify the data type of variables, options, and parameters.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com
Received on Sunday, 4 August 2013 21:01:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:51 UTC