See also: IRC log
-> http://www.w3.org/XML/XProc/2007/06/21-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2007/06/14-minutes
Accepted.
No regrets given for 28 June
-> 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.
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?
Accepted.
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.
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]
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
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/.
Adjourned.