New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On the subject of usability #562

Open
ndw opened this Issue Oct 17, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@ndw
Contributor

ndw commented Oct 17, 2018

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

This comment has been minimized.

Contributor

gimsieke commented Oct 17, 2018

There’s already a proposal for a step called p:message (xproc/3.0-steps#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

This comment has been minimized.

Contributor

ndw commented Oct 17, 2018

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

This comment has been minimized.

Contributor

gimsieke commented Oct 17, 2018

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

This comment has been minimized.

Contributor

ndw commented Oct 17, 2018

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

This comment has been minimized.

Contributor

gimsieke commented Oct 17, 2018

<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

This comment has been minimized.

Contributor

ndw commented Oct 17, 2018

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

This comment has been minimized.

Contributor

gimsieke commented Oct 17, 2018

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

This comment has been minimized.

Contributor

gimsieke commented Oct 17, 2018

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

@ndw ndw added the Deferred-to-4.0 label Oct 17, 2018

@eriksiegel

This comment has been minimized.

Contributor

eriksiegel commented Oct 17, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment