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

XProc Minutes 10 Jan 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 10 Jan 2008 14:31:24 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ve615vg3.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/01/10-minutes

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 97, 10 Jan 2008

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Norm, Henry, Paul, Alessandro, Alex, Richard, Andrew

   Regrets
           Murray

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 17 January 2008?
         4. Face-to-face meeting in 2008?
         5. Last call comments
         6. Split the spec into two or three parts?
         7. Replace ignored namespaces with p:appinfo (or some such)
         8. Allow sequences on source and result of p:pipeline
         9. Any other business?
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/01/10-agenda

   Accepted

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/01/03-minutes

   Accepted

  Next meeting: telcon 17 January 2008?

   No regrets given.

  Face-to-face meeting in 2008?

   Norm: Anyone think we want to try to do that before the Tech Plenary? (Oct
   in Mandelieu, probably.)

   Henry: I can imagine that we are sufficiently finished with XProc in a few
   months that it will be time to turn our attention to our other task.
   ... Sitting around a table would be the best way to start.

   Norm wonders about Balisage...

   Norm: Let's wait and see

  Last call comments

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html

   Comment 21: XProc localization

   Norm outlines his message about making p:error take its description from
   an input port

   Henry: This resonates with something I encountered when trying to simplify
   the early example pipelines.
   ... Sometimes you'd like an alternative between an input port and an
   option.
   ... For example, I'd like to be able to specify the XSLT stylesheet by way
   of an option instead of on an input port.
   ... It's just laziness, but the idea of having an option and a port in a
   trading relationship seems very natural
   ... The alternative is that folks won't provide descriptions for errors.
   ... Do we want to consider adding this feature?

   Richard: Can't you do it with a select and an expression?

   Norm: No, because it gets turned into a string and the markup is thrown
   away.
   ... I guess my reaction is, gosh that's a nice feature but aren't we done
   adding features?

   Henry: It's not a feature it's a design pattern.

   Richard: It seems to me that it's a bit excessive for what it does.

   Support does not seem to be rising for the coocurrence constraint idea.

   Norm: Do we want to make the description of p:error an input port?
   ... I observe that it does require the user to make up some random
   document element for the message.

   Richard: What about structured content?

   Norm: No, way too much feature for now. We could remove the restrction to
   strings, but that didn't get support alst time it came up.
   ... Straw poll: Input or option?

   Input wins with unanimity.

   <scribe> ACTION: Norm to change the spec to make error descriptions come
   from an input port on p:error [recorded in
   http://www.w3.org/2008/01/10-xproc-minutes.html#action01[7]]

  Split the spec into two or three parts?

   Some discussion of why we might do this

   Richard: I'm inclined to keep them together.
   ... I think it's simpler for readers to ahve it all in one document.

   Paul: The biggest advantage as far as I'm concerned is that you could
   advance different parts to PER, for example, independently.
   ... For example, you can tell folks we haven't fiddled the language, we've
   just changed the steps.

   Henry made apoint earlier about the fact that breaking it into pieces
   doesn't necessarily make it into separate RECs

   Paul: I don't think it makes sense to do unless we make different RECs.

   Norm: The editor doesn't feel strongly one way or the other, for what it's
   worth.

   Henry: I think Paul's argument has value, but I don't feel that strongly
   either.

   Some discussion of adding steps in the future

   Henry: At worst, we can always change our minds later.
   ... At V1.1 time, for example.

   The chair doesn't hear consensus for splitting the document at this time.

  Replace ignored namespaces with p:appinfo (or some such)

   Norm summarizes how we got where we are

   Richard: One advantage to inventing your own namespace is that it
   designates the owner of the info.

   Norm: We could mandate, suggest, or leave that problem to implementors

   Alex: Why?

   Henry: Because it's just not clear and is contradictory in the spec.
   ... The core of my problem is that we invite people to put an element
   between two steps but we say it musn't change the flow. That's just
   bizarre.

   Some discussion of the extent to which deleting them is appropriate.

   Norm: I guess the position I've come to is that ignored namespaces
   introduce some complexity without much benefit over having a single
   element for this purpose.

   Alex: What about making them top-level?

   Henry: Yes, excpet that the spec tries to do that and it gets confusing.
   ... Instead of putting it in subpipline, couldn't we put it in the prolog?

   Richard: Does having a p:appinfo solve the placement problem?

   Some discussion, basically yes.

   Alex: I'm partial to the ignored namespace thing, but I don't mind having
   an appinfo, as long as we don't call it "appinfo".

   Straw poll: keep ignored namespaces,or abandon them in favor of some
   element to be named later.

   Results: 6 for new element, 1 for ignored namespaces, and 1 abstention.

   Name the new element...

   pipedata

   userdata

   <MoZ> pipeinfo

   pragma

   Results: pipedata: 3, userdata: 2, pipeinfo: 4, pragma: 3

   The winner is p:pipeinfo.

  Allow sequences on source and result of p:pipeline

   Norm: I'm inclined to say not.

   Alex: I'm inclined to allow them so that you don't have to jump into a new
   syntax just to provide two input documents.

   Richard: Because this is the simple case, I was expecting it to be used on
   the command line and that's possibly going to make the output syntax
   different.

   <MoZ> +1 with Richard on output

   Richard: I was planning to implement sequences as directories, that means
   I'll always get a directory even when there's only a single file.
   ... I can work around it, but it seems a bit yucky.

   Some discussion of the various possibilities

   Alex: If I put an XSLT inside a pipeline, I shouldn't have to fiddle the
   syntax depending on whether or not a sequence is produced.

   Straw poll: sequence or no sequence?

   <ht> I note that saxon 8 just concatenates multiple unnamed
   result-documents on stdout

   Results: sequence: 2, no sequence: 4, abstain: 2

   Henry: What about sequence on input, no sequence on output?

   Alex: I'm not going to lie down in the road over sequences.

   Alessandro: I think we shouldn't let constraints on the command line
   system influence how we design our language.

   Richard: I'd agree, except that we're only discussing the abbreviated
   form. And that does seem to me to have a more direct connection to
   useability on the command line.
   ... It's there for simple cases.

   Norm: Is there anyone who can't live with no sequences on input or output

   None heard.

  Any other business?

   None.

   Henry: I'd like to encourage the wG to identify any issues between here
   and last call.

   Some discussion of circular imports in pending mail.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: Norm to change the spec to make error descriptions come from
   an input port on p:error [recorded in
   http://www.w3.org/2008/01/10-xproc-minutes.html#action01[8]]
    
   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/01/10-agenda
   [3] http://www.w3.org/2008/01/10-xproc-irc
   [7] http://www.w3.org/2008/01/10-xproc-minutes.html#action01
   [8] http://www.w3.org/2008/01/10-xproc-minutes.html#action01
   [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [10] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[9] version 1.128 (CVS
    log[10])
    $Date: 2008/01/10 19:30:14 $

Received on Thursday, 10 January 2008 19:31:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 January 2008 19:31:41 GMT