- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 19 Jan 2012 11:29:05 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2k44nwt9q.fsf@nwalsh.com>
See: http://www.w3.org/XML/XProc/2012/01/19-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 206, 19 Jan 2012
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Jim, Paul, Alex, Vojtech, Carine, Cornelia, Henry (near the
end)
Regrets
Mohamed
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon, 26 January 2012.
4. [8]Processor profiles document
5. [9]V.next?
6. [10]Any other business?
* [11]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [12]http://www.w3.org/XML/XProc/2012/01/19-agenda
Accepted.
Accept minutes from the previous meeting?
-> [13]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.
-> [14]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
[15]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 [16]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
[17]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.
Summary of Action Items
[NEW] ACTION: Alex to attempt to categorize the steps into a small number
of groups. [recorded in
[18]http://www.w3.org/2012/01/19-xproc-minutes.html#action01]
[NEW] ACTION: Jim to start drafting a note for p:zip/p:unzip [recorded in
[19]http://www.w3.org/2012/01/19-xproc-minutes.html#action02]
[NEW] ACTION: Norm to attempt to enumerate the items currently on the
wikis that are "low hanging fruit" for V.enxt [recorded in
[20]http://www.w3.org/2012/01/19-xproc-minutes.html#action03]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [21]scribe.perl version 1.136 ([22]CVS
log)
$Date: 2012/01/19 16:25:47 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2012/01/19-agenda
3. http://www.w3.org/2012/01/19-xproc-irc
4. http://www.w3.org/XML/XProc/2012/01/19-minutes#agenda
5. http://www.w3.org/XML/XProc/2012/01/19-minutes#item01
6. http://www.w3.org/XML/XProc/2012/01/19-minutes#item02
7. http://www.w3.org/XML/XProc/2012/01/19-minutes#item03
8. http://www.w3.org/XML/XProc/2012/01/19-minutes#item04
9. http://www.w3.org/XML/XProc/2012/01/19-minutes#item05
10. http://www.w3.org/XML/XProc/2012/01/19-minutes#item06
11. http://www.w3.org/XML/XProc/2012/01/19-minutes#ActionSummary
12. http://www.w3.org/XML/XProc/2012/01/19-agenda
13. http://www.w3.org/XML/XProc/2012/01/05-minutes.html
14. http://www.w3.org/XML/XProc/docs/xml-proc-profiles.html
15. http://www.w3.org/2012/01/19-xproc-minutes.html#action01
16. http://www.w3.org/2012/01/19-xproc-minutes.html#action02
17. http://www.w3.org/2012/01/19-xproc-minutes.html#action03
18. http://www.w3.org/2012/01/19-xproc-minutes.html#action01
19. http://www.w3.org/2012/01/19-xproc-minutes.html#action02
20. http://www.w3.org/2012/01/19-xproc-minutes.html#action03
21. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
22. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 19 January 2012 16:29:49 UTC