W3C

- DRAFT -

XML Processing Model WG

06 Aug 2009

Agenda

See also: IRC log

Attendees

Present
Norm, Paul, Vojtech, Henry, Alex
Regrets
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2009/08/06-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2009/07/30-minutes

Accepted.

Next meeting: telcon 20 Aug 2009

Cancelling 13 Aug for Balisage

Henry gives regrets for 20 Aug, 27 Aug

155 Circular and re-entrant libraries

Basically, what we've got doesn't work. Henry has made an alternate proposal.

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2009Aug/att-0000/import_algorithm.html

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

Scribe struggles

Henry: The problem is that the algorithm as I specified it doesn't check the nested pipelines.
... 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.

148 Parameter names cannot be in the XProc namespace

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?

Norm: Yes.

Propsal: Keep the prohibition, create a new dynamic error for the parameters case.

Accepted.

149 UUID

Norm: I think this is editorial.

Alex: I can dig up a normative reference and send it to you.

Norm: Thanks!

<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

150 err:XD0002 and err:XD0011 and err:XD0029

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.

Accepted.

151: Why is err:XC0001 a step error?

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.

Norm: Sold!

Proposal: Remove err:XC0001 using err:XD0020 there instead.

Accepted.

152: p:http-request and err:XC0020

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.

Accepted.

<scribe> ACTION: Norm to generalize err:XC0020 appropriately. [recorded in http://www.w3.org/2009/08/06-xproc-minutes.html#action02]

156: What nodes does replace act on?

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.

Accepted.

Any other business?

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.

Adjourned.

Summary of Action Items

[NEW] ACTION: Alex to find a normative reference for UUID algorithms. [recorded in http://www.w3.org/2009/08/06-xproc-minutes.html#action01]
[NEW] ACTION: Norm to generalize err:XC0020 appropriately. [recorded in http://www.w3.org/2009/08/06-xproc-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/08/06 15:58:30 $