Henry's proposed syntax change

I discussed the proposed syntax change with Henry.  Here is my
understanding of it.  Possible variations are marked with [???x].

The fundamental step-declaring element is p:declare-step.  Either it
contains nothing except port and option declarations (the current
form), or it also contains a subpipeline and its output port
declarations are also bindings.

The type attribute on declare-step is required, so all pipelines
declared this way have types.  [???1] There are two obvious
possibilities for how to refer to pipeline input ports within the
subpipeline: either by omitting the step attribute, or by using the
local part of the type as the step name.

Non-primary input ports are always allowed content to specify a
default.

Examples:

<!-- as before -->

<p:declare-step type="p:identity">
     <p:input port="source" sequence="true"/>
     <p:output port="result" sequence="true"/>
</p:declare-step>

<!-- new form of pipeline declaration -->

<p:declare-step type="myns:mypipe"
                xmlns:myns="..."  xmlns:p="http://www.w3.org/ns/xproc">

<p:input port="in"/>
<p:output port="out"/>

<p:xslt name="rot13">
  ...
</p:xslt>

</p:declare-step>

p:pipeline-library is renamed p:library, because (a) it can contain
atomic steps as well as pipelines and (b) the "pipeline-" is implicit
in the namespace.  It acts only as a container (to allow multiple
declare-steps in one file) and as a scope (so that the pipelines
inside it can refer to each other).  It doesn't have a namespace
attribute, but will typically have a namespace declaration for
the prefix used on the types of the contained declare-steps.

Both p:library and p:declare-step are allowed as top-level elements.

Because p:declare-step has a type attribute, there is no problem
with recursive calls.

Note that type and name attributes have more clearly separated roles:
name is used on uncallable things just to provide a way to refer to
ports, and type is used on callable things.  There is no magic
construction of types from names.

At this point, we can do everything.  p:pipeline is introduced merely
as an abbreviation.  It's only allowed as a top-level form, and

<p:pipeline ...attrs...>
  ...content...
</p:pipeline>

is equivalent to

<p:declare-step ...attrs...>
  <p:input name="source"/>
  <p:ouput name="result"/>
  ...content...
</p:declare-step>

[???2] Should the input and output have accessible names, or should
they have unreferencable ones?  From the internal point of view,
unreferencable ones would be reasonable, but I think we need to
be able to *call* them from arbitrary pipelines where the port
names need to be specified.

So a pipeline with a single input and output needs no port
declarations.

[???3] The type attribute is optional on p:pipeline.  If omitted, the
pipeline cannot be called recursively or externally, and depending on
how we resolve ???1 it's either possible or impossible to refer to the
ports explicitly inside.  You can of course have a pipeline in no
namespace (type="foo") though this is inadvisable if you want to
import it.

Syntax summaries (from Henry, done at last minute and may still have bugs):

<p:declare-step
  ignore-prefixes? = prefix list
  xpath-version? = string
  type = QName>
    (p:input |
     p:output |
     p:option |
     p:import |
     p:declare-step |
     p:log |
     p:serialization)*
     _subpipeline_
</p:declare-step>

Ignore-prefixes and xpath-version are only allowed on top-level
declare-steps.  Import and declare-step are only allowed when there's
a subpipeline.  But serialization is allowed on all declare-steps
(which it wasn't before) reducing the difference between built-in and
pipeline steps; it only has effect when the step is run at top-level.
The declaration visibility story needs to be updated now that
declare-step can occur inside itself.

<p:library
  ignore-prefixes? = prefix list
  xpath-version? = string>
    (p:import |
     p:declare-step)*
</p:library>

<p:pipeline
  ignore-prefixes? = prefix list
  xpath-version? = string
  type? = QName>
    (p:input |
     p:output |
     p:option |
     p:import |
     p:declare-step |
     p:log |
     p:serialization)*,
    subpipeline
</p:pipeline>

-- Richard

Received on Thursday, 20 December 2007 15:00:37 UTC