XML Processing Model WG

3 Jan 2008


See also: IRC log


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



Date: 3 January 2008

<scribe> Meeting: 96

<scribe> Scribe: Norm

<scribe> ScribeNick: Norm

Accept this agenda?

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


Accept minutes from the previous meeting?

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


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


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.

<MoZ> ##local

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]

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?



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]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2008/01/03 16:58:54 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.128  of Date: 2007/02/23 21:38:13  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/forwarde/forward/
Succeeded: s/the name/the type/
Succeeded: s/reused/reused without copying/
Succeeded: s/yes/Yes/
Succeeded: s/the the/the/
Succeeded: s/90/89/
Found Scribe: Norm
Inferring ScribeNick: Norm
Found ScribeNick: Norm
Default Present: Norm, Ht, MSM, +1.415.404.aaaa, richard, alexmilowski, MoZ, ruilopes, Andrew
Present: Norm Michael Henry Richard Alex Mohamed Rui Andrew
Regrets: Alessandro Paul Murray
Agenda: http://www.w3.org/XML/XProc/2008/01/03-agenda
Found Date: 3 Jan 2008
Guessing minutes URL: http://www.w3.org/2008/01/03-xproc-minutes.html
People with action items: norm

[End of scribe.perl diagnostic output]