W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > September 2007

RE: An unfulfilled requirement maybe?

From: Vasil Rangelov <boen.robot@gmail.com>
Date: Sun, 30 Sep 2007 11:45:43 +0300
To: <public-xml-processing-model-comments@w3.org>
Message-ID: <46ff6255.0116300a.5254.fffff485@mx.google.com>

>I may have missed something :
>Isn't your stdout-is-xml = true equivalent to wrap-stdout-lines = false ?
>Since you don't wrap it, it just must be XML per XProc spec, isn'it ?

No. wrap-stdout-lines = false means you get the output as one big plain
ESCAPED text, for the sake of well formdness. If the program returns
<root/>
<root/>
What you get is
<c:result>
	<c:line>&lt;root/&gt;</c:line>
	<c:line>&lt;root/&gt;</c:line>
</c:result>
And with wrap-stdout-lines = true, you get
<c:result>&lt;root/&gt;
&lt;root/&gt;</c:result>

What the stdout-is-xml = true is trying to do is to override this behavior
so that the above program would return
<root/>
<root/>

> I'm tempted to suggest a "stdout-is-xml" option that treats stdout as
> XML and returns a document. But maybe it's ok to just require the
> unescape-markup step. You could always write your own pipeline to do
> that.

It may be better without it. One reason are sample programs like above (to
which the step may just fail) and also that if stdout-is-xml = true, then
wrap-stdout-lines must be ignored altogether (a sort of conditional options
- a thing XProc doesn't have, and which I'm betting will be left out for
V1). It's not a big loss anyway. As you said, you could always write your
own pipeline to do that.

On 9/30/07, Norman Walsh <ndw@nwalsh.com> wrote:
> | Oh, and one last thing I forgot when I suggested this. Implementations
> | should probably be allowed to read additional non standard streams,
provided
> | they mark them in c:other element within the c:result element.
>
> I prototyped a slightly different model:
>
> <p:declare-step type="px:exec">
>  <p:input port="stdin"/>
>  <p:output port="stdout" primary="true"/>
>  <p:output port="stderr"/>
>  <p:option name="command" required="true"/>
>  <p:option name="args"/>
>  <p:option name="wrap-stdout-lines" value="false"/>
>  <p:option name="wrap-stderr-lines" value="false"/>
> </p:declare-step>
>
> It seems to work pretty well, naming aside.

I can't figure this out... what and how goes in the input port? I mean, how
is the application and/or CLI connected to the input port?

If "command" is suppose to contain the full command (i.e. the path to the
program and it's arguments), what does the "args" option carry? If "command"
is supposed to be only the program's location... why? And that "command"
would be a misleading name in that case is another question.

I assume both output ports will have <c:result/> elements with <c:line/>
elements (if not prohibited by the wrap-*-lines options of course), right?

What happens if a program has only errors? Is the primary output port still
populated and if not, wouldn't that cause the step to fail (even though
there's contents in the error stream)? Would making it non-primary solve
this?

Regards,
Vasil Rangelov
Received on Sunday, 30 September 2007 08:46:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:24 UTC