Re: An unfulfilled requirement maybe?

>
> If $source-is-xml is true, then the serialization options are used to
> convert each of the inputs into serialized XML and they're written to
> the commands stdin.
>
> If $source-is-xml is false, the XPath 1.0 string-value of the document
> node of each of the inputs is written to stdin.
>
Great! Looks like a fine solution.

> I wonder
> if we need to worry about setting environment variables.
I think this should be left implementation... defined. I can imagine
an implementation saying "unless adjusted by setting X,
*implementation* runs the command line as user Y" which would
essentially mean it inherits all environment variables available to
that user. Speaking of user rights, this should be implementation
defined (and thus possibly adjustable by a setting) as well I believe.


>
> I think that covers it. Argument processing sort of sucks.
Amen to that. It looks like the most complicated piece of this step. I
mean, Windows for example doesn't use single quotes as an argument
concatenator the same way it uses double quotes. And a backslash is
only used to escape double quotes - nothing more and nothing less. So
this will certainly create a burden for implementations. But it's also
wrong from a pipeline author's point of view.

For example (just to show CLI's behavior), the command
md "te st\'"
under Windows (XPSP2) produces a folder called [te st] and IN IT,
another folder called just ['] (a single quote). If this escaping
should be done as described, this should return a single folder called
[te st'] which is in contrast to what a user would expect.

Also, if a pipeline author was to migrate from one OS to another,
(s)he should always be ready to face changes in the pipeline,
especially when dealing with things as the CLI.

And in the event the author needs to have a portable pipeline (eg. if
it is distributed for others to use, the same way XSLT stylesheets are
sometimes published for massive use), they can always perform a test
to see the OS the pipeline is running on. How exactly is test going to
be done? Either imlementations *should* add the OS to their
p:product-version system property, or a new system property should be
added for that, or a pipeline could perform a command that is known to
be available only on a certain OS and act accordingly, etc. etc.

In summary: the more the CLI's behaviour is left implementation (and
thus OS) dependant, the better and easier it will be for both
implementations and pipeline authors.

>
> Executes $command with $args, feeding "source" to stdin and reading
> "result" from stdout and "errors" from stderr.
>
Again, especially with the above note(s) in mind, why not combine
$command and $args into a single $command option which will include
the command and it's arguments?

>Any "/" or "\" in the $command are transformed into the
>platform-specific path separator character.
OK. I see this as one reason. The path in general I mean. But in this
case, I think that the value of this option (and the $cwd for that
matter) should be an URI rather a file path. It should ease both
implementation requirements and pipeline author's expectations. Either
that, or it should be left implementation dependant, in which case
it's better to combine it with $args.

Btw, what happened to the wrap-*-lines options? Processing the
returned text line by line is (almost?) impossible with XSLT 1.0 and
hard (though easier) with XSLT 2.0. XProc itself also doesn't provide
any way to process text contents or at least split the text into lines
as would have happened with wrap-*-lines = false, so theese options
would be handy in many occasions.

If those options are to be dropped (for whatever reason), putting
<c:line/> elements should probably be the default behaviour, as the
<c:line/> to plain text convertion is easily doable with XSLT (1.0).
The other way around is what's hard.

Received on Friday, 5 October 2007 20:19:39 UTC