- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 13 Dec 2007 12:01:40 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2ve72lea3.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/12/13-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 94, 13 Dec 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Alex, Norm, Mohamed, Andrew, Henry, Alessandro, Richard
Regrets
Paul
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 20 December 2007
4. Last call comments
5. Comment #81, a proposal to restructure our top-level syntax
6. Comment 79: sequence-consistency of choose/try branches
7. Comment 80, properties of an implicit output port
8. Comment 83, viewport
9. Comment 74, minor p:http-request issues
10. Comment 76, p:import dynamic errors: should be static
11. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/12/13-agenda
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/11/29-minutes
Accepted.
Next meeting: telcon 20 December 2007
No regrets given.
Last call comments
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments
Comment #81, a proposal to restructure our top-level syntax
Henry: I think the motivation is the crucial thing.
... It felt like we still hadn't found the sweet-spot in the relationship
between pipelines, steps, and pipeline-libraries
... The crucial observation was that it suddenly made sense to allow
declare-step to contain a subpipeline
... That's precisely what we're doing when we put <px:somename> in a
pipeline as a call to the pipeline with the type px:somename
... It made sense to use *declare-step* to do that.
... When I worked that all through, it seemed to me to have a number of
positive consequences.
... The single residual notion as the sort-of entry level way of wrapping
a subpipeline to run it, it didn't have to have a name.
... Giving it a name is only necessary if you want to be able to refer to
its ports.
... There are two seperable parts: 1. Put a subpipeline in declare-step
and 2. let's make reference to the enclosing top-level artifact easy by
defaulting on p:pipe.
... I think that works very neatly, but its seperable from the other
proposal.
Norm: My big concern was the fact the you couldn't import two simple
pipelines anymore, because there'd be a name clash.
Henry: We could (1) add an optional name to p:pipeline, but that still
doesn't help if you don't own the pipeline.
... Or (2) alow a type attribute on p:import that is the type of a naked
imported pipeline.
... or an error if the imported library doesn't include it.
Norm: If we went with type, I think I'd want it to be an error if you
don't import a naked pipeline.
Henry: Or you can workaround it with a really tedious set of nested
libraries.
Some discussion
Norm: The other concern I have is much harder to quantify: are we making
the language more like a static compile/run language and less dynamic and
is it going to piss off our audience.
Richard: there isn't a pipeline and a declare-step for the pipeline, it's
one or the other.
Henry observes that the type/p:import trick would bungle an attempt to
import a recursive pipeline.
Alex: I don't see why requiring the p:declare-step in the recursive case
is such a big deal.
Norm: I'm not *sure* it is, it just changes the way the language feels.
Richard: I thought we were going to get rid of p:pipeline altogether, just
putting them all in p:declare-steps.
... Then we put pipeline back in as an abbreviation for a common case of a
declare-stpe with a subpipeline in it.
... We can then fiddle with what the abbreviation means to make the common
cases we care about easy.
... If you do it in those two stages, it seems more plausible to me.
Norm: There's no point in repeating myself: there's a sense in which this
makes the language feel more like java and less like a scrypting language
and that worries me.
Henry: A question of how much a discontinuity arises when you want to
write a recursive pipeline is an open question.
Alex: What if a pipeline is allowed to have a type declared. And you have
to do that to use recursion.
Richard: If we made pipeline just be an abbreviation in that way, the only
thing we've really changed is that you write pipelines with p:declare-step
when you put them in libraries.
Henry: I get confused about what the state of play is wrt what attributes
are allowed on p:pipeline at the moment.
Alex: It also fixes the defaulting problem for inputs and outputs of
pipelines.
Henry: The other consequence is that we could get rid of the situation
where p:pipeline has both an optional name and an optional type.
... Our users are never going to be anything other than confused by that.
Norm: The way that was rectified was by allowing p:pipe to have no step
and that means the enclosing pipeline.
Some discussion of the proposal that Norm had made earlier
Alex: I'd have to think about the defaulting story a bit more.
Richard: The thing that Henry's proposing isn't really defaulting, it's
like giving the name of the pipeline the name "" and just letting you not
say that.
Alessandro: I think it would help if someone could consolidate the
proposal and post it with some examples. My reluctance now is coming more
from lack of understanding that something being wrong with it.
Henry: I'll do that over the next 24 hours.
Comment 79: sequence-consistency of choose/try branches
Norm: I think so.
Richard: The reason why it came up was that one branch had an XSLT and the
other had Identity, so that doesn't work.
Norm: Yes, I see how that might be tedious.
Richard: Because you're allowed to hook sequences to non-sequences, it
doesn't really matter to the implementor.
... We could say that if any branch produces a sequence, then the p:choose
does.
Norm: I can live with that.
Proposal: We accept Richard's suggestion above, an output of a choose or
try is a sequence if any of the branches produces a sequence on that port.
Accepted.
Comment 80, properties of an implicit output port
Richard: I think Norm's right, it inherits the properties of the output on
the last step.
Accepted.
Richard: The only effect that declaring something sequence=false has is
that it prevents a sequence from slipping through.
Comment 83, viewport
Richard: We really did mean that the pipeline can inside the viewport can
only have one output.
Norm: Yes, we meant that.
This is a significant editorial issue, but not a technical one.
The subpipeline must have one output and the result can be a sequence.
Richard: I think there may be similar editorial problems with p:for-each
Comment 74, minor p:http-request issues
The version was absent by mistake and yes, the XML decl should be present
Comment 76, p:import dynamic errors: should be static
Norm: Yes, they should be static.
Accepted.
Any other business?
None.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/12/13-agenda
[3] http://www.w3.org/2007/12/13-xproc-irc
[7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[8] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[7] version 1.128 (CVS
log[8])
$Date: 2007/12/13 17:00:48 $
Received on Thursday, 13 December 2007 17:01:53 UTC