See also: IRC log
<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
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.
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.
Norm summarizes the thread.
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.
Norm: The proposal is to standardize SVRL as the output.
Henry: I have no problem saying
that implementations SHOULD use SVRL[reference] for this
... 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.
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
... 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
Norm: Basically finished! The
XSL/Query comment needs more work, but there's nothing major in
... 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
... On C14N, we've already discussed this and said it was a user-defined option on serialization.
Norm: Good point! Thank you, Mohamed.
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]