XML Processing Model WG

Meeting 156, 15 Oct 2009


See also: IRC log


Paul, Norm, Vojtech, Mohamed, Alex


Accept this agenda?

-> http://www.w3.org/XML/XProc/2009/10/15-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2009/10/08-minutes


Next meeting: telcon 22 Oct 2009

No regrets heard.

Paul gives regrets for 29 Oct

W3C Technical Plenary

Expected: Norm, Henry, Alex, Vojtech, correct?

Norm: I believe I requested a phone, we'll hook up Zakim for you if we can.

Alex gives regrets for TPAC after all

Versioning and forwards compatibility

-> http://www.w3.org/XML/XProc/2008/11/cr-comments/

Norm attempts to summarize where we stand.

Norm: The status quo allows very limited forwards-compatibility and only if new step declarations are loaded from the W3C server.
... You can't just load a V2 pipeline in a V1 processor and expect it to work.
... The desire has been expressed, from several camps, to provide a more flexible story.
... They want something that will "just work"
... And the ability to use p:choose to select between two different flavors of pipeline, for V1 or V2.
... And they don't want to have to hit the W3C web server for new decls to make it work.
... The last point to make is, if you don't do versioning "right" in V1, it's very hard to get it right later.
... Do we care? Are we going to try to address this in V1?

No one is heard to argue for the status quo.

Mohamed: Let's go as far as possible in the investigation since this is the last chance. But at the end, perhaps we'll stick to the status quo.

<ht> +1 to MoZ

Norm: I think the proposals boil down to two camps:

1. Some sort of defaulting rules for what to do when you see steps/ports in the p: namespace that you don't recognize.

2. Some sort of static manipulation like XSLT's use-when

Norm attempts to summarize the two flavors.

Norm: Thoughts?
... Comments?

Alex: Thinking about Norm's proposal for empty sequence on output.

Norm: One weakness of my proposal is that it requires you to have the 2.0 declarations.

<ht> As I said in email, I find Jeni's critique of that [being online] compelling

Alex: The 1.0 processor isn't going to do the right thing...

Vojtech: If we introduce defaulting that can work without the declarations, then we have to be a lot more relaxed about static errors.

<ht> That's why I prefer the use-when approach

Alex: If you're trying to do this, the onus on the 1.0 processor is that it has to go retrieve the stuff.

Norm: I'm (mostly) convinced by the offline arguments.
... The reality is, I think the use-when approach is the most practical. It balances ignoring things with user-control.
... It's the C preprocessor.

Vojtech: Does this solve what we want to solve?
... This is really the forwards-compatible mode. When you evaluate these use-when conditions, you wind up with some sort of pipeline.

Alex: One interpretation is that we have this static view and we're trying to adjust that. The other is that the data flow graph is the same in both situations, but what the steps can do is different.
... In the case where you produce an empty sequence, you can still hook things up.

Norm: Right. If you have the declarations.

Norm natters on about the need to have declarations.

Norm points out that the user community that wants us to fix this isn't going to be happy with the need to load declaratins.

Alex: I'm not against the use-when approach.

Norm wonders out loud about the requirement to use use-when; or can we have p:when that contains a step we don't recognize and still "compile" the pipeline.

Alex: I don't think use-when is as simple as it is in the case of XSLT.

Norm: And does this really solve the backwards compability problem? If you throw a random V2 pipeline at a V1 processor, what will it do?
... If a pipeline uses a V2 step unconditionally, there's nothing a V1 processor can do with it.
... So if an author wants to write a pipeline that can run in V1, he or she will have to use some sort of conditionality.

Mohamed: My understanding is that we have three levels:
...1: mandate importing of step decls; without them then there are two levels:
...1a: primary ports
...1b: secondary ports
... My understanding is that only primary ports could be connected automatically.

Norm: Right.

Mohamed: So I think the lack of information that we have to compute the graph dependencies is only on primary ports.

Norm: Right.

Mohamed: On one branch, we say that a new primary port can never be added in V.next.
... Or, we say that if you add some primary port then we say that you have to make the connection explicit if you want to run it in V1.

Vojtech: This is only about existing steps, not about new steps.

Norm: True

Mohamed: The same could be true for new steps, you have to make all the bindings explicit.

Norm: So if you see a new step, you assume that it has no primary inputs or outputs.

Mohamed: Yes.

Norm: Interesting.

Mohamed: As soon as we say that we don't want the user to import the step declarations, then the user will have to put new information into the pipeline to make it work in V1.

Vojtech: For new V2 things that have have inputs like "iteration-source" that aren't recognized, then the pipeline will just fail.

More discussion.

Mohamed: The only point of my proposal is that it moves the entire static validation into dynamic when you have p:choose or p:try

More discussion

Norm talks through the "propagate errors up" story again.

Mohamed observes that we have to support p:choose/p:try dynamically.

Vojtech: We have to decide if a new messages output port on p:xslt should work or should be a failure.
... I don't think we can really solve this.

Alex: I'm having trouble following the different situations we want to handle.

Norm: Is there consensus to explore a radical solution that involves defaulting, use-when, and the other mechanisms that we've discussed here?

Proposal: Norm to attempt to write this up?

<ht> Yes


<ht> Willing to help

Norm: I think the solution has these general features:

1. Remove the requirement to load step declarations

2. Add use-when to allow authors to be explicitly dynamic

3. Add some defaulting rules to allow for dynamic selection (p:choose) of steps from different versions. (p:identity vs. p:identity-with-colors)

4. Add a version attribute to identify when forwards compatible behavior is required

Norm: I don't want a V1 processor running a pipeline that it thinks is a V1 pipeline to be unable to statically reject broken pipelines.
... I suppose we could require a version attribute, like XSLT does.

Any other business?

ht, can you send email reminding us how short LC and CR are allowed to be?


<ht> Will do

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/10/15 16:07:59 $