XML Processing Model WG

Meeting 72, 21 Jun 2007


See also: IRC log


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


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/06/21-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/06/14-minutes


Next meeting: telcon 28 June 2007

No regrets given for 28 June

Review comments on 20 June 2007 editor's draft?

-> http://www.w3.org/XML/XProc/docs/langspec.html

Henry commented on some content models and on App D being broken.

Norm reports that those things are fixed.

Mohamed made some comments in email; Norm will address these.

Renaming p:doc, p:document, and p:journal

Norm describes the background following Jeni's mail

Henry: I'm happy to change p:journal to p:log
... And I agree we should change p:doc to p:documentation.
... I don't feel strongly about p:document, I'm happy to leave it.
... I don't think there's any real stress between document and documentation.

Norm: I dislike the alternatives that have been proposed and I don't find document/documentation confusing.
... Anyone want to pursue p:document renaming?

No one speaks up.

Proposed: Rename p:doc to p:documentation and p:journal to p:log. Leave p:document unchanged.

Any objections?


Base URIs

Norm outlines his concerns.

But not very well articulated.

We should probably say what happens to the base URI as a document passes through each step.

Norm: I guess the clearest thing I can say is that we have no way of accessing the base URI from XPath.
... So you can't make a p:choose that branches on the base URI, you can't pass it as an option or parameter.

Let's move this to email.

Pipeline defaults

Norm points out that parameter defaults are a little tricky.

Henry: On the question of pipeline parameters, I sort of convinced myself that it was going to come out ok.
... That is, the fact that we can put parameter port declarations on p:pipeline means that you can connect to them.
... There is some way, maybe the only way, of declaring an input port in p:pipeline as a parameter port. Reading from this gets you whatever was passed in from the outside.

Norm: The question is, if you don't have a parameter input port on a p:pipeline, what happens to parameters?

Henry: I want a pipeline with one input and one output not to have to have any declarations.

Norm: That's not on the table!

Henry: Yes it is. I wrote email about it...I can find that mail

Norm: So if a pipeline has no inputs and no outputs, you want it to have a default input of source and a default output of result?

Henry: I don't care about the name, I just want the default input port to be available.

<ht> My goal all along has been to make it so that <p:pipeline><p:identity/></p:pipeline> works

Alessandro: With a system like this, how do we declare that a pipeline has no inputs or outputs?

Henry proposes p:empty, but we agree quickly that this doesn't work.

Henry/Richard recall that we had previously discussed making nothing mean one input

Henry: No inputs or outputs is a small percentage case, so maybe we can have attributes on p:pipeline that identify the number of inputs and outputs.

Norm: Yes, that would work. It's not pretty to me...

Norm agrees that it's syntactically simpler but worries that it's conceptually confusing.

Henry: Maybe we push it too far, but think of the stdin/stdout analogy: you don't have to declare those.

<ht> The input to the first step is, other things being equal, the in put to the pipeline

Norm: I could live with it, but it's not immediately comfortable.

Alessandro: In my mind, pipelines are more similar to the way you would use functions in other programming languages. In those languages, default declarations are uncommon.
... And in my experience, having 1 input and 1 output is not the overwhelmingly common case.
... Having that be the default doesn't resonate with me.

<Zakim> ht, you wanted to note the exception to Perl

Henry: I wanted to observe that Alessandro is right in general, but Perl is a counter example.
... In Perl the default input and default output are always there by default, $_

<ht> That is $_

Henry: I can live without this, but it seems the logical conclusion of the rest of our defaulting story.

Richard: One can imagine the input case working as a kind of error recovery. If a pipeline with no inputs finds its first step relies on the default input, it could infer one. But that doesn't work for outputs.

<scribe> ACTION: Henry to get this discussion started in email [recorded in http://www.w3.org/2007/06/21-xproc-minutes.html#action01]

What's between here and Last Call?

Norm: I want everyone to think about what stands between us and last call.

Henry: Is the error story complete?

Norm: I think it's complete, but I wouldn't swear to it.

Henry: Can we say nothing about implementations and APIs?

Norm: Good point.

Henry: The fact that every implementor will have to answer certain questions doesn't obligate us to answer them.

Norm: I'm not sure I follow.

Henry: There's been an assumption that whatever the API is, it's going to get at most one document at a time. But it's also got to know when it's gotten the last one.

Norm: I don't think we could answer that in any sort o fimplementation independent matter.

Henry: Do we need or want to make the point that implementations have to buffer whole sequences at places.

Norm: Not normatively, in my mind, but informally I think we should mention it.

Try/Catch, some uses of last(), and possibly p:count

Any other business

Mohamed: What about the step vocabulary, will that be updated for the next draft?
... Some name changes.

Norm: Let's check with Alex and see what the status is/.


Summary of Action Items

[NEW] ACTION: Henry to get this discussion started in email [recorded in http://www.w3.org/2007/06/21-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/06/22 14:49:17 $