See also: IRC log
No regrets heard.
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?
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
... Modulo details about the diagram.
No objections heard.
RESOLUTION: Publish new LC next week with LC period ending 17 Feburary.
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.
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
... 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.
... 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
... 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
... 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.
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?