Re: Possible conditional construct for discussion

Murray Maloney wrote:

> I know that this is coming from left field and that I am not an implementor,
> however please consider the following as my suggestion toward a bit of
> the overall syntax. Notice that the steps no longer declare their 'type';
> instead, I have made step a wrapper for an <p:xslt> or <p:xinclude> or
> whatever components we make public. I am imagining that such elements
> definitions would include subordinate elements for an appropriate number of
> <input>, <output> and <param> elements, plus whatever other elements
> might be appropriate to the specific component.

I'd prefer this to what we have now.  That is, I'd prefer that a step's
name is the name of the element much like actions are distinguished
elements in XSLT templates.

I have some inline notes below.

> I imagine that components would prescribe the names to be used for
> their input and output interfaces, for example in cases where a
> component has multiple inputs or outputs with distinct roles.
> 
> <p:flow>
>    <input name="source" src="file:stdin" />

I think we need to distinguish on inputs

    * references to outputs of other steps
    * references to external inputs
    * declarations of unbound inputs:

For example, an input to a pipeline might be two of
the above:
    * the implicit "input" bound to a name via the
      environment (e.g. a command-line option)

      <input name="source"/>

    * an ancillary file reference via an embedded relative
      URI:
       <input name="source" href="somebits.xml"/>


I don't think we need to invent a URI syntax for stdin, stdout, etc.
as that can be bound by name by the tool/implementation environment
(e.g. xproc -stdin input.xml -stdout output.xml mypipe.pd)


>    <output name="result" src="#inc.result"/>

Here I think fragment identifier might be useful:

    * A simple NCName value would be the constructed name
      of some output.  This is a good reason why the '.' notation
      might be the right choice of syntax.

    * Other parts could be referenced with a Xpointer link scheme:

      #xproc(step::p:xslt/input::source)

>    <choose>
>       <input src="#source"/>
>       <output name="cond.result"/>

Here's a bit where the prefix notion for output naming could
be difficult to understand.  So, here the author has constructed
a name that looks like a step result (e.g. 'cont.result').  To
be consistent, we'd have to name the choose:

    <choose name="cond">
       <input src="#source"/>
       <output name="result"/>

...but that seems strange to me.

Maybe names are just optional attributes that can be used.
If you don't want to name something, then you can use the #xproc()
fragment identifier scheme.

> I also imagine the possibility of an equivalent to a UNIX 'here' 
> document, where
> I can for example write
> 
>         <input name="boilerplate">
>                 <P>Here is the XML document that I want to process</P>
>         </input>

Yes!  I really want/need the ability to embed an input.  Putting right
where the input is declared would be really convenient.

--Alex Milowski

Received on Thursday, 22 June 2006 18:57:36 UTC