Re: Requirements Document Updated

At 06:05 PM 2/10/2006 +0100, Erik Bruchez wrote:


>I am not 100% we have built a strong case for parameters. [...]
>My fear is that now, will will have two concepts: "input" and 
>"parameters". They won't work the same, and the question of how or whether 
>a step can produce data which gets connected to a "parameter" remains open.

I am confused.

If I understand the terminology that everybody is using, when we talk about
an 'input' it is as though we were talking about stdin, except that we may 
also be
talking about inputs that are specified through command-line options, and even
inputs that are consumed in the course of processing, such as a style sheet 
that
may specified within a document or from a user's environment.

And when we talk about 'outputs' we are talking principally about stdout, 
but possibly
also artifacts of processing which can be considered as outputs for the 
purpose of
discussion, but are not outputs in the sense that they cannot be 'piped' or 
re-directed.

That leaves us with parameters, which I think of as options on a command line
or even environment variables and registry entries. Does anybody attach a
different meaning to 'parameters'?

These are all familiar paradigms. Surely there is no problem allowing for 
any and
all of these paradigms, from a user's or an implementor's perspective. Am I
missing something?

What I don't understand is how we can limit 'inputs' or 'outputs' to XML 
info-sets.
Perhaps we only mean that the XML Processing Specification will provide
for steps which operate on a putative XML Info-set. Or perhaps we mean that
'components' must accept/emit reifications of an XML Info-Set at stdin/stdout.
Hopefully we don't mean to prevent a component from emitting non-XML outputs,
even to stdout, because that would forbid components from rendering XML
into publishable formats such as PostScript et al. Hopefull we also don't mean
to prevent a component from accepting non-XML inputs, even stdin, because
that would forbid component that read a CSV file and emit an XML rendition
of that data as, for example, a table or an address book.

If we are saying that the XML Proc will provide mechanisms which allow one
to write specifications that operate on an XML Info-Set, then I think that
we may have a winner. In that case, my stdin/stdout streams can be anything.
Assuming that my component is capable of taking a CSV file as input, exposes
an XML Info-Set interface, and produces PostScript as output, then why should
anyone care? Perhaps a component should be required to publish its interfaces
so that anyone attempting to use the component will know which interfaces
are available.

Does any of this make sense, or am I more confused than even I thought?

Regards,

Murray