Just pipes and flows was Re: Adjusting Syntax & Semantics - removing the need for port variables, block expressions, and other declarations

After yesterdays meeting had a helpful chat with Alex who clarified a
lot of things for me.

We are bumping up against complexity and confusion because of the
tensions betwixt vars, options, ports, inputs/outputs etc. This is not
at all helped by the 'nomenclature menagerie' of

* options
* variables
* port
* pipelines
* connections
* inputs/outputs
* pipes
* flows
* chains

====================
Possible next step ?
====================

If we synthesize from previous discussions there maybe a way to
simplify so we only define:

* flows
* pipes
* variables

xproc version = "2.0";

  @source as document-node();
  @result as document-node();
  $version as xs:decimal = 3.0;

@source
  → if (xs:decimal(/*/@version) < $version)
       then [schema="v1schema.xsd"] → validate-with-xml-schema()
       else [schema="v2schema.xsd"] → validate-with-xml-schema()
  → [@(),"stylesheet.xsl"]
  → xslt()
  ≫ @result

where the entire example is a flow and:

* @ denotes named pipe
* $ declares a variable which becomes part of the signature of the
flow (aka option) - we can consider how to annotate things like
'required' in the future
* in scope pipes are referenced with @ or @() ex. @source, @result,
@schema, @(), @(1)

This clarifies that

* -> passes inscope pipes to next step
* >> appends to a pipe

Another example for discussion fodder:

xproc version = "2.0";

  @source as document-node();
  @result as document-node();
  $version as xs:decimal = 3.0;

@source
  → if (xs:decimal(/*/@version) < $version)
       then [schema="v1schema.xsd"] → validate-with-xml-schema()
       else [schema="v2schema.xsd"] → validate-with-xml-schema()
  → [@(),"stylesheet.xsl"]
  → xslt()
  ≫ @myresults as document-node()

"http://www.example.org/someotherdata.xml"
  ≫ @result

@myresults
  → add-attribute(match="/",attribute-name="id", attribute-value="
el{count($myresults)}")
  ≫ @result

We would expect @result pipe to contain someotherdata.xml +
adulterated @myresults.

One might access current contents of a pipe by referencing the pipe as
a variable ex. $pipe gets the actual current context on @pipe. I am
not sure count($myresults) does what I think it should but added it to
provoke comment. Doing anything like this obviously would have an
impact on speed, streaming etc.

I have a follow up synthesis to flow decl but that depends if the
above is acceptable or just the rantings of a mad man.

thx, J

Received on Thursday, 21 April 2016 10:56:06 UTC