Accept this agenda?

-> http://www.w3.org/XML/XProc/2012/01/05-agenda

Accepted.

Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2011/12/15-minutes.html

Accepted.

Next meeting: telcon, 12 January 2012.

No regrets heard.

Review of XML processor profiles

Norm summarizes. Questions about the diagram?

Jim: Vojtech suggested a small circle to represent XInclude in Full Profile.

Henry: I have reservations, could we see it first?

Norm: Any other questions or concerns before we publish?

None heard.

Norm: Here's what I propose: we agree to publish this as a new LC draft with an email decision this week on the diagram.

<jfuller> +1 to that

Norm: I propose a publication date of XXX next week, where XXX is whatever day of the week the team likes to publish on
... Let's see, LC drafts need to have a comment period. How long do we need?

Some discussion of the selection of colors for the diagram wrt various forms of color restricted vision.

Norm proposes 17 Febuary for the close of the LC comment period.

Norm: Any objections to publishing a new LC with a last call period ending on 17 February.
... Modulo details about the diagram.

No objections heard.

RESOLUTION: Publish new LC next week with LC period ending 17 Feburary.

-> http://www.w3.org/XML/XProc/docs/proc-profiles-test.svg

Discussion of the diagram

<jfuller> sending u a new diagram

Norm: Ok, I propose we use the new diagram, with a small editorial edition to the spec that describes what the inner purple circle means.

No objections heard.

Accepted.

XProc V.next discussions

Norm summarizes.

Norm: I tried to start a resource mgr discussion, but I like Vojtech's solution.

Henry: I don't
... What about the race condition?

Norm: We add a depends-on attribute to resolve that

Henry: Boy, I don't want to go there.
... I want the resource manager to handle something like the XQuery consistency constraint.
... Storing into the resource manager should be a distinct operation.

Norm: I think we've gone all the way around the house and got back to where we started.

Henry: Yeah.
... Is it obvious in the case that we're looking at [Vojtech's mail]...when I turn on that extension. Does it also do a PUT or not?

Vojtech: My idea in this case is that it wouldn't really store it, it just updates the resource manager cache.

Henry: Then the synchronization becomes a little easier. One way to do this is to use our own URI scheme.

Norm: I don't think that works, we want to tinker with URIs in existing documents.

Henry: Then you want an XML Catalog

Norm: No, because I don't necessarily know statically, in advance, what the URIs are.

Henry: We ought to be able to have a compound step which is "with catalog".

Vojtech: It could also be an attribute on steps that indicates if the output should be cached.

Henry: The idea is that there should be a general step that allows you to intercept GETs...

Alex: In 1.0 we have a statement about the (lack of) doc function consistency.
... I want to able to say "in this part of my pipeline, I want consistency"
... There are other issues about catalogs, side effect control, etc.
... They probably all interplay in some way.

Henry: I think we should adopt the XQuery rule.

Alex: It's not that quite that cut and dry. You need to be able to specify different consistency constraints in different parts of the pipeline.

Norm: Those two rules are directly contradictory.

Henry: Here's a back of an envelope design:
... We start with the story that the XQuery story holds. The first retrieval establishes a binding between a URI and a document and that binding is consistent/stable for the duration of the pipeline.
... We also have a lexically scoped URI binding mechanism.
... We want to avoid race conditions, so whatever we do we need to make statically scoped. It seems like it would be possible to use the notion of a "with-uri-bindings" compound step to not only allow you to map from one URI to another but also to require a refetch.
... To say that the story about consistency is reset and everyone within this scope has to do it all again.

Norm: I'm intrigued by the idea of having a catalog that applies for the duration of a compound step.

Henry: I want to keep caching and writing separate.

Alex: If you're binding in your catalog, then we have the feature of the ability to have URI named results, that are accessible by URI then your catalog does what you want.

Norm: If we said that cache:uri retrieved "uri" from the cache, then we could do it.
... It's not clear to me that it's practical to construct such a catalog dynamically in all cases.

Alex; I think there are two issues.

scribe: Catalogs map things to URIs.
... Then external to that, then you have the ability to say that these results have this name.
... Then you can have a catalog somewhere that points to an intermediary result.

Vojtech: We already say something about changing documents.
... In the valdation steps, for example, we say that documents passed to the step are used in favor of external documents with the same URIs.
... We need to make sure that these features interact well under these cases too.

Norm: I feel good about the progress we made. Exploring an explicit cache step and explicit catalog scoping seems like a good combination.
... Any closing thoughts before we run out of time.

Any other business

Norm: I would really appreciate any suggestions for how to structure the agendas to make progress on V.next

Jim: I think we need some principles to guide us on V.next.
... With an eye towards adoption and prioritizing in favor of outstanding user requests.
... And we should ask ourselves what type of V.next we're talking about.
... I would naturally think of it from a time point of view.
... If we say that V.next is 50% fixing what is broken and 50% usability, then that would be a useful thing to guide our discussions.
... And what about backwards-compatibility?

Adjourned.