See also: IRC log
Date: 25 Sep 2008
<scribe> Meeting: 126
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
Ok, thanks for letting me know, Paul
Uhm. Only if there's one of the open issues you feel a burning need to disagree with the editor over :-)
Hmmm. Is anyone talking?
You can't hear *me*
Our Last Call period ends tomorrow!
Next meeting: 2 Oct 2008
Vojtech gives regrets; Norm at risk, but Henry will chair in his absence.
Revisit after looking at the issues.
Norm asked us to review the kinds of nodes that can go through select/match patterns on steps
Norm's proposed changes to p:replace
Norm's proposed changes to p:wrap
Richard: I don't have a strong objection, but I'm a bit dubious about having what nodes are ignorable depend on what's on either end.
Vojtech: Can it happen that you have a match that matches an element or a text node.
Richard: What about two text nodes with a comment between them? You might want to group those.
Norm: I see, that would work according to the old rules.
Rejected, stick with the status quo.
Norm: Then Mohamed and I had a short discussion about p:insert, ending with:
Norm's proposed changes to p:insert
Richard: Just a moment. Suppose the match pattern matches a PI before the document element.
Norm: Then we could just let the natural failure mode handle that.
Richard: If we have an error for
producing a document that's not well formed, then we could
remove that case--we don't need a special error for it.
... Then we could use error 25 for just the case that doesn't make any sense.
Norm: I'm happy with that.
Proposal: Adopt Norm's proposal with Richard's change to error 25.
Vojtech: In p:replace, we say
that we can only replace elements.
... Isn't that like p:insert?
Norm: Yes, I must have overlooked
... So, we should allow match on p:replace to match elements, comments, PIs, and text nodes?
Proposal: Change p:replace as suggested
Now on to issue 20
Norm: I misunderstood issue 020
last time we talked about it. I thought it was about XML
encryption/decryption, effectively a dup of the other
... But in fact, it's about text-encrypt, a la gnupg.
... I dont' think we ahve a use case for that, so I'm inclined to reject it.
... If we did add it, it would be a little complicated because it would need to be a wrapper.
Richard: Henry suggested we should allow the relevant WGs to invent their own libraries.
Alex: Right. We let users create
new steps, so they can do it.
... We'll revisit in 1.1 or 2.0 or something.
Norm: Yes, but we have an encyption/decryption use case in our requirements document, so I'm a little worried.
Richard: Presumably we aren't required to do it if we have a good explanation. Not having the expertise seems like a good reason.
Norm: I'm content to leave the
*XML* encryption/decryption case open until after we've been
able to speak with the XML Security WG.
... This issue is about text encryption.
Proposal: Reject this issue.
Accepted, no new steps for text encryption/decryption
Norm: I've done my best, does
anyone have any other or better suggestions?
... Ok, then I'd like to close the issue.
Norm: I addressed this by changing the definintion in-scope variables in 220.127.116.11.
<scribe> ACTION: Norm to make the parallel change in 18.104.22.168 [recorded in http://www.w3.org/2008/09/25-xproc-minutes.html#action01]
Norm summarizes the changes: defining in-scope variables as being the "specified options" and adding a note about unspecified options.
Norm: Does anyone think that that fails to adequately resolve the issue?
Proposal: That resolves the issue.
Norm: The change here is wrt the
type of options, variables, and parameters
... I've changed the introductory sections to say that the values "MUST be a string or xs:untypedAtomic" where they used to say "MUST be a string".
... I felt that was necessary for consistency with the actual definitions later on.
... Does anyone have reservations about that change?
Proposal: That's fine.
Norm: Let's go through this
... I'm inclined to agree with point 1.
Richard: It's ok as long as none
of *our* steps have any implementation-defined ones.
... Do they want XProc implementations to be allowed to have extra pre-defined namespaces, or whether they merely want it to be possible for certain steps to have certain pre-defined namespaces.
<scribe> ACTION: Norm to follow-up with the XQuery/XSL WGs on this point. [recorded in http://www.w3.org/2008/09/25-xproc-minutes.html#action02]
Norm: The only other non-editorial comment is about the XQuery step. I'm inclined to accept comments from the XQuery WG about the p:xquery step.
Norm: I'll try to address these in the next draft and bring back any issues that I see.
Norm: I'm inclned to make no change.
Proposal: Stick with the status quo
Vojtech: Someone asked on xproc-dev what the definition of the XSLT match pattern is; is there a clear definition? We should try to clarify that.
Norm: I'm happy to point a little more explicitly to the respective definitions of Pattern in XSLT 1.0 and 2.0.
<scribe> ACTION: Norm to make the XSLTMatchPattern reference a little more explcit [recorded in http://www.w3.org/2008/09/25-xproc-minutes.html#action03]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/here/hear/ Succeeded: s/chagne/change/ Succeeded: s/ciit/cit/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Present: Vojtech Norm Alex Richard Andrew Regrets: Henry Mohamed Michael Agenda: http://www.w3.org/XML/XProc/2008/09/25-agenda Found Date: 25 Sep 2008 Guessing minutes URL: http://www.w3.org/2008/09/25-xproc-minutes.html People with action items: norm[End of scribe.perl diagnostic output]