W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > January 2012

XProc Minutes 19 January 2012

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


                                   - DRAFT -

                            XML Processing Model WG

Meeting 206, 19 Jan 2012


   See also: [3]IRC log


           Norm, Jim, Paul, Alex, Vojtech, Carine, Cornelia, Henry (near the





     * [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


  Accept minutes from the previous meeting?

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


  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
   ... 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
   ... Sometimes I run away to xslt or xquery to get back to familiar
   ... 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
   ... 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

   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

   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:

   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

   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

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

   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


   <scribe> ACTION: Norm to attempt to enumerate the items currently on the
   wikis that are "low hanging fruit" for V.enxt [recorded in

   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

  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
   ... that may also influence what we are doing.


Summary of Action Items

   [NEW] ACTION: Alex to attempt to categorize the steps into a small number
   of groups. [recorded in
   [NEW] ACTION: Jim to start drafting a note for p:zip/p:unzip [recorded in
   [NEW] ACTION: Norm to attempt to enumerate the items currently on the
   wikis that are "low hanging fruit" for V.enxt [recorded in

   [End of minutes]


    Minutes formatted by David Booth's [21]scribe.perl version 1.136 ([22]CVS
    $Date: 2012/01/19 16:25:47 $


   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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:50 UTC