<ht> Agenda: http://www.w3.org/XML/XProc/2008/10/02-agenda.html

<ht> Next meeting: 9 October, no regrets noted

<ht> Minutes accepted as posted

Namespace binding examples

<ht> http://www.w3.org/XML/XProc/docs/langspec.html#opt-param-bindings

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Sep/0024.html

Henry: I read it again and while it was complex, that complexity stems from the complexity of the feature, I think.
... I was left feeling that I wish we didn't have to do this.

Norm: But we do...
... if anyone has any specific suggestions, I'd be happy to try, but I've done all I can.

Mohamed: I think the examples are fine; I think it could be simpler, but mostly I just don't want users to be confused.

Norm: I think most users will never need this, and hopefully by the time they do, there will be nice tutorials somewhere.
... Proposal: we're done, the revised prose is fine.

Accepted.

008

Norm: This was a comment RELAX NG step. Henry pushed a little bit about APIs. And I went off and took a closer look.

Norm summarizes his email.

Norm: Err, dtd-id-idref-errors should be dtd-id-idref-warnings

Henry: Works for me.

Proposal: Accept Norm's suggestions, close the issue.

Accepted.

032

Norm summarizes the thread.

Proposal is in: http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2008Sep/0044.html

Henry: I don't understand the phase thing, but I'm not going to argue about it.

Proposal: Accept Norm's suggestions and close the issue.

Accepted.

033

Norm: The proposal is to standardize SVRL as the output.

Henry: I have no problem saying that implementations SHOULD use SVRL[reference] for this purpose.
... The substantive issue of another output port for positive reports probably does need a new port.

Norm: We already have a secondary port, can't we just put postive reports there?

Henry: So it's impl defined what goes on that port. The only thing that's for sure is that if assert-valid is true then errors will go there if there are errors.

Proposal: All reports (error or otherwise) go on the report port. We'll say that the output SHOULD be in SVRL.

Accepted.

034

Norm: This amounts to a proposal for a secondary port on the validation steps on which the answer 'true' or 'false' appears depending on whether or not the validation was successful.

Henry: I got a private reply from James.
... He agrees that try/catch can be used, but thinks it would be more consistent if the result was available directly.
... Part of the problem is that in my pipeline, I support the PSVI and I have an extension function that makes it trivial to get this answer.
... We could put the validity/validation attempted results on the document in an XProc namespace.

Mohamed: Streaming is also a problem.

Some discussion of encoding of PSVI items...

Richard: It's possible that you might want to determine the validity w/o doing anything with the validated result.
... I think the argument you quoted about the output of the step reflects a different idea about what validation means. If you're just asking the question, then it is, but if you're expecting downstream steps to use the result, then it isn't.

Norm: Neither answer seems compelling to me.

Henry: What's someone going to do with this result? Presumably they're going to put a choose in and write to subpipelines anyway...

Richard: Maybe not, maybe the answer is just true/false

Norm: But that's not terribly useful by itself.

Mohamed: I don't think it's worth having this answer. It would make streaming imposible, so try/catch wouldn't be too much of a burden.
... You just write your own wrapper pipeline to get the result.
... Even in the proposal, there's the idea that you might want the error, etc. So that should be done in a try/catch.

Henry: Yeah, I agree.
... This just encourages too many different ways to write the same thing.

Norm: We earlier set "can you do it yourself" as a criteria for new steps, that can apply here.

Mohamed: Right. This would change all the validate steps which is too big a change from my perspective.

Proposal: Reject this request, you can get the result yourself with existing features of XProc

Accepted

Where are we?

Norm: Basically finished! The XSL/Query comment needs more work, but there's nothing major in it.
... The question of XML encryption/decryption/c14n, etc. is something we'll discuss with the XML Security WG next week.

Norm describes his feelings about security which amount to putting the new steps in a separate document.

Henry: I've supported that approach already.

Mohamed: I think I agree. My proposal a few months ago was to put it all in a parameter port and try to standardize with a clear proposal. It ends up being the same to have it a separate note or REC-track document.
... On C14N, we've already discussed this and said it was a user-defined option on serialization.

Norm: Good point! Thank you, Mohamed.

Test suite

Norm outlines that we'll get to CR just after the f2f. But we need tests to get out.

Mohamed: How will we split up the work?

Norm: Submit tests and I'll contrive to get some reports about what the coverage is.
... If people submit tests, I'll write some reports on analytics.

Mohamed: Ok, I'll write some tests.

Henry: If I have an idle day, I'll look at what would be required to convert my private tests into our format.

<scribe> ACTION: Norm to update the RELAX NG grammer for the test suite vocabulary [recorded in http://www.w3.org/2008/10/02-xproc-minutes.html#action01]

Any other business?

None heard.

Adjourned.