See also: IRC log
-> http://www.w3.org/XML/XProc/2014/03/05-agenda
Accepted
Norm: Except there aren't any
No regrets given
Norm: I want to do a few bugs each week.
-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21015
<jfuller> view source on http://tests.xproc.org/tests/required/err-d0026-004.xml
Norm: I think Tim's right. If you
never need to evaluate $var, then you may never get the
error
... I propose to rewrite the test so that $var is needed.
Vojtech: We say that the names and values are added to the environment; I guess that doesn't preclude lazy evaluation but i guess it depends how you read that.
Norm: I don't think we want to forbid lazy eval.
Vojtech: I agree.
Norm: Any objections to my proposal?
None heard.
-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21035
Norm: I think we added XD0030 as an escape hatch; we don't want to forbid steps from giving more specific errors
Jim: Is he saying that other errors should be bubbling up instead?
Norm: I think Tim thinks that errors should be consistent across impls; we don't say that.
Norm proposes:
The WG's position has been that errors do not have to be consistent across implementations; that was viewed as too large a burden to impose. The spec, alas, appears not to say that anywhere. We'll fix that.
The error XD0030 is a "standard" escape hatch for errors that don't have a more specific error code. Impls are free to provide more specific/better error codes. We suggest such codes for some errors in some steps.
<jfuller> we have http://tests.xproc.org/tests/required/err-d0030-001.xml
<jfuller> and
<jfuller> http://tests.xproc.org/tests/required/err-d0030-002.xml
Norm: Anyone unhappy with my comment?
Jim: To be clear: if we have no support for the xsl formatter step, and this step runs, we want an XD0030
Vojtech: No, there's a different error for "unsupported atomic step"
Norm: Both of those tests are bogus
Vojtech: Another thing that Tim
mentions in that bug is that he would like to be able to catch
a specific XQuery error code.
... We don't provide that.
Norm: You only get one catch bucket in V1 but you can test for the error you got.
Vojtech: But the errors are implementation defined.
Norm: Yes. Well, mostly. We
specify a few errors.
... We could have done better.
... Maybe we can do better in Vnext
Vojtech: Maybe we can make well defined error codes more visible.
Norm: Are we happy with my comment?
No objections heard.
<jfuller> +1 to Norm's comment
Norm asks about the parameters proposal
Vojtech: It took me a while to
understand it. Maybe I still don't completely understand it. My
feeling is that if you depend on third party pipelines, you're
limited by what they provide.
... Even if it's hidden to you as a top level consumer, you
still have to learn about that.
... My main worry is that you'll end up in a situation that's a
mess.
... On the other hand, I like other things about it a lot. It
simplifies a lot of things.
... The pipeline doesn't declare any of the parameter maps that
it expects.
Norm: I think an empty parameter map is always an option
Vojtech: Suppose that you don't
have any parameters, but you use a third party library that
runs XQuery or XSLT
... In V1, you know that the third party pipeline has three
parameter input ports and you know how they're used.
... In the current proposal, there's no way to declare that.
There's no contract.
... I as a user have no control over that.
... A simple pipeline that doesn't import anything, one that
runs a query, a stylesheet, and an XSL formatter. You may want
to pass different parameters to all of them.
Jim: I think this is a classic engineering balance question.
Vojtech: In V1, the parameters
are crazy to use but it's clean in the sense that it's
maintainable.
... A step declares what it expects. With this situation,
there's something going on that you have no control over. And
you can't work around it.
Alex: I hear two things: one is the ability to scope and control the parameters...
Vojtech: I think that's my main concern
Alex: ...and there's also the question of declaring the maps that get used.
Vojtech: You don't really know, you have to look at the source code. And at the source code of all the imported pipelines.
Some discussion of how steps get parameters.
Alex: My concern is that we're going to have to eventually say that parameter maps are in the context and you're not supposed to use them.
Norm: They're in the pipeline's context, not the step context. The pipeline knows lots of things that the steps can't see.
Vojtech: We're throwing away any kind of scoping.
Norm: Yep.
Alex: That's the other issue.
Somewhere deep within the pipeline you're importing, there's a
reference to the default parameter map. You can't override that
when you call it.
... That's the concern.
... I want to be able to say "at this point, new scope, I don't
want any parameters."
Norm: Maybe we need some way to deal with that.
Henry: I don't want to go there
until I see a real use case. We've perfectly reasonably circled
back around to where we were about 3/4 of the way through the
discussion in Edinburgh.
... I agree that in principle, you could get into trouble, but
I'd like to see a practical use case. I don't think we need
it.
Alex: I'm on the fence, I think we should be aware that it's something we can't do.
Norm: Fair enough, the spec for this certainly should make clear what it's deficiencies are.
Alex: The analogous case for code
is I write a library that uses a global variable and bad things
happen. Don't do that. Could you say that's a poorly written
library? Possibly.
... If you don't want magic, then you have to make explicit
calls.
Vojtech: Maybe there's a story that's in between. There's some magic in the pipeline, but at the step boundaries there isn't.
Norm: There's nothing that
prevents a pipeline author from doing better.
... You can control all the parameters, what you don't get is
after-the-fact control over a third party pipeline that wasn't
written carefully.
Alex: Unintended things can
happen if you use a library that was written carelessly.
... that's just a fact of life.
Vojtech: Since we're adopting the
map type, and we will have AVTs. Why do we need to have this
mechanism at all?
... If you want to pass parameters, just use options that are
maps.
Some discussion of other mechanisms
Jim: The main reasons why we have a difference today is that because we might not know the name.
Vojtech: Yes, but maps solve that problem.
None heard.
Adjourned.