- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 19 Apr 2007 13:37:13 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87abx4xo3a.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/04/19-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 64, 19 Apr 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Alex, Rui, Alessandro, Richard
Regrets
Paul, Andrew, Henry, Mohamed
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 26 Apr 2007
4. Handling non-XML serializations
5. Obstacles to Last Call?
6. Review of the step library
7. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/04/19-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/03/12-minutes.html
Accepted.
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[6]]
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[7]]
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[9]
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..
Agreed.
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?
None.
Adjourned.
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[10]]
[NEW] ACTION: Norm to draft something for the error vocabulary. [recorded
in http://www.w3.org/2007/04/19-xproc-minutes.html#action02[11]]
**
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/04/19-agenda.html
[3] http://www.w3.org/2007/04/19-xproc-irc
[6] http://www.w3.org/2007/04/19-xproc-minutes.html#action01
[7] http://www.w3.org/2007/04/19-xproc-minutes.html#action02
[9] http://www.w3.org/XML/XProc/docs/langspec.html#c.subsequence
[10] http://www.w3.org/2007/04/19-xproc-minutes.html#action01
[11] http://www.w3.org/2007/04/19-xproc-minutes.html#action02
[12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[13] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[12] version 1.128 (CVS
log[13])
$Date: 2007/04/19 17:36:00 $
Received on Thursday, 19 April 2007 17:37:39 UTC