Re: Henry's proposed syntax change

/ Richard Tobin <richard@inf.ed.ac.uk> was heard to say:
| 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.

Neither of these strike me as ideal. But I agree both would work. I
think I have a marginal preference for using the local name of the
type.

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

| 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.

Isn't this conflating two things? Couldn't we equally say that

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

is equivalent to

<p:declare-step ...attrs...>
  ...content...
</p:declare-step>

and (continue to) require that all the inputs and outputs on a
p:pipeline must be declared.

| [???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.

I wonder if we could get away with requiring the type on p:pipeline...

| 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

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If God created us in his own image, we
http://nwalsh.com/            | have more than reciprocated.-- Voltaire