See also: IRC log
Cancelling 13 Aug for Balisage
Henry gives regrets for 20 Aug, 27 Aug
Basically, what we've got doesn't work. Henry has made an alternate proposal.
Vojtech: I think there's still an issue with nested pipelines.
Henry: I think there is a
problem...but not with nested pipelines.
... I don't think nested pipelines are a problem because the algorithm stops when it hits a p:pipeline child.
... Consider a pipeline that has an import and a nested pipeline (as a sibling of import)
... And that nested pipeline defines symbols (nested pipelines or an import of its own).
<ht> [pipe <import a> [pipe <import b>][pipe <import c>]]
Henry: The problem is that the
algorithm as I specified it doesn't check the nested
... I think I know how to fix that without changing the algorithm, but we need a different set of initial conditions.
... To check a pipeline, you need to know the exports of its parent and the URIs that were involved in checking that and you start with those.
... I'll send another message in a little while with an update.
Vojtech: I'm happier with the new proposal, including Henry's addendum. I think it's easier to understand.
Norm: Yes, I think so to.
... Ok, we'll continue the review in email and touch base again at the next telcon.
Vojtech: For options and
variables, the spec says they can't be in the XProc namespace.
It says the same thing about paramters.
... But I don't think it can be a *static* error for parameters.
Norm: Right. It's clearly not a static error.
Vojtech: Is it really necessary to say this about parameters?
Norm: We own it, that's why we
say it, but I don't feel strongly about it.
... Would anyone ever need to write a stylesheet that used parameters in the XProc namespace?
... I can't think of a reason. I'm inclined to leave the prohibition but make the parameter case dynamic.
Vojtech: But leave options and variables static?
Propsal: Keep the prohibition, create a new dynamic error for the parameters case.
Norm: I think this is editorial.
Alex: I can dig up a normative reference and send it to you.
<scribe> ACTION: Alex to find a normative reference for UUID algorithms. [recorded in http://www.w3.org/2009/08/06-xproc-minutes.html#action01]
<alexmilowski> Odd: Here's the official spec for UUIDs: http://www.itu.int/rec/T-REC-X.667-200808-I/en
Norm: Yes, it seems odd to have
all three. We could lose 2 or 11 and 29 I think.
... I guess losing 2 is the way to go, it's in a part of the spec distant from the other constraints on p:document and p:data.
Vojtech: I would remove 2.
Proposal: Remove err:XD0002 in favor of the two more specific errors, 11 and 29.
Vojtech explains why they should both be dynamic errors.
Norm: I think you're right.
Proposal: Rename err:XC0001 to some appropriate dynamic error number
Norm: Actually, I think err:XC0001 is simply subsumed by err:XD0020. There's no need to call out method if we aren't going to call out all of them.
Vojtech: Do we need two: one for invalid values and one for unsupported values?
Norm: I don't know, I'm not sure users will get value out of that distinction.
Vojtech: When I was writing the serialization tests, I had problems telling them apart.
Proposal: Remove err:XC0001 using err:XD0020 there instead.
Alex: In both cases, it's about making sure the values are consistent.
Norm: Does anyone diagree that those are two cases of the same error, that is that one error code is sufficient.
Vojtech: The first definition talks specifically about the header value.
Alex: The spirit of this error is
that to make a request, you have to get all the packaging
right: headers, options, etc. have to match.
... The first mention talks about headers, but the boundry and a few other things also come into play.
Norm: I'm happy to reword err:XC0020 so that it's clear that what we're testing is general consistency in a request.
Proposal: Generalize err:XC0020 so that it's more appropriate for both cases.
<scribe> ACTION: Norm to generalize err:XC0020 appropriately. [recorded in http://www.w3.org/2009/08/06-xproc-minutes.html#action02]
Vojtech: The replace step talks
about the "elements" that it matches, but later on it talks
about comments, PIs, text, etc.
... I think it should talk about nodes instead of elements.
Norm: Sounds right to me.
Proposal: Replace elements with nodes where appropropriate to make the description accurately reflect what the step does.
Norm: We're getting very close to being done. Maybe September? I'll have a more coherent report of coverage by the next meeting.
No other business heard.
Alex: Who's going to Balisage?
Norm: I think it's you and I and Mohamed.