See also: IRC log
JF: I've done my action A-206-2
... See http://www.w3.org/XML/XProc/docs/xproc-zip_unzip.html
HST: No new reports on cleared actions
JF: Were you able to make any progress on splitting the use cases doct into "how we did it" vs. "what is still left"
AM: Not yet
JF: I've pulled this from a lot
of sources, including AM/MM and telcons
... We need to check the email lists as well
... Has anyone reviewed this doc't?
AM: Only just had a quick look
JF: Poll on sections in draft req'ts doc't
1) Fix Params
2) None-XML content
3) Compact syntax
HST: I don't feel we have consensus on that
JF: Yes, probably strike this, at
least for now
... Maybe we don't need this in the new spec. in any case
... Propose to drop
4) Drop XPath 1.0 support
AM: If we're using the XDM more
seriously, then XPath 2.0 comes as part of that package
... We should have some kind of forward-compatible model, so that if a new version comes out, we don't rule out support
JF: So we keep it
HST: I'm confused, I thought AM said we have to get rid of XPath 1.0
JF: Yes, but also change the title to focus on move forward to XDM
VT: I'm okay with dropping 1.0
JF: Volunteers to put a proposal in email for this one?
[silence gives consent]
5) Expand allowed content of variables
JF: I think I know where this is going
VT: This could have some consequences for streaming? We will need to think about this a bit
JF: I borrowed the Design Principles section, which mentions parallel/streaming, but I don't see any proposals
AM: This doc't will need to refer
to 1.0, and to the Solutions doc't
... and admit where we drop/give up
JF: Is there precedent for saying in a spec. that we didn't satisfy a req.
HST: Dan Connolly would recommend revising a req. doc if the spec. itself doesn't cover parts of it
AM: A lot of what we need is in
... Back to content of vars -- are we including parameters here?
... We will have to come back to the rel'n between 4.1 and 4.5
... There are some use cases that will drive this exploration
JF: This raises the question of our commitment to backwards compatibility
AM: I think we've agreed that
fixing parameters will break parameters
... We should do it as compatibly as possible, but not at the expense of a clean solution
JF: It does look like the old syntax won't work as such -- change from port to, perhaps, option
AM: Maybe a new Design Principle -- we will allow some 1.0 pipelines to fail as 2.0 pipelines
MM: returning to streamability --
I tripped on this when I was working on the Solutions doc
... Maybe that should be a Design Principle -- that we commit to avoiding things which force blocking
JT: We have some cases (from MZ?) which already make streaming difficult or impossible
MM: Right, that's why change it from Requirement to Design Principle
JF: Indeed, that's how I have it
in my new doc
... I'd like at least some use cases, even if we don't have anything more concrete
AM: There are some examples in 1.0, but yes, we can do better on that this time
<scribe> ACTION: MZ to give us some concrete use cases which stress streamability [recorded in http://www.w3.org/2012/10/11-xproc-minutes.html#action01]
6) Fix non-step wrappers
VT: I have always treated [them] as steps
AM: Do we have a preferred outcome?
HST: They weren't originally steps because they have steps inside them
VT: When I implemented, I saw two
interpretations -- that they barely exist, they are just a kind
of typed sub-pipeline, OR that they are a compound step with
their own semantics
... I feel as if we shifted from one view to the other as we went along, without ever really cleaning it up
AM: Can you fix it?
VT: I've looked at this, and it's not easy whichever way we go
JF: What does this give us?
AM: It would give us the ability to have a syntax which maps to a semantics, w/o having to have semantics which essentially just attaches to a content model ('subpipeline')
VT: I agree -- note that p:group is currently schizophrenic -- it's a compound step, except inside p:try, where it's a non-step wrapper
7) Step categories
AM: There is a real issue here -- we need to decide how to manage the step life-cycle
JF: I agree, just not sure how it can be normative
AM: Does this have to be framed in the req doc as a requirement
HST: No, we can do whatever we like
AM: We should put a meta-requirement that we write 2.0 so that changes to steps don't require a new language document
HST: We need a step
... Seriously, at the recent TAG meeting it was suggested that many/most W3C specs are at least primarily registries
... Maybe we would benefit by foregrounding that perspective a bit more
AM: I like that
JF: Would would that mean concretely for the req doc?
AM: Two new requirements: we need
a strategy for reving steps w/o reving the language; maybe some
kind of step registry should be considered
... That might mean 4.7 gets addressed in some other document
JF: Do we need some discussion before we make this more specific?
AM: Yes, I think email discussion is needed
JF: OK, I'll try to kick that off
HST: What about our short list from the beginning of the autumn?
JF: Yes, they're all there
AM: Really an action to the group
to go back and confirm that nothing they care about has been
... That list was re-minuted a few weeks ago. . .
JF: Yes, I tried to be careful on that subject
JF: That was back in January, it sparked a lot of replies
HST: What have we done to make XProc easier to use, to adopt, to get into?
AM: So what we need in our use
cases are pointing to cases where things are hard/should be
... Getting rid of params is an obvious win there
... What other _specific_ pain examples can we point to?
... Placeholder in the use cases section: Usability
JF: So that's an action to everyone to dig out their (un)favourite examples of annoying pipelines