Accept minutes from the previous meeting?

Next meeting: telcon 26 Apr 2007

Handling non-XML serializations

Norm: I think this has two parts:
final result from the pipeline, but we also have the question
of what, for example, an XSLT component should do if its output
is text.

Alex: I have a simple requirement
to have a declaration in the pipeline document of how the
author would like the results to be serialized.
... I don't know where we should put that, in the syntax, but
that's what I need.
... This is like the XSLT transform situation which has an
xsl:output declaration.
... I want to replace an XSLT transformation with a pipeline
and I want to make sure that the output is serialized the same
way.

Norm: So you don't want to be
able to track what the XSLT said.

Alex: I think we have a story
there. To be consistent, the shortest answer is that we say
that XML documents come out on the output port.

Norm: the outputs of an XSLT
processor aren't serizlied.

Richard: Not in your
implementation. I think we should be agnostic about this.
... The output you get is the output you get.

Alex: But implementations can do
the right thing if they know what the output should be.
... I'd like to be able to allow an author to express the
serialization of a pipeline result.
... We could declare that out-of-scope and be done.

Richard: I don't mind the pipeine
saying somewhere that it's output is HTML, but I hope you're
not suggesting that the pipeline should be required to produce
HTML if the last step doesn't produce HTML.

Alex: No, it's just a declaration
of intent.

Richard: If I write a pipeline
and say the output is HTML and the last thing is an XSLT
step,then you have to say it's HTML there too.

Alex: We have to clarify
that.

Norm: I think they're
independent.

Richard: I had thought that if
the last step happened to not produce XML output then as a
special case that's ok.

Norm: That's not what I
thought.

Richard: The pipeline has to know
every kind of output.

Alex: No it doesn't, it's either
XML or it isn't.

Richard: Suppose I write an addon
component that produces foo output.

Norm: It crashes and burns.

Alex: The constraint on output
ports says you have to produce (a sequence of) XML
documents.

Richard: So who does produce
HTML?

Alex: The way it works in JAXP
depends on how you invoke the transform.

<rlopes> Zakim: [ is me

Norm: I thought you'd either
serialize with a component or the serialization would be an
implementation-dependent feature.

Alex: What about a separate
document that specifies the pairings.

Richard: I expect people to run
things from the command line, I'd expect to have command line
arguments that specified those things.
... It sounds like what Alex is asking for is the equivalent of
standardizing the command line arguments.
... I think that's something we should leave to the
implementations.

Norm: XSLT serializes, we
don't.

Alex: I think the XSLT spec says,
"if you serialize..."

Richard: You're drawing the
parallel with XSLT so the place to put the hint would be in the
pipeline document.

Alex: I'd prefer that it be in
the pipeline document.

Richard: This is something the
pipeline author chooses.

Alex: Right

Norm: So we're thinking of
putting this the whole xsl:output thing in XProc
... And what about character maps, how far are we going to
go?

Alex: I think we'd want to
support all the serialization features of XSLT 2.0/XQuery 1.0
serialization.

Richard: I don't want to
implement all of that stuff.

Alex: But it's a slippery slope.
Once you start writing stuff to disk you wind up here.

Richard: Not if we don't support
XSLT 2.0 serialization
... XSLT 1.0 was quite useful without having any of that stuff
in it.

Norm: Maybe p:store should be
optional.

Alessandro: Can we have two store
components, one the XSLT 1.0 way, one the XSLT 2.0 way.

Alex: I think we should treat
serialization as a feature.

Richard: I think that if we allow
all these complicated serializations then we don't want to
reinvent the wheel. But I also think this should be no-more
required than XSLT 2.0.

Norm: Maybe we need p:store to
store XML and an optional p:serialize to do all sorts of XSLT
2.0-style goo.

Richard: It can be one component
with a parameter.
... that you're only required to support certain values of.

Alex: I like the idea of having a
serialization feature like XSLT 2.

Norm: I think that's a V2
feature.

Alex: We have use cases that
require producing HTML.

Norm: Can we get away with a
serialization feature like XSLT *1.0*

Alex: The feature I added to
p:store was just to say "method".

Norm: I wonder if Alex you'd be
willing to write this up as a more concrete proposal and send
it out in mail.