See also: IRC log
-> http://www.w3.org/XML/XProc/2009/05/28-agenda
Accepted
-> http://www.w3.org/XML/XProc/2009/05/14-minutes
Accepted
Paul is at risk, so is Norm
Henry gives regrets for 11 June
Henry to chair 4 June in Norm's absence
Is expected today.
Is expected in Santa Clara at the upcoming W3C Technical Plenary meeting during the first week of November, 2009.
-> 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 forward.
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?
Accepted.
Norm: The other proposal was Mohamed's bound-like-this-option attribute on p:with-option
Henry: I couldn't see how that didn't just push the problem one level down.
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'
select='$foo'"
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 refinements.
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.
Accepted.
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
p:value-available('foo')
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 tested
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
instantiated.
... We don't have lazy eval of options and I don't think we
need to add it.
Vojtech/Henry: No!
<scribe> ACTION: Norm to clarify "is needed" in 5.7.2 [recorded in http://www.w3.org/2009/05/28-xproc-minutes.html#action01]
Norm: Our new draft has been publish.
Adjourned.