- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 05 Jan 2012 11:52:03 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2ipkqhz2k.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2012/01/05-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 205, 05 Jan 2012
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Jim, Henry, Cornelia, Vojtech, Alex
Regrets
Paul
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon, 12 January 2012.
4. [8]Review of XML processor profiles
5. [9]XProc V.next discussions
6. [10]Any other business
* [11]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [12]http://www.w3.org/XML/XProc/2012/01/05-agenda
Accepted.
Accept minutes from the previous meeting?
-> [13]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.
-> [14]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.
Summary of Action Items
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [15]scribe.perl version 1.136 ([16]CVS
log)
$Date: 2012/01/05 16:50:54 $
References
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2012/01/05-agenda
3. http://www.w3.org/2012/01/05-xproc-irc
4. http://www.w3.org/XML/XProc/2012/01/05-minutes#agenda
5. http://www.w3.org/XML/XProc/2012/01/05-minutes#item01
6. http://www.w3.org/XML/XProc/2012/01/05-minutes#item02
7. http://www.w3.org/XML/XProc/2012/01/05-minutes#item03
8. http://www.w3.org/XML/XProc/2012/01/05-minutes#item04
9. http://www.w3.org/XML/XProc/2012/01/05-minutes#item05
10. http://www.w3.org/XML/XProc/2012/01/05-minutes#item06
11. http://www.w3.org/XML/XProc/2012/01/05-minutes#ActionSummary
12. http://www.w3.org/XML/XProc/2012/01/05-agenda
13. http://www.w3.org/XML/XProc/2011/12/15-minutes.html
14. http://www.w3.org/XML/XProc/docs/proc-profiles-test.svg
15. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
16. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 5 January 2012 16:52:33 UTC