Accept this agenda?

-> http://www.w3.org/XML/XProc/2012/01/19-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2012/01/05-minutes.html

Accepted.

Next meeting: telcon, 26 January 2012.

Jim gives regrets.

Processor profiles document

Norm: My apologies for not getting it published.
... Paul gave some comments, I think they're all addressed.

-> http://www.w3.org/XML/XProc/docs/xml-proc-profiles.html

Norm: I've now dated it 24 January, with a comment period that ends 29 February.
... V.next?

V.next?

Norm: We're not getting a lot of discussion/progress.

Norm asks for help.

Jim: I've just gone through a cycle of intense XProc use. I'd like to give some observations.
... I think what's good is that we've got something that's relatively consistent in V1.
... Ports work, there's a set of standard steps, the XProc pipelines are highly reusable.
... What's bad: XProc feels like middleware more than a standalone processor.
... Sometimes I run away to xslt or xquery to get back to familiar terrain.
... One of the biggest problems is the abstraction of working with sets of documents seems baked in at the wrong level.
... Working with sets of documents seems difficult which is surprising. It almost seems like we need p:document*s*.
... We've enumerated most of the speed bumps: values in variables, having to add p:empty to p:parameters.
... I think the biggest thing is verbosity. We all know that options/variables/parameters are related.
... The same sort of thing with iteration-source/viewport-source/xpath-context.
... I don't know if we considered this: but it strikes me that we could have had one construct for p:for-each and p:viewport.
... There are simple scenarios that are hard to do. For example, dealing with ZIP files is a lot of work.
... I think we've missed a beat with respect to cross-platform issues. It's surprisingly easy to write a platform-specific pipeline.
... When I step back, I'd like to talk about what V.next is. Are we fixing things, so that it's more amenable to being adopted?
... Are we trying to expand its scope?
... I think fundamentally, XProc being a data flow language, we're not leveraging everything we could in a data flow language.
... Ultimately, the idea of how long the effort for V.next is interesting.
... We can do things to make the language more adoptable.
... That concludes that our V.next should be relatively short.

Norm: How long is a really good question?
... Are we going to do something small an fast, or are we going to try to tackle bigger issues?

Alex: What about parameters, lots of folks say we messed that one up.

Norm: Even if we all think parameters suck, until someone comes up with a better proposal, I'm not sure what we can do about it.

Norm puts Cornelia on the spot about long or short time frame.

Cornelia: My instinct is the former. I think if we don't get uptake in the shorter time frame, the longer term issues are going to be moot.

Norm: Thanks.
... I think I'm starting to hear consensus that one of the design goals for V.next should be that we get it finished quickly.

Alex: I wonder about the resource manager. If we're going to categorize small/big/large that resource manager is a big issue.

Jim: I think the resource manager is interesting. But we have to do it right.

Alex: I think we should focus on usability. Features like AVTs, additional steps, or additional options on existing steps.
... "Easier to use" and "more inventory of cool things" that would be a win.

Jim: I think we can also double-down on steps published as notes.

Alex: We might also consider as a WG how we're going to handle steps.

Norm mumbles a bit about the issue of step management.

Jim: How would we do that?

Norm: I think we could group them together.

Vojtech: Then the question is, how large do we want to grow the inventory of p: steps.

Alex: Maybe we should categorize things.
... We could start by categorizing the existing steps.

Norm: Vojtech, are you consered about having a large vocabulary of p: steps?

Vojtech: I think it was Michael Kay that was surprised that we had so many steps. We have things like p:rename and such (that could be implemented in XSLT or XQuery).
... Having more steps is a greater opportunity to get things wrong.
... It's more about having things done right than about adding things quickly.

Alex: It's like the XPath functions, they're in a separate spec.

Vojtech: Yes, we could have a separate document that enumerates all the steps.

Alex: Right.
... The only thing is there that we'd have to some definition of the core steps. You'd want to have a minimum number of steps that every processor had to implement.

Jim: I think that's the significant issue.

Alex: If they're in categories, then you can organize them that way.

Cornelia: I think that's a great idea too. Consider Atom: there's the core format, then the publishing spec, then there are lots of RFCs for all kinds of extensions.

<jfuller> I think Notes have to apply to optional steps

Norm: I'm confused, I thought having separate specs for zip/unzip, file utilities, os utilities, etc. was exactly that model

Alex: Well, Notes don't have the same standing as Recommendations.
... Atom is both an example and a counter-example. In order to use Atom, you have to go digging through all the possible extensions.
... I don't think we want to have everything in Notes, nor do we want to have to manage lots of Recommendations.
... Having a principle here would be good.

Norm: Yeah, we could have Recommendations for required steps and Notes for optional ones.
... For example.

Alex: That's what the HTML5 folks have been doing, breaking out functionality into separate specs.

Vojtech: With XProc you could take it to the extreme and say that the language doesn't define any atomic steps at all. That'd be the complete language.
... On top of that you could build standard libraries of steps.
... You could have required and optional profiles.

Norm: I think I hear consensus growing for separating the spec into at least two parts.

Alex; Maybe we could try to take up some subgroups.

Norm: Alex, would you take a stab at categorizing the existing steps.

Alex: Sure.

<scribe> ACTION: Alex to attempt to categorize the steps into a small number of groups. [recorded in http://www.w3.org/2012/01/19-xproc-minutes.html#action01]

Alex: My time between now and next week is pretty tight.

Norm: I wonder, Jim, if you'd look at a Note for zip/unzip, those seem very popular on xproc-dev

Jim: Sure.

<scribe> ACTION: Jim to start drafting a note for p:zip/p:unzip [recorded in http://www.w3.org/2012/01/19-xproc-minutes.html#action02]

Norm: So I think I heard consensus on two points.
... 1. Our focus for V.next will be on small items that we can accomplish quickly.

Accepted.

<scribe> ACTION: Norm to attempt to enumerate the items currently on the wikis that are "low hanging fruit" for V.enxt [recorded in http://www.w3.org/2012/01/19-xproc-minutes.html#action03]

Norm: 2. We want to consider dividing the spec into at least two pieces: a core language spec and a step library spec.

Jim: I don't disagree, but I'm wondering about the timing.
... Using energy and effort for that might mean other things don't get done. So maybe that's not the best thing.

Norm: Ok, we'll record the fact that people thought it was, in principle, a good idea, not that we're determined to do it.

Norm asks Henry about the plan to go quickly.

Henry: I'm reminded of Ashok's advice. If we don't really go quickly. If it takes us 9mo to a year to do a modest V.next, then we'll never get anyone to pay any attention again.
... I don't know how strongly I feel about that, or about whether it applies to us.

Jim: Is 9 months really what it takes?

Some discussion of timing.

Alex: If we're really into doing this quickly, then we need a laundry list of usability items that we want to accomplish and the other is the step inventory.

Any other business?

Paul: Liam reported at the CG call that the new charter is going through the process.
... It should happen by March.

Vojtech: There's a grand vision that Liam has about XProc/XSLT/XQuery coordinating.
... that may also influence what we are doing.

Adjourned.