- From: Vasil Rangelov <boen.robot@gmail.com>
- Date: Sun, 30 Sep 2007 11:45:43 +0300
- To: <public-xml-processing-model-comments@w3.org>
>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><root/></c:line> <c:line><root/></c:line> </c:result> And with wrap-stdout-lines = true, you get <c:result><root/> <root/></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