See also: IRC log
Norm: Note that's a Thursday; still waiting on Liam for the time slot
No regrets heard.
Norm: See above :-)
Norm: I think A-210-03 is done.
Norm summarizes the changes
Norm: I believe that covers all the changes requested by commentors.
Jim: I tried to trace them back and I think it's a good response.
Norm: Ok, I'm going to point Michael to this draft.
Vojtech leads us through http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2013Jan/0022.html
Norm: Thanks Vojtech. It's an interesting idea. I can't quite decide if I'm comfortable with it or not.
Vojtech: Me neither.
... The 'autobind' attribute could also be on the step.
... But that introduces even more magic, the user has less control than with the top-down inheritence
Norm: I wonder if we can align it with XSLT "tunnel" parameters.
Norm and Henry have differing recollections of how tunnel parameters work.
Norm: Any other opinions on the inheritance
Jim: What happens when you bind a variable with something like fn:current-dateTime(); does that invoke when the time it gets used? Or at the declaration.
Vojtech: When it's used is my idea.
Norm: I don't think you can tell. Whatever value it gets, that's the value it gets everywhere.
Norm: It sounds like we need to think about this a little bit. Let's take it up next time.
Some discussion of what use cases this covers. Mostly the parameter input port magic.
Norm points to examples in http://www.w3.org/XML/XProc/2012/11/01-minutes
Vojtech: Those examples are mostly about how you construct the map, they didn't seem relevant.
Norm: I said I'd leave this on the agenda, but I don't have anything new to contribute this week.
No one else does either, apparently
Alex: I think one thing that's essential for the approach that I was advocating is a resource manager.
Norm: It's not a deeply complicated resource manager is it?
Vojtech: Is it something that's visible and controllable by the pipeline author?
Alex: No, I think it's for the spec. We have to be able to speak about how resources are stored with an opaque URI.
Vojtech: You mean we should say things like, for example, if your pipeline accesses the same URI twice at different times you should get the same data?
Alex: That's a fine point. Say you get an image with an http-request. The result is a c:data with an href you can resolve. Now in another step down the way, you get that element. You have to be able to get that image back from somewhere, I'm calling that somewhere the 'resource manager'.
Norm: I don't think it's that complicated. Pipeline authors can't control the 'resource manager'.
Henry: The simplest possible but
no simpler thing is what we're looking for. You have to speak
about locking, read/write, serialization, sequencing,
... It does seem to make sense to add to that as a strategic question, whether we should take the opportunity to implement the XSLT/XQuery constraint.
... I think we should address that question.
Norm: I think the XSLT folks are
relaxing that constraint in some cases, where they need to for
... WRT Alex's question about existing steps, I think we may need a new c:binary element or something.
Norm mumbles a bit about when you want to operate on the element and when you want to operate on the data
Jim: At XML Prague, in the morning of the pre-conference day, we have an hour and a half.
Jim: I think we're going to get
some advanced users.
... We'll get some new users too; I'd like to bring them on board.
... I'm hoping to release xprocxq at the conference.
... The other things I want to talk about are some of the latest approaches we're discussing.
Alex: I'm not sure I want to put
out there our half-baked ideas. Because there are so many
details we haven't thought through.
... But I think telling them our hot topics that we're trying to figure out is a great idea.
Jim: I'd be happy to say here are
the things we're working on for V.next
... The third thing I want to do is identify some of these XProc activities and get them in the expath repository.
... And my stretch goal is to get an XProc running within eXist.
Norm: Thanks, Jim, for the summary and for setting it up!