See also: IRC log
We'll meet 6 March; any regrets? None heard
None progress reported
Norm: I sent a note to Michael, he expressed some continued reservations about some terminonology but said he'd take a closer look.
Jim: No progress.
... Zip and unzip are still in the same boat. Need a few hours to get them ready to present.
that's better right?
Talk amongst yourselves about the repeating with-option with parameters proposal.
Jim: On an initial reading, I like it.
Norm: It would work for things declared to be a map or a sequence; I think I like error for other cases.
Jim: For sequences, you'd get a
concatenation of the values.
... What about different values?
Vojtech: If we say concatenation, then we don't care; sequences can be heterogeneous.
Henry: The other choice would be
... How would you know a single element scalar is a sequence?
... Is that an error or is that an append
Norm: I think I'd do it by checking the type of the parameter.
Vojtech: I was assuming we'd have that kind of machinery
Henry: It makes better sense, but it's non-local and maybe not as ideal, but maybe it's the right thing.
Jim: Where does this fall in V.next?
Norm: In fixing parameters, I think
Vojtech: The proposal assumes we're adopting XDM.
Norm: I think we have agreed to adopt XDM.
<jfuller> +1 to XDM
<alexmilowski> A story with or without the option inheritance ?
Vojtech: The inheritance proposal gets rid of the parameter story altogether, and works for any kind of option.
Henry: Why do I look at variables when I'm looking for options?
Vojtech: They share the same scope. There's no shadowing.
Henry: Variables shadow.
Vojtech: They are in the same "bag".
Norm: A reference to $foo can be either an in-scope variable or an in-scope option.
Henry: Telling people that options take their bindings from variables is too confusing.
Vojtech: I'm not saying that, it's the other way around, variables can get their bindings from options.
Henry: But the proposal says you can take option bindings from variables.
Vojtech describes an example using p:xslt that inherits the version attribute from an outer scope.
Vojtech: If you have option or
variable you can say wether it propagates down and that's
... By that I mean that somewhere down below, there's an unbound option, it inherits from above.
... The second proposal was to allow p:with-option to be repeated so that we can provide the functionality of p:with-param.
... It's not the same, but you can do more or less the same things.
... It also applies to other options, not just to parameters.
Jim: Syntactically, it says "type=". Have we proposed that?
Vojtech: No, I just copied it.
Norm: I think it has to be "as=" to be consistent with XSLT and XQuery
Alex: I like this proposal, but I think there's an opportunity here to make variables/options/parameters language much clearer.
<ht> +1 -- I think we need to see if we can unify all three
Jim: I agree. It would be nice to
conflate these things.
... Were there proposals to have only one?
Alex: I think variables came later.
Jim: Options are the top level.
<ht> I find this pair of sentences: "Variables and options share the same scope and may shadow each other"; "It is a static error (err:XS0004) if an option or variable declaration duplicates the name of any other option or variable in the same environment. That is, no option or variable may lexically shadow another option or variable with the same name."
<ht> Confusing at best, contradictory at worst
ht, I think the salient point in the second sentence is "same environment"
<Vojtech> There is even a test, I think, that checks that shadowing is not allowed
<ht> But variables inherit through the environment. . .
<scribe> ACTION: Norm to review variable/option scope/shadow language and test cases [recorded in http://www.w3.org/2013/02/20-xproc-minutes.html#action01]
Vojtech: Optional options are also a problem.
Vojtech: Right now you have to write a huge choose and duplicate a bunch of stuff.
<ht> Need to go look at simple functional languages in this regard, e.g. scheme. . .
Alex: We need to collect together all the things we're trying to solve here with a short description.
Jim: We have a few option-related proposals on the table.
<ht> At the very least, I'd like to see if we can do the "only way to bind is to call a function" pure functional thing, and then describe everything else as syntactic sugar
<ht> [which is the case for scheme, e.g.]
Norm: I'll try to get the chair to pull together a list as a starting point.
Jim: I've stepped away from it a bit. In my mind it can just be an implementation detail.
Norm: I think we'd need some syntax for it.
Jim: But where we specify that
syntax doesn't necessarily have to be in the core of
... What makes document metadata attractive to me is workflow without having to change your source.
... Something like state control markup language.
Nothing new to be said.
Henry: I want a 30 second report on XProc day at XML Prague.
Jim: I hadn't pushed XProcathon
... I just wanted to get hard core folks in the room and test the temperature of the community.
... I think there were 40-45 people in the room.
... And there was a lot of passion in the room.
Norm: And all but one or two of them were using XProc. Not just curiuos onlookers.
Jim: There was a lot of interest
in simplification and ease of use.
... I had a lot of personal conversations from that meeting that were pretty exciting.
<alexmilowski> Don't forget the cocoon user ...
<ht> I agree the GUI line is not for a standard
Some discussion of the role of GUIs in ease of use.
<ht> But a 'higher-level' XProc that compiles into actual XProc might be a possibility. . .
Some discussion of the role of tutorials and user guides.
Alex: There was also a question
of annotations and standardizing them.
... But there's nothing stopping you from doing that today, so go do that.
... There were neat ideas, but not all of them were about things we needed to do.
<ht> We did, back in 2002, plan that the customer-facing version of the Markup Technology pipeline language would be visual. . .
<ht> I might try to drag out some of our old story boards
Jim: There were two things to me:
some exasperation and need for ease of use improvements, and
then a bunch of folks using it for things I hadn't thought
... People are using it in production.
Alex: It was a full room, there are real users.
Jim: In the conference sessions, there was a tremendous variety of use cases for XProc, from things like farming to DAISY
<alexmilowski> One power user in the WG could be interesting.