- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 03 Jan 2008 12:07:35 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2k5mqu9bc.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/01/03-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
3 Jan 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Michael, Henry, Richard, Alex, Mohamed, Rui, Andrew
Regrets
Alessandro, Paul, Murray
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 10 January 2008?
4. Last call comments
5. 81. A proposal to restructure our top-level syntax
6. 89. Questions and comments
7. Future plans
8. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2008/01/03-agenda
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/12/20-minutes
Accepted.
Next meeting: telcon 10 January 2008?
No regrets given.
Last call comments
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html
81. A proposal to restructure our top-level syntax
Norm wonders if Alex has any thoughts.
Alex: I generally like it.
Alex wonders if there are any controversial parts in the minds of others
Silence
Norm: Is there anyone on the call that thinks we shouldn't do this?
Michael: The fundamental idea seems good. Some of the special cases for
defaulting are problematic.
Alex: When you have a p:pipeline, any inputs and outputs are additive, is
that right?
Richard: Yes, as I framed it, p:pipeline is just syntactic sugar for a
declaration with a p:input and a p:output.
... The advantage it gives is that there's a fully explicit syntax for
things.
... If you want an abbreviated syntax, then p:pipeline is it, and the
abbreviation seems to me to be very straightforward.
Alex: Can you point to a p:pipeline to import it.
Richard: I don't see why not.
In fact, you can point to all three, a p:pipeline, a p:declare-step, or a
p:library.
Some discussion of the fact that this means you can point to a
declare-step implemented by other means as well.
Let's consider the options in Richard's proposal:
1. How to refer to pipeline input ports within a subpipeline.
Norm: I have a preference for using the local name of the type.
Richard: That has an impact on option 3, since it will make some inputs
totally unavaiable.
Alex: Why not make the type required.
Henry: You could do that, you could take 1 and 3 as a package solution.
Henry expresses a preference for requiring the type if we don't go with
the absent step attribute shortcut.
Henry: The advantage of requiring all pipelines to be typed is that it
means you can always import them.
Richard: And conversely, having untyped pipelines allows authors to
prevent them from being reused without copying.
Mohamed: I prefer to use the local name as well. Omitting the name is just
too complicated to understand.
So, for option 1, we'll use the local name of the step type.
2. Should the defaulted input and output on p:pipeline have referenceable
names.
Richard: I think that if they don't have referencable names, how can you
call the pipeline? That's compelling to me.
Norm: I feel a little odd because we've made the other choice elsewhere.
Richard: Yes, but no where else is it exposed externally.
Anyone disagree?
Mohamed points out that you could still call them, as long as the call
used the primary input port.
Richard: I think the point of the simplification is that it simplifies
things for the author, it shouldn't constrain the user.
Ok, for 2, we'll use the names "source" and "result"
3. The type attribute is optional on p:pipeline.
Norm: I think at the moment I favor making it optional, the point of the
default syntax is to make things simple and requiring a type you never use
doesn't seem simple.
Henry: I think we should try that and see if we get pushback.
So, for 3, we leave it optional.
Norm summarizes the consequences of the choices.
Richard: I left the 'primary' off of my equivalence summary in email.
Mohamed: I'm wondering about the mandatory nature of input and output in
the p:pipeline case.
Norm: I think pipelines that have no input or no output are going to be
much less common.
<richard> It's not "do something extra if you want to reuse", it's "don't
use this abbrevation if you want to reuse"
<scribe> ACTION: Norm to craft an editor's draft implementing these
decisions [recorded in
http://www.w3.org/2008/01/03-xproc-minutes.html#action01[7]]
89. Questions and comments
Norm: On closer inspection, I decided that these were editorial or
clarifications.
Future plans
Norm: Seems like we're done.
Henry: Time for a last call.
Richard: Do we want to introduce this renaming in a last call.
Norm muses about that.
Norm: I guess it's time to get an editor's draft out that includes all of
the decisions we've made.
... Anyone know of anything else that's outstanding?
Mohamed: At some point we talked about splitting the spec.
Richard: Having the step library separate, you mean?
Mohamed: yes.
Norm: I'll put that on the agenda for next week.
Any other business?
None.
Adjourned.
Summary of Action Items
[NEW] ACTION: Norm to craft an editor's draft implementing these decisions
[recorded in http://www.w3.org/2008/01/03-xproc-minutes.html#action01[8]]
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2008/01/03-agenda
[3] http://www.w3.org/2008/01/03-xproc-irc
[7] http://www.w3.org/2008/01/03-xproc-minutes.html#action01
[8] http://www.w3.org/2008/01/03-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/03 16:58:54 $
Received on Thursday, 3 January 2008 17:04:01 UTC