XProc Minutes 4 Sep 2008

See http://www.w3.org/XML/XProc/2008/09/04-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 124, 04 Sep 2008


   See also: IRC log[3]


           Mohamed, Paul, Norm, Vojtech, Alex, Richard, Henry, Andrew,





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 11 Sep 2008?
         4. Action items
         5. Open last call comments
         6. 004
         7. 020
         8. 021
         9. 022
        10. 023
        11. 024
        12. Any other business
     * Summary of Action Items


  Accept this agenda?

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


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2008/08/28-minutes


  Next meeting: telcon 11 Sep 2008?

   Norm gives regrets, Henry to chair.

  Action items

   Henry completed ACTION-2008-08-14-01, the XProc charter is extended until
   31 Dec 2008.

  Open last call comments

   There are only a few left, and few are coming in. Yay!


   Norm: p:choose currently requires p:xpath-context followed by p:variable*

   Henry: Right, I think we should allow them in any order. I could, for
   example, want to bind a variable that I then want to refer to in the
   ... It'll be clearer if the variable can come first.

   Mohamed: How about just swapping p:variable* and p:xpath-context?

   Henry: That's sufficient for my use case, but I actually think that the
   order in the spec is the one that folks are usually going to want to do.

   Norm: I don't see any compelling reason not to do what Henry suggests.


   Vojtech: It's already the case that p:for-each and p:viewport require the
   context to come first.

   Mohamed: Variable can be very useful, but they make the spec very, very

   Norm: We could relax this restriction in the future, since it wouldn't
   make any pipelines invalid.

   Henry: The thing that I didn't realize before is that p:xpath-context
   unlike p:input doesn't have a select attribute.
   ... I guess I withdraw my suggestion.

   Proposal: The suggestion is withdrawn, close with no action



   Norm: This is encryption and decryption, I don't think we've made any
   progress here.
   ... I've agreed to talk to the XML Security WG on Tuesday, 16 September.

   <scribe> ACTION: Norm to ask the Security WG to invite the rest of the WG
   (anyone who's interested) [recorded in

   Norm: Let's hold off on trying to deal with encrypt and decrypt until at
   least after that meeting


   Norm attempts to summarize the p:pipeinfo vs. allowing non-step namespaced
   elements everywhere.

   Norm: Anyone want to reopen this discussion.

   None heard.

   Michael: Allowing foreign namespaces anywhere is fine if the basic rule is
   that it's there in the document and what you can do with that document is
   what you can do with it.
   ... if I put stuff in a foreign namespace somewhere in a pipeline, can
   anyone access it?

   Norm: You can always do introspection on the pipeline docuement, but I
   think most extra stuff is either for implementation-defined purposes or
   for other applications, not for the pipeline itself.

   Proposal: Reject the request, leave the status quo.



   Henry: Yes, I tripped over this too when revising the DTD. It's not a
   substantive change, it's just an editorial correction and I think we
   should do it.

   Norm: Yes, I think so to.

   Proposal: Ask the editor to make the editorial improvements necessary



   Henry: The short answer is, we considered and rejected this. I think the
   better answer is, you can just leave out the whole input from your
   identity step.
   ... The wG has decided that when you write p:pipe, you have to say
   everything. Anything else is just too confusing.

   Norm: Allowing different defaults just seems too confusing.

   Henry: Missing attributes on pipe having one convention and missing input
   having another is just too likely to cause confusion.

   Proposal: Reject this proposal, stay with the status quo.



   Henry: Looking back at the original problem Mohamed observed, I think
   there are three possibilities:
   ... 1. It's an error; we can say that either p:option declarations must
   specify a default or be required (or we could say the same at runtime)
   ... 2. The implementation can't access a value for the option.
   ... In this case, there will be an error; I was thinking of atomic steps

   Mohamed: So I don't think we need a @required.

   Henry: I don't agree, there are lots of cases where the option isn't going
   to be used at all.

   Mohamed: But I think we need a special function to test if the variable is
   bound or not.

   Henry: 3. The default for default is the empty string.
   ... But I really don't like that.
   ... It follows naturally for XSLT, because the default comes from teh
   content, but we don't do that.

   Norm: I'm inclined along the lines of Henry's #2. I think it's ok if
   options have no value. In the case that Mohamed points out, if it wasn't a
   test case, we'd suggest putting required='true' on that option.

   Henry: I think I agree. I'd like to preserve the distinction between
   defaulted and not provided.
   ... If we go this way, the prose about the XPath context will have to be
   clear that the in-scope options do not contain options that were optional
   and not supplied.
   ... It's worth noting that the phrase "in-scope options" isn't defined.

   <ht> Yes, there is a definition of in-scope bindings. . .

   Henry: I'll look to see if there's a place to say that processors may/must
   allow atomic step implementations to distinguish between the two cases.

   <ht> Ah, we have a notion of "specified options"

   Mohamed: The difference between Henry's and Jeni's proposal is that Jeni's
   was "fail fast": you must specify a default or required; Henry's is "fail

   <alexmilowski> yep

   Norm: Yes, I prefer Henry's form as well. So it's a dynamic error if a
   non-defaulted, non-required option has no binding and a reference is made
   to it.

   Henry: Yes, but the right way to say it is that the variable bindings in
   the XPath context are determined by the *specified options*.

   Norm: For all the atomic steps that we define, that have options that are
   neither required nor have default values, we should say what it means if
   they aren't provided!

   Vojtech: The serialization options for p:store, for example.

   Henry: The defaulting of serialization options is a specified in the QT
   serialization document.
   ... I think this also means that we must say somewhere that implementors
   of atomic steps must be given a way of determining whether optional,
   non-defaulted options where specified or not.

   <scribe> ACTION: Henry to review the optional options and suggest what we
   should say about each of them [recorded in

   Proposal: Allow optional options, it's a runtime error if you attempt to
   refer to an unspecified optional option.


  Any other business

   Norm: Anyone going to the plenary, remember to register and book your

   No other business heard.


Summary of Action Items

   [NEW] ACTION: Henry to review the optional options and suggest what we
   should say about each of them [recorded in
   [NEW] ACTION: Norm to ask the Security WG to invite the rest of the WG
   (anyone who's interested) [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/09/04-agenda
   [3] http://www.w3.org/2008/09/04-xproc-irc
   [6] http://www.w3.org/2008/09/04-xproc-minutes.html#action01
   [7] http://www.w3.org/2008/09/04-xproc-minutes.html#action02
   [8] http://www.w3.org/2008/09/04-xproc-minutes.html#action02
   [9] http://www.w3.org/2008/09/04-xproc-minutes.html#action01
   [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [11] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[10] version 1.133 (CVS
    $Date: 2008/09/04 17:57:03 $

Received on Thursday, 4 September 2008 17:58:40 UTC