See also: IRC log
No regrets given
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.
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.
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.
Alex: I can do that.
<scribe> ACTION: Alex to construct a proposal for adding a serialization feature to XProc. [recorded in http://www.w3.org/2007/04/19-xproc-minutes.html#action01]
Editorial notes from the spec:
When/how is XML well-formedness checked?
Errors in try/catch
Rui: We have to define the error vocabulary
We have to do a better job of define the vocabularies for the other components.
Can anyone think of anything else?
Alex: We need to convince ourselves that we have met all our use cases.
Norm: So let's get those things taken care of!
<scribe> ACTION: Norm to draft something for the error vocabulary. [recorded in http://www.w3.org/2007/04/19-xproc-minutes.html#action02]
Alex: The first is
... I added the $p:position variable.
Norm: Do we want this to be an XPath extension function?
Alex: I think if you look at the
specs for XPath, it allows this conceptually.
... An extension function is harder to implement.
Norm: Ok, we can try the variable.
Alex: Then there's include-last, exclude-last
Norm: Why not include-last=yes/no
Alex: The semantics are more complicated.
Some discussion of the semantics
Norm: So include-last would throw away everything except the last?
Alex: Err, this is underspecified, isn't it?
Norm: I like Mohamed's suggestion, head to return the first 'n'; tail, to return the last 'n', and a subsequence that tests..
Alex summarizes the changes: p:store, p:validate-relax-ng, p:xquery
Alex: I want to clean up the whole definition of the spec definition elements.
Norm: Yes, I'll work on that. It's a stylesheet issue.