See also: IRC log
Date: 6 Aug 2009
<scribe> Meeting: 151
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
<ht> oops, how time do fly
<ht> running to grab T, brb
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]
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.
<alexmilowski> Odd: Here's the official spec for UUIDs: http://www.itu.int/rec/T-REC-X.667-200808-I/en
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.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Keept he/Keep the/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Norm, Vojtech, PGrosso, Alex_Milows, Ht Present: Norm Paul Vojtech Henry Alex Agenda: http://www.w3.org/XML/XProc/2009/08/06-agenda Found Date: 06 Aug 2009 Guessing minutes URL: http://www.w3.org/2009/08/06-xproc-minutes.html People with action items: alex norm[End of scribe.perl diagnostic output]