Re: Requirements Document Updated

Murray Maloney wrote:
>
> 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'?
I certainly think of parameters this way.  The one extension to this is 
that parameters
might be bound to an ancillary XML infoset--one that might be produced 
during
execution of the pipeline.  A simple example of this is an XSLT 
transformation
that takes a node-set as one of its defined 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.
I don't think anyone is thinking that we restrict steps in a pipeline 
from storing/producing
non-XML outputs.  All most are saying is that "stdout" is an XML infoset.

For example, an XSL FO processor could take an XSL FO document as input but
the output is most-likely non-XML (PDF, latex, etc.)  As such, the 
output of the
XSL FO step has to be constructed to instruct the following steps as to 
what was
done.  The possibilities for this might be:

   * a single XML element that references the document (e.g. the XHTML 
link element):

     <link rel="alternate" type="application/pdf" href="output.pdf"/>

  * a status code:

     <result status="ok"/>

  * an Atom entry describing the new resource:

   <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
      <atom:title>Output Document</atom:title>
      <atom:content type="application/pdf" src="output.pdf"/>
      ...
   </atom:entry>

  * an Atom entry containing the new resource:

   <atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
      <atom:title>Output Document</atom:title>
      <atom:content type="application/pdf">
      huge base64 string here
      </atom:content>
      ...
   </atom:entry>

So, all we are saying is that the "main" output is restricted to an XML 
infoset.

--Alex Milowski

Received on Sunday, 12 February 2006 16:33:06 UTC