On the subject of usability

[ndw]

I was just writing a little demo pipeline when I came to this:

...
<p:otherwise>
  <p:identity>
    <p:with-input>
      <p:inline>Something went wrong</p:inline>
   </p:with-input>
  </p:identity>
</p:otherwise>

I wonder if p:message as a syntactic shortcut for this form of p:identity would be a win.

<p:otherwise>
  <p:message>Something went wrong</p:message>
</p:otherwise>

Maybe p:message isn't the ideal name.

[gimsieke]

There’s already a proposal for a step called p:message (https://github.com/xproc/steps/issues/2). Also, there’s the proposed p:message option (#29). What your p:message does is not emitting a message (to stderr or stdout) at all, but it returns a text document. I don’t think we need an extra element for this.

Can we probably adopt a broader definition of implicit inlines? That is: When you write <p:identity>Something went wrong</p:identity>, not only will the missing p:inline be “inserted” by the processor but also the p:with-input for the primary input.

[ndw]

Indeed, the p:message above is nothing like the proposed step. So one of them needs a different name. And I concede that the step and the attribute do quite different things, so probably this one.

I considered the broader definition, but it's quite complex to formulate:

If a step has exactly one primary input port and exactly one primary output port, then if it is not empty and contains no elements in the XProc namespace, then the content is treated as if it were inside a p:inline inside a p:with-input. In all other cases, such content is a static error

Yuck.

It seems simpler to me to have a rule like

The [insert name of step here] element is a syntactic shortcut for a specific form of the p:identity step. The content of the element is treated as inline content passed to the source port of an identity step. An occurrence of <[insert name of step here]>something</[insert name of step here]> is exactly equivalent to <p:identity><p:with-input><p:inline>something</p:inline></p:with-input></p:identity>

Or words to that effect.

Maybe this complexity isn't worth doing, but the otherwise clause that sends some default output feels like a pretty common case and the current solution is definitely a lot of typing.

But I don't know.

[gimsieke]

Still, I’d like to propose an extended notion of implicit inlines instead of a shortcut for p:identity with implicit primary port binding. Like:

<p:add-attribute attribute-value="{count(collection())}" collection="true" attribute-name="bar">
  <foo/>
</p:add-attribute>
⇒ <foo bar="3"/>

<p:wrap wrapper="foo"><bar/></p:wrap>
⇒ <foo><bar/></foo>

<p:wrap-sequence wrapper="foo"><bar/><baz/></p:wrap-sequence>
⇒ <foo><bar/><baz/></foo>

Extended notion means: You can omit the p:with-input primary port binding in addition to the p:inline. We can specify that all non-XProc, non-withespace nodes will be implicitly fed into the primary input, with the usual error checking (if sequence is not true, only a single element is allowed; text nodes are only allowed if the step’s primary input accepts text/*; etc.).

[ndw]

What do you propose to say about steps that have more than one input? Is this allowed?

<p:insert position="first-child">
<doc/>
</p:insert>

What does it mean?

[gimsieke]

<p:insert position="first-child">
  <doc/><!-- primary input-->
  <p:with-input port="insertion"><foo/></p:with-input>
</p:insert>
⇒ <doc><foo/></doc>

(Comments and PIs probably need to be ignored, like whitespace nodes at the top of an implicit inline.)

[ndw]

That didn't really answer my question. I assume that your answer to my question is that <doc/> is the primary input and the secondary input comes from the default-readable-port.

[gimsieke]

As I said above: The non-XProc (namespace) children (of p:insert, in this case) will be treated as the primary input (wrapped in document nodes if necessary). The non-primary inputs need at least a p:with-input around them before they also can be given as implicit inlines. The DRP in the example above will not be considered because both inputs of p:insert have been explicitly connected (to inlined content).

[gimsieke]

In your example, the secondary input won’t be connected, that means, an empty sequence appears on the insertion input, which effectively leaves the primary input as it is. If secondary inputs were not specified as sequence, an error would be raised if there was no connection given (they won’t read the DRP, will they?).

[xatapult]

Yeah, deferred sounds good. Too many complications...

[xatapult]

We close it for now.