See also: IRC log
Vojtech gives regrets for two weeks.
Some discussion of the charter. It's now out for AC vote.
<Liam> [note, it was changed very slightly since Norm saw it, but I think not significantly (e.g. meeting frequency clarified), but comments can be made in the AC review.]
A-207-02: Completed, gone out to AC for review
A-213-04: is 5.27, still open on Alex.
Norm: Murray, I assume you'll insert them in the document.
Murray: Yes, of course.
Norm: Anyone have anything to add?
Cornelia: I was able to find the editor's draft of the use cases/requirements but only in email?
Norm: Alex, is it checked in somewhere?
<scribe> ACTION: Norm to make sure everyone knows the stable URI for the use cases/requirements document [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action01]
Henry: Once it's anywhere under the XProc CVS, it's available.
Murray: Do you want me to mail a draft?
Norm: No, let's get it checked in and send out the pointer to the stable pointer.
Cornelia: There were use cases and requirements marked as satisified, are those old ones?
Murray: The use
cases/requirements document is the 1.0 version supplemented
with original material.
... What we've been doing is improving those use cases.
... And assuring ourselves that we've satisfied them.
<jfuller> link to old use case document
Murray: But we're still detailing them.
Cornelia: With the current version of XProc?
Norm attempts to explain the motivation for repeating the use cases: to provide real pipelines and to look at how they might be simplified for V.next.
Murray: We've also got DAISY requirements that we can incorporate in support of the work we've done.
Norm describes the problem of having "out-of-date" schemas and XPL wrt the new template note.
Henry: We should have put those documents in date space at publication time. Then we could have a dated version that never changes and an undated version that you can keep up-to-date.
<scribe> ACTION: Henry to stage the dated and undated versions of updated schemas and library.xpl [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action02]
Norm: Mohamed summarizes the issue here:
Norm: The original problem was that the XSD for p:catch doesn't allow a name attribute, but it must be allowed to have one.
<MoZ> sure, but do we allow to have one on p:when and p:otherwise
<scribe> ACTION: Norm to clarify with Mohamed to see if he thinks there's really a problem here. [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action03]
Norm: Does anyone disagree that the XSD for XProc has bug?
<MoZ> Basically my proposal is to fix the XSD
<scribe> ACTION: Henry to fix the bug where p:catch doesn't allow a name in the XSD. [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action04]
<MoZ> but the real question is whether we need to allow name on p:when and p:otherwise
MoZ, let's take that offline.
<MoZ> Norm, fine
<jfuller> sounds good to me
Murray: What about variables?
Norm: I think Mohamed suggested we use a template style.
Vojtech: But how can that work? Where would you set the parameters?
Norm: Yeah. Maybe it doesn't work.
Vojtech: Why can't we just use ordinary XPath expressions?
Norm: So maybe you use the template style but you can't have any variable references because there are no parameters
Murray: I guess I don't understand how this template thing would work.
<scribe> ACTION: Norm to consider the template idea and provide an example of how that might look [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action05]
Alex: I think the next thing you
do with this thing would be to come up with some motivating
... One of the things I have to do in other ways is to figure out what values variables have. It's not just the document, it's also the other bits that are coming into the step.
Vojtech: I see two situations. If
you put p:log in p:group then you can have variables or options
that are inscope and you could say that those are visible in
... But on the top-level, there's probably no way to refer to variables.
... Though maybe pipeline options.
Alex: I'm assuimg there are
limitations. You don't want to get into circularity.
... I think we need a short list at least of things that we expect to work.
Henry: Can I come back on this
question of template?
... These aren't common, garden variety steps. These are names in p:; we can make their content be evaluated in any context we choose.
... So I don't see any a priori reason why we can't say that p:assert with a body is effectively shorthand for a p:template with a connection to a template.
... I don't think the workaround Mohamed suggested is necessary, we can define the body to be evaluated as we wish.
Vojtech: I think it needs to be consistent with AVTs.
Alex: Are we going to allow markup, or just text?
Norm: The xsl:message instruction allows markup and that's handy every now and then. I might be inclined to allow markup.
<alexmilowski> (Veronika cries about markup … does her vote count?)
Norm: I think the 90% case is probably just text, but that's not a reason to forbid markup.
Henry: I agree.
Alex: We will need to consider the document element case for plain text.
Murray: Somewhere in the
requirements document, there's a list of variables that are
available somehow to the XProc engine.
... Would someone go through that list and verify it?
<scribe> ACTION: Norm to review the list of "variables" in the use cases/requirements and see if it's correct. [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action06]
Murray: It would be useful to me to see a simple pipeline with several levels showing what the values of variables are at the different levels.
Norm: There's probably one of those in the test suite because we had to test scoping.
<scribe> ACTION: Norm to point Murray to the scoping tests in the test suite. [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action07]
Jim: I think streaming and parallel processing are out of scope.
Alex: How so?
Jim: In my opinion, they're just to big and hard for V.next.
Alex: I'm curious if there's
low-hanging fruit that we could do to enable or guarantee that
we can create streaming processors.
... We have one member who's worked on this, I don't know what else might have been done.
... I think we need to keep this around in order to make sure we don't violate our own requirements.
Jim: I think I'd have to review those requirements.
Alex: I think we should at least give Mohamed and others a chance to tell us if there's low-hanging fruit.
Murray: I think the point of this
exercise is allow anyone with streaming/pp requirements to step
up and present them.
... Then we can document those requirements for the future.
Norm mumbles something about dependency analysis.
Norm: I guess if no one else has comments now, we'll leave this and see what comes back in terms of low-hanging fruit.
Henry: I'm largely in agreement that it's out-of-scope, but the observation that "you just made it impossible to stream in this case and you didn't have to" is always in order.
Murray: There's that and there's also documenting things. If you're intending to build a streaming or parallel process, then watch out for these things.
Alex: One path forward wrt that,
as a side task, would be to enumerate some examples of things
in XProc that should stream and for what reason.
... I think that would be a note or something.
Norm observes that his own plans for streaming will supply some of those answers. Someday.
Alex: The quick question I have
is the organization of the document. New material vs. the old
... When you see this draft, there's the original structure of the requirements document and then there's a bunch of stuff in the appendixes.
... What's the right organization?
Norm: I think that's the editor's job.
Alex: Do we want to keep the old structure, or have a new document?
Murray: My goal was to gather
things in the appendixes for now so that everything is in one
... Eventually, sometime this summer, I was hoping we'd be able to migrate stuff from the appendixes into the body of the document.
... We'd leave all the existing things in place and add more.
... This would be a living/growing document that would guide the development of XProc in the future.
Norm: That sounds fine to me.
Murray: Earlier, we were talking
about information available for debugging. There are two
sections: F.3.4 and F.5.12.
... Under F.3.4, there's a list of steps that provide information.
... I'd like to see a useful pipeline that uses those steps and functions that I can plop into the document.
Norm: I'd draw a distinction between things like pos:env and p:step-available.
Murray: I don't disagree that
they're different, I just need to see a pipeline that delivers
all that information.
... Part of the purpose of seeing such a pipeline is to see what's missing.
<scribe> ACTION: Norm to write a pipeline that summarizes the environment in which a pipeline runs to the extent possible. [recorded in http://www.w3.org/2012/05/24-xproc-minutes.html#action08]