W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > September 2008

XProc Minutes 25 September 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 25 Sep 2008 14:36:35 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2abdw5az0.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/09/25-minutes


                                   - DRAFT -

                            XML Processing Model WG

25 Sep 2008


   See also: IRC log[3]


           Vojtech, Norm, Alex, Richard, Andrew

           Henry, Mohamed, Michael




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: 2 Oct 2008
         4. Open actions
         5. Review of last call comments
         6. 016
         7. 020
         8. 022
         9. 024
        10. 027
        11. 030
        12. 031
        13. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/09/25-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/09/11-minutes


   Our Last Call period ends tomorrow!

  Next meeting: 2 Oct 2008

   Vojtech gives regrets; Norm at risk, but Henry will chair in his absence.

  Open actions

   Revisit after looking at the issues.

  Review of last call comments

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


   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


   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
   ... Then we could use error 25 for just the case that doesn't make any

   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 that one.
   ... So, we should allow match on p:replace to match elements, comments,
   PIs, and text nodes?

   Proposal: Change p:replace as suggested



   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
   ... 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 summarizes

   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

   <scribe> ACTION 2008-09-25-01: Norm to make the parallel change in
   [recorded in http://www.w3.org/2008/09/25-xproc-minutes.html#action01[11]]

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

   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


  Any other business?

   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


Summary of Action Items

   [NEW] ACTION 2008-09-25-01: Norm to follow-up with the XQuery/XSL WGs on
   this point. [recorded in
   [NEW] ACTION 2008-09-25-02: Norm to make the parallel change in
   [recorded in http://www.w3.org/2008/09/25-xproc-minutes.html#action01[15]]
   [NEW] ACTION 2008-09-25-03: Norm to make the XSLTMatchPattern reference a
   little more explcit [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/09/25-agenda
   [3] http://www.w3.org/2008/09/25-xproc-irc
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2008Sep/0049.html
   [11] http://www.w3.org/2008/09/25-xproc-minutes.html#action01
   [12] http://www.w3.org/2008/09/25-xproc-minutes.html#action02
   [13] http://www.w3.org/2008/09/25-xproc-minutes.html#action03
   [14] http://www.w3.org/2008/09/25-xproc-minutes.html#action02
   [15] http://www.w3.org/2008/09/25-xproc-minutes.html#action01
   [16] http://www.w3.org/2008/09/25-xproc-minutes.html#action03
   [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [18] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[17] version 1.133 (CVS
    $Date: 2008/09/25 18:35:26 $

Received on Thursday, 25 September 2008 18:37:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:41:08 UTC