Re: bare bones requirements v2 document

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