W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2007

XProc Minutes 19 Apr 2007

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:50 GMT