- From: Norman Walsh <ndw@nwalsh.com>
- Date: Fri, 22 Jun 2007 10:56:43 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <871wg4ox5g.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/06/21-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 72, 21 Jun 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Norm, Paul, Andrew, Henry, Alessandro, Richard
Regrets
Rui, Michael, Alex
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 28 June 2007
4. Review comments on 20 June 2007 editor's draft?
5. Renaming p:doc, p:document, and p:journal
6. Base URIs
7. Pipeline defaults
8. What's between here and Last Call?
9. Any other business
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/06/21-agenda
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/06/14-minutes
Accepted.
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?
Accepted.
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[7]]
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/.
Adjourned.
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[8]]
**
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/06/21-agenda.html
[3] http://www.w3.org/2007/06/21-xproc-irc
[7] http://www.w3.org/2007/06/21-xproc-minutes.html#action01
[8] http://www.w3.org/2007/06/21-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: 2007/06/22 14:49:17 $
Received on Friday, 22 June 2007 14:56:48 UTC