Re: Serialization

On 7/3/07, Norman Walsh <ndw@nwalsh.com> wrote:
> The use case I think Alex wants to support, and I'm symphathetic, is
> the analog of the XSLT case where a serialized HTML document is
> produced on stdout.

What happens to the output of a pipeline? Who decides what happens
with this data? I can see 2 cases:

1) The pipeline decides
2) The caller of the pipeline decides

In #1, the pipeline uses a step at the "end" of the pipeline to
serialize the data, say to stdout, or to a file, or to an HTTP
response. In #2, the caller (another pipeline, the command line
program) does that serialization.

I am not convinced we need to make the language more complex to
support a case that would be between #1 and #2, where the pipeline
decides how the data is serialized, but leaves the caller to decide
where it is serialized.

> If you wrap that stylesheet in a pipeline, you'll get an XML document
> From the XSLT step, not an HTML one. In order to add a store step,
> you'll have to say where it should be stored.

I realize that this is something we have in XSLT. My guess is that
this was added to XSLT when it was imagined that XSLT would be used in
browsers, and the browser would directly do the transformation and
serialization to (X)HTML. So it was important to able to specify both
in the same file. I feel things have changed, and that nowadays it
makes more sense to keep transformation and serialization separate.

Coming back to the command line use case, we don't need to make the
language more complex just for this: instead of specifying how data is
to be serialized in the pipeline, this could be done on the command
line, with parameters that mimic the attributes of <xsl:output>.

Alex
-- 
Orbeon Forms - Web 2.0 Forms, open-source, for the Enterprise
http://www.orbeon.com/

Received on Friday, 6 July 2007 17:17:29 UTC