W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > May 2009

XProc Minutes 28 May 2009

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 28 May 2009 11:59:34 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m21vq95ic9.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/05/28-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 145, 28 May 2009


   See also: [3]IRC log


           Henry, Paul, Vojtech, Norm, Mohamed





     * [4]Topics

         1. [5]Accept this agenda?
         2. [6]Accept minutes from the previous meeting?
         3. [7]Next meeting: telcon 4 June 2009
         4. [8]New public draft
         5. [9]Face-to-face meeting
         6. [10]The question of unbound options
         7. [11]Any other business

     * [12]Summary of Action Items


  Accept this agenda?

   -> [13]http://www.w3.org/XML/XProc/2009/05/28-agenda


  Accept minutes from the previous meeting?

   -> [14]http://www.w3.org/XML/XProc/2009/05/14-minutes


  Next meeting: telcon 4 June 2009

   Paul is at risk, so is Norm

   Henry gives regrets for 11 June

   Henry to chair 4 June in Norm's absence

  New public draft

   Is expected today.

  Face-to-face meeting

   Is expected in Santa Clara at the upcoming W3C Technical Plenary meeting
   during the first week of November, 2009.

  The question of unbound options

   -> [15]http://lists.w3.org/Archives/Public/xproc-dev/2009May/0116.html

   Norm: I think I've mostly come to terms with the fact that there's no
   pretty way out of this in V1.

   Henry: I agree; so the question is which of the ugly ways do we move

   Norm: I think Vojtech's observation that try/catch conflates this case
   with other errors motivates me.

   Henry: I'm motivated too.

   Norm: I think the lowest hanging fruit solution is a new XPath extension
   function, p:option-available.

   Norm summarizes

   Henry: I don't have any problem with p:option-available.
   ... I'm prepared to make the case that we don't need to go back to last
   call if we add this as a "feature at risk"

   Norm/Vojtech: This is easy to implement.

   Henry: We haven't heard from James Fuller, but we haven't heard from him
   about anything recently.

   Norm: Proposal: add this new extension function?


   Norm: The other proposal was Mohamed's bound-like-this-option attribute on

   Henry: I couldn't see how that didn't just push the problem one level

   Norm attempts to explain

   Mohamed: It's a very particular use case that this covers.

   Vojtech: In Mohamed's proposal, it takes the name of the option. What if
   we say that it takes an XPath expression and if that expression raises an
   error then the step will get an undefined value.

   Norm: That will also mask other sorts of errors, like wrong number of
   function arguments

   Henry: If we go that far, I want two additional attributes on
   p:with-option, @protected and @fallback.
   ... @protected is a boolean, if it's true then XPath errors in the select
   expression don't blow the pipeline.
   ... If @protected is true and there's no @fallback, you get undefined
   ... If @protected is true and there's an @fallback, you get the fallback.
   ... If @protected is false, you get the current behavior.
   ... So to get what Mohamed proposes you write "protected=true'

   Norm: I'm a little more comfortable that way.

   Vojtech: I don't think people will be using this feature a lot.

   Norm argues that maybe we don't want to go *this* far in V1.

   Henry: All this adds up to is: I think we should only do the
   p:option-available() and not Mohamed's suggestion or any of its

   Norm: I agree.
   ... Does anyone want to argue for more than p:option-available in V1?

   None heard

   Norm: Let's nail down the semantics just a little bit.

   1. p:option-available() takes a single QName argument

   2. It returns true if and only if there is an option with that name and
   that option has an in-scope value

   Henry: It should be p:value-available() or p:reference-valid or something
   like that if it works for any option/variable in scope.

   Norm: I see. I guess value-available works for me.


   Norm: I think the last question is...

   <ht> scribenick: ht

   Norm: does this return 'false' or throw an error if the supplied QName is
   not in scope at all?

   HST: Hunh? Oh yes, right -- well, helps the user more if it is an error
   ... How hard is that?

   Vojtech: It's easy for me, but is it right?

   Mohamed: I think an error is the right thing . . .
   ... Being consistent with other ...-available would be good
   ... step-available doesn't support this distinction

   Vojtech: value-available would do more, because it checks a) if there is a
   var/opt and b) if it has a value

   Mohamed: OK, so, two functions?

   Vojtech: Perhaps, or perhaps a second argument to control the error . . .

   HST: I'm happy with all three options: hard semantics, two functions or a
   2nd argument

   Vojtech: I'd prefer a 2nd argument

   Mohamed: Fine with me. . .

   HST: So, what is the 2nd argument called?
   ... Do we have optional args in XPath


   I want that to work

   scribe: with whatever semantics we agree for the 2nd arg
   ... So I guess I propose to call the 2nd arg 'allow-unknowns', with
   default False

   Vojtech: We've used fail-if-... elsewhere

   Mohamed: So 'fail-if-unknown' with default True

   HST: Works for me

   Norm: I don't fully see why this is necessary, but I can live with it

   Vojtech: I had some sense of dynamically-generated option names being

   Norm: I guess I would have just had it be 'soft'

   <Norm> scribenick: norm

   Vojtech: I also wonder if the function throws an error, if we need a
   special error code.
   ... We should be able to reuse an existing error.

   Norm: I'm happy either way.

   Mohamed: I think the existing error is fine.

   Vojtech: If we went this far, maybe there would be value in having a
   unique error code.

   Mohamed: I'm ok either way.

   Norm: Error codes are cheap, let's give it a new one.

   Vojtech: There was another bug reported on xproc-dev.
   ... If an unused option refers to an unbound option, is that ok?

   Norm: If you put a select expression is used in an option declaration,
   it's not evaluated then, it's evaluated when a step of that type is
   ... We don't have lazy eval of options and I don't think we need to add

   Vojtech/Henry: No!

   <scribe> ACTION: Norm to clarify "is needed" in 5.7.2 [recorded in

  Any other business

   Norm: Our new draft has been publish.


Summary of Action Items

   [NEW] ACTION: Norm to clarify "is needed" in 5.7.2 [recorded in

   [End of minutes]


    Minutes formatted by David Booth's [18]scribe.perl version 1.135 ([19]CVS
    $Date: 2009/05/28 15:58:43 $


   Visible links
   1. http://www.w3.org/
   2. http://www.w3.org/XML/XProc/2009/05/28-agenda
   3. http://www.w3.org/2009/05/28-xproc-irc
   4. http://www.w3.org/XML/XProc/2009/05/28-minutes#agenda
   5. http://www.w3.org/XML/XProc/2009/05/28-minutes#item01
   6. http://www.w3.org/XML/XProc/2009/05/28-minutes#item02
   7. http://www.w3.org/XML/XProc/2009/05/28-minutes#item03
   8. http://www.w3.org/XML/XProc/2009/05/28-minutes#item04
   9. http://www.w3.org/XML/XProc/2009/05/28-minutes#item05
  10. http://www.w3.org/XML/XProc/2009/05/28-minutes#item06
  11. http://www.w3.org/XML/XProc/2009/05/28-minutes#item07
  12. http://www.w3.org/XML/XProc/2009/05/28-minutes#ActionSummary
  13. http://www.w3.org/XML/XProc/2009/05/28-agenda
  14. http://www.w3.org/XML/XProc/2009/05/14-minutes
  15. http://lists.w3.org/Archives/Public/xproc-dev/2009May/0116.html
  16. http://www.w3.org/2009/05/28-xproc-minutes.html#action01
  17. http://www.w3.org/2009/05/28-xproc-minutes.html#action01
  18. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  19. http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 28 May 2009 16:00:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:47 UTC