See also: IRC log
-> http://www.w3.org/XML/XProc/2008/09/25-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2008/09/11-minutes
Accepted.
Our Last Call period ends tomorrow!
Vojtech gives regrets; Norm at risk, but Henry will chair in his absence.
Revisit after looking at the issues.
-> http://www.w3.org/XML/XProc/2008/08/lastcall/comments.html
Mohamed asked us to review the kinds of nodes that can go through select/match patterns on steps
See http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Sep/0049.html
Norm's proposed changes to p:replace
Accepted.
Norm's proposed changes to p:wrap
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Sep/0045.html
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:
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Sep/0053.html
Norm's proposed changes to p:insert
Accepted.
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.
Accepted.
Vojtech: In p:replace, we say
that we can only replace elements.
... Isn't that like p:insert?
Norm: Yes, I must have overlooked
that one.
... So, we should allow match on p:replace to match elements,
comments, PIs, and text nodes?
Proposal: Change p:replace as suggested
Accepted.
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
one.
... 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
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2008Sep/0029.html
Norm summarizes
Norm: I've done my best, does
anyone have any other or better suggestions?
... Ok, then I'd like to close the issue.
Accepted.
Norm: I addressed this by changing the definintion in-scope variables in 2.6.2.1.
<scribe> ACTION 2008-09-25-01: Norm to make the parallel change in 2.6.1.1 [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.
Accepted.
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.
Accepted.
Norm: Let's go through this
one.
... I'm inclined to agree with point 1.
No objections.
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 2008-09-25-02: 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.
Sounds ok.
Norm: I'll try to address these in the next draft and bring back any issues that I see.
Norm: I'm inclined to make no change.
Proposal: Stick with the status quo
Accepted.
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 2008-09-25-03: Norm to make the XSLTMatchPattern reference a little more explcit [recorded in http://www.w3.org/2008/09/25-xproc-minutes.html#action03]
Adjourned.