W3C

- DRAFT -

XML Processing Model WG

Meeting 227, 20 Feb 2013

Agenda

See also: IRC log

Attendees

Present
Norm, Jim, Vojtech, Henry, Alex
Regrets
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

-> http://www.w3.org/XML/XProc/2013/02/20-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2013/01/31-minutes

Accepted.

Next meeting: 27 Feb 2013? 6 Mar 2013?

We'll meet 6 March; any regrets? None heard

Review of open actions

None progress reported

Update on processor profiles

Norm: I sent a note to Michael, he expressed some continued reservations about some terminonology but said he'd take a closer look.

Use cases and requirements

Jim: No progress.
... Zip and unzip are still in the same boat. Need a few hours to get them ready to present.

Option inheritance

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2013Feb/0002.html

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 error.
... 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.

no worries

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2013Jan/0022.html

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 it.
... 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.

Alex: Right.

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.

Document metadata

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 v.next
... What makes document metadata attractive to me is workflow without having to change your source.
... Something like state control markup language.

Non-XML documents

Nothing new to be said.

Any other business?

Henry: I want a 30 second report on XProc day at XML Prague.

yes, please

Jim: I hadn't pushed XProcathon that hard.
... 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. . .

<jfuller> http://sharexml.com/

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 of.
... 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.

Adjourned

Summary of Action Items

[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/03/05 16:15:05 $