Action items

JF: I've done my action A-206-2 wrt zip/unzip
... See http://www.w3.org/XML/XProc/docs/xproc-zip_unzip.html

<jfuller_> http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0018.html

<jfuller_> http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0018.html

<jfuller_> http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0018.html

<jfuller_> http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0018.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

<jfuller_> http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml

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

[none opposed]

2) None-XML content

[none opposed]

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

[none opposed]

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

HST: Vojtech?

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 MM's doc
... 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

<jfuller_> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2012Oct/0012.html

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

<jfuller_> http://www.w3.org/XML/XProc/docs/requirements-v2-jim.xml

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 registry!
... 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 missed
... That list was re-minuted a few weeks ago. . .

JF: Yes, I tried to be careful on that subject

<jfuller_> http://lists.w3.org/Archives/Public/xproc-dev/2012Jan/0011.html

Pain points

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 easier
... 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

Adjourned