XML Processing Model WG

Meeting 64, 19 Apr 2007


See also: IRC log


Norm, Alex, Rui, Alessandro, Richard
Paul, Andrew, Henry, Mohamed


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/04/19-agenda.html


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/04/12-minutes.html


Next meeting: telcon 26 Apr 2007

No regrets given

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.

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.

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]

Obstacles to Last Call?

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]

Review of the step library

-> http://www.w3.org/XML/XProc/docs/langspec.html

Alex: The first is subsequence.
... I added the $p:position variable.

<alexmilowski> http://www.w3.org/XML/XProc/docs/langspec.html#c.subsequence

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.

Any other business?



Summary of Action Items

[NEW] 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]
[NEW] ACTION: Norm to draft something for the error vocabulary. [recorded in http://www.w3.org/2007/04/19-xproc-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/06/12 18:12:10 $