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

p:message, an improved cx:message step #2

Open
mkraetke opened this Issue Jun 27, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@mkraetke

mkraetke commented Jun 27, 2017

This proposal was originally posted on xproc-dev@w3.org at 7th March, 2017.

The basic behaviour of p:message should be like cx:message but I would add a new output port and some new options which make it easier to debug pipelines:

<p:message xmlns:p="http://www.w3.org/ns/xproc">
  <p:input port="source"/>
  <p:output port="result"/>
  <p:output port="report"/>                  <!-- c:report -->
  <p:option name="select" required="true"/>  <!-- XPathExpression -->
  <p:option name="abort"/>                   <!-- true|false -->
  <p:option name="code"/>                    <!-- QName -->
  <p:option name="code-prefix"/>             <!-- NCName -->
  <p:option name="code-namespace"/>          <!-- anyURI -->
  <p:option name="severity"/>                <!-- String -->
</p:message>

The source and result port is similar to cx:message. The report provides a c:report document which contains the report message.

I've added also an option to terminate the pipeline which is named "abort" according to our discussion in prague. Like p:error, the step contains the options "code", "code-prefix", "code-namespace" to provide an error code. The "severity" option can contain arbitrary strings such as "info", "warning". The severity would be added as attribute to c:report and can accompany the message at stdout.

@vojtechtoman

This comment has been minimized.

Show comment
Hide comment
@vojtechtoman

vojtechtoman Jun 27, 2017

Collaborator

What does 'terminating the pipeline' mean exactly? Just raising a dynamic error with the provided code, or really terminating the execution of the entire pipeline? What happens if abort is true but code is not specified?

Collaborator

vojtechtoman commented Jun 27, 2017

What does 'terminating the pipeline' mean exactly? Just raising a dynamic error with the provided code, or really terminating the execution of the entire pipeline? What happens if abort is true but code is not specified?

@mkraetke

This comment has been minimized.

Show comment
Hide comment
@mkraetke

mkraetke Jun 27, 2017

Terminations should be similar to the termination of a regular step like p:xslt. You should catch the error with p:try/p:catch. The error output should be similar to p:error. When abort has the value true, you have to add an error code. code-prefix, code-namespace should be optional.

mkraetke commented Jun 27, 2017

Terminations should be similar to the termination of a regular step like p:xslt. You should catch the error with p:try/p:catch. The error output should be similar to p:error. When abort has the value true, you have to add an error code. code-prefix, code-namespace should be optional.

@bertfrees

This comment has been minimized.

Show comment
Hide comment
@bertfrees

bertfrees Feb 7, 2018

We have been using a px:message in the past but are switching to a custom px:message attribute now for a number of reasons:

  • The execution order problem: it is not guaranteed that the message step is executed immediately before the step it "precedes" because the processor determines the execution order. Even worse, if there is no document to pipe through the message step, which is sometimes the case, it is not even guaranteed that the message step is executed before the next step at all (we needed to use the cx:depends-on attribute in several places). With an attribute this guarantee can be made.
  • We want to be able to associate a message with a step for the full length of the step's execution (for generating progress information).
  • A step is more verbose than an attribute.

bertfrees commented Feb 7, 2018

We have been using a px:message in the past but are switching to a custom px:message attribute now for a number of reasons:

  • The execution order problem: it is not guaranteed that the message step is executed immediately before the step it "precedes" because the processor determines the execution order. Even worse, if there is no document to pipe through the message step, which is sometimes the case, it is not even guaranteed that the message step is executed before the next step at all (we needed to use the cx:depends-on attribute in several places). With an attribute this guarantee can be made.
  • We want to be able to associate a message with a step for the full length of the step's execution (for generating progress information).
  • A step is more verbose than an attribute.
@mkraetke

This comment has been minimized.

Show comment
Hide comment
@mkraetke

mkraetke Feb 7, 2018

  • On the exec order issue: I see two possible but contradicting solutions to this problem: First, the spec could stipulate that p:message should immediately executed after the preceding step in pipeline order. Think of an implicit cx:depends-on. Second, we just drop the option to terminate the pipeline execution.
  • I like the idea of a generic message attribute in XProc. But in contrast to a separate step, you cannot specify the context of the message. I assume the message would always apply to the primary output port of the step.
  • What if we have a generic element which can be a child of a specific step:
<p:identity>
  <p:message select="'what's in the base attribute?', /*/@xml:base" port="result"/>
</p:identity>

mkraetke commented Feb 7, 2018

  • On the exec order issue: I see two possible but contradicting solutions to this problem: First, the spec could stipulate that p:message should immediately executed after the preceding step in pipeline order. Think of an implicit cx:depends-on. Second, we just drop the option to terminate the pipeline execution.
  • I like the idea of a generic message attribute in XProc. But in contrast to a separate step, you cannot specify the context of the message. I assume the message would always apply to the primary output port of the step.
  • What if we have a generic element which can be a child of a specific step:
<p:identity>
  <p:message select="'what's in the base attribute?', /*/@xml:base" port="result"/>
</p:identity>
@bertfrees

This comment has been minimized.

Show comment
Hide comment
@bertfrees

bertfrees Feb 7, 2018

Thanks. I like the child element proposal. It's indeed more powerful without the need for more attributes (e.g. message-severity and progress in our case).

However, one thing I should add is that our custom attribute is allowed not only on steps but also on p:group, p:choose, p:when, p:otherwise, p:try, p:for-each and p:viewport. So by supporting only the child element you loose this possibility unless you support it inside all of these element as well.

In my attribute solution the message (which is an AVT) gets evaluated in the context of the primary input port I think, or maybe there is no context at all, I'm not sure. To evaluate against an output port could be a use case but it also means that the message can not be produced before the document appears on the output port, which is something the user should be well aware of I think.

The implicit cx:depends-on sounds a bit like a hack.

bertfrees commented Feb 7, 2018

Thanks. I like the child element proposal. It's indeed more powerful without the need for more attributes (e.g. message-severity and progress in our case).

However, one thing I should add is that our custom attribute is allowed not only on steps but also on p:group, p:choose, p:when, p:otherwise, p:try, p:for-each and p:viewport. So by supporting only the child element you loose this possibility unless you support it inside all of these element as well.

In my attribute solution the message (which is an AVT) gets evaluated in the context of the primary input port I think, or maybe there is no context at all, I'm not sure. To evaluate against an output port could be a use case but it also means that the message can not be produced before the document appears on the output port, which is something the user should be well aware of I think.

The implicit cx:depends-on sounds a bit like a hack.

@mkraetke

This comment has been minimized.

Show comment
Hide comment
@mkraetke

mkraetke Feb 7, 2018

As XProc programmer, I would found it more coherent that the p:message (as attribute) applies to the primary output of the step where it is attached. If there is no primary output port declared in the spec or explicitely specified, there should be just a warning message. Otherwise it would confuse users what's the real context. For example, if a p:message at a p:viewport would provide the input at the current port, a user would think that his subpipeline in p:viewport might have no effect. However, I would like to have p:message both as element and attribute.

mkraetke commented Feb 7, 2018

As XProc programmer, I would found it more coherent that the p:message (as attribute) applies to the primary output of the step where it is attached. If there is no primary output port declared in the spec or explicitely specified, there should be just a warning message. Otherwise it would confuse users what's the real context. For example, if a p:message at a p:viewport would provide the input at the current port, a user would think that his subpipeline in p:viewport might have no effect. However, I would like to have p:message both as element and attribute.

@ndw

This comment has been minimized.

Show comment
Hide comment
@ndw

ndw Sep 6, 2018

Collaborator

Probably should rename this p:log, but seems fine to me.

Collaborator

ndw commented Sep 6, 2018

Probably should rename this p:log, but seems fine to me.

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