- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Thu, 05 Apr 2007 12:00:49 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <87fy7e4xqm.fsf@nwalsh.com>
See: http://www.w3.org/XML/XProc/2007/04/05-minutes.html
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 62, 5 Apr 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Richard, Paul, Norm, Alessandro, Alex, Moz [on IRC]
Regrets
Henry, Rui, Mohamed
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 12 Apr 2007
4. 5 Apr 2007 WD
5. Caching
6. Dependency managentment.
7. Review of the step library
8. Any other business?
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2007/04/05-agenda.html
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2007/03/29-minutes.html
Accepted.
Next meeting: telcon 12 Apr 2007
No regrets given.
5 Apr 2007 WD
Was published today!
Caching
Norm: So caching is the problem of referring by URI in one component to an
output of a previous component.
->
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Mar/0205.html
Norm: There were follow-on messages, Henry proposed a caching scheme and
Mohamed proposed p:map
Richard: I would like to be able to implement XProc in a system where
components were implemented as completely independent external programs.
... As a consequence, it'd be impossible to do any sort of caching.
Norm: That strategy may have trouble with some pipelines.
Richard: For protocols in general, it may even be the case that different
requests at different times will get different results.
Norm: The alternative that got us back into this discussion was the
Xinclude-with-sequence component.
... I don't think that's a practical answer.
Some discussion of the possibilities
Richard: What is the circumstance that causes an output to appear at a URI
if there's no serializing component.
Norm: I was thinking that your implementation of XSLT with extensions
would write them to disk
Richard: Are you supposed to use http: URIs for local caching?
Alex: Browsers cache all the time.
... What happens to the base URI of a document when it goes through
XInclude.
Richard: I agree that the base URI can be anything you like, but I've
never before encountered a situation where other processes would see that.
Alex: What if we had a way to hook up a sequence to arbitrary steps to say
that this is the set of known documents.
Richard: You shouldn't use http to refer to the the things in there.
Norm outlines the include/import case which motivates caching.
Richard: I don't have any problem with URIs that are private to a
pipeline, but I don't think they should use http: URIs.
... It seems to me that's an abuse of http:
<alexmilowski> That battle has been lost as http uris are used for
namespaces all the time...
Richard: The use of http: URIs for namespace doesn't bear on this because
they don't get dereferenced. They're just strings.
... Here you're proposing a mechanism that does a GET but gets a different
result.
Alessandro: I agree with Richard. But if you use another component that
might help.
Richard: I think file: URIs are the way that you'd do this. You'd put it
in a temporary file and refer to that.
... Either you have to reuse filenames or make up filenames, so file: URIs
aren't perfect.
... I can see that there might be objections from others on the basis that
this isn't how the web is supposed to work.
Alex: Does this mean that if you changed the base URI of the document, you
could avoid the problem?
... You fabricate an identifier, id:1234, then it's no longer retrievable
therefore it's cacheable.
... Since it's not retrievable then it's not a problem.
Richard: That doesn't help me because I can't use those URIs in external,
unmodifiable components.
Alex: For caching to work, then we need a way for people to order things.
Norm: There was strong resistance on the list to any sort of dependency
support and I don't see any consensus being acheived on the caching issue.
Alex: I'm not a fan of caching.
... I don't want to be in a situation where arbitrary things can pull
documents from a cache so that I have to store everything.
Richard: I don't think the caching solution is a good solution anyway.
What we have here is the temporary file problem. Having fixed names
doesn't work.
... Suppose there's a subpipeline that works by constructing a partial
stylesheet or something. Now if you use that module twice, you'll have a
conflict.
... Programming libraries usually do this with dynamic names, but that's
inconvenient in cases like XInclude.
Norm: I don't think we're making progress towards an answer. Without a
good proposal on the table, we should probably move on.
... Is there anyone that wants to continue discussing the caching issue?
Richard: If we can't come to a conclusion about it, we ought to produce a
list of use cases that seem to require it. That way we have something to
test future solutions against.
Norm: I think the XInclude/XSLT import/Schema include use case is the only
one I can think of. Richard's observation of the problems of multiple
inclusions of the same subpipeline is an interesting wrinkle.
<richard> moz - I suppose a scoped catalog mechanism might work for
multiple instances
Norm: Given a component that can produce a URI for a local file and
another component that can replace attribute values, you can probably work
around this situation.
Alex: You may also be able to work around it with the p:insert component.
Possibly.
Norm: I propose that caching is dead.
Dependency managentment.
Norm: I propose dependency management is dead. We can abdicate
responsibility for side-effects in V1.
Alex: You can also use p:group and a funky parameter to force the order.
Review of the step library
Alex: We went through the list last time.
Alex summarizes his current work queue from last time.
Alex: there's a question about non-XML syntaxes for RELAX
<MoZ> yes
Norm: I'd like to find some way to start a discussion of the component
input and output vocabularies.
<MoZ> and for XQuery also
Norm: We have specialized input/output vocabularies for store, XSL-FO, and
httpRequest.
Alex: XQuery also has one.
... The httpRequest component is most odd. Most other components consume
things described in other specifications.
Norm: I think it's going to be useful, so I don't want to remove it.
Alex: It is underspecified.
Norm: Can you please start to fully specify it.
Alex: Yes.
... I should also put the XQuery input into our own namespace.
... Can we make the micro-operations optional?
Norm: That's not interoperable, I'd rather make them all required.
No one objects, so that's what Alex will do.
Any other business?
None.
Adjourned.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/03/22-agenda.html
[3] http://www.w3.org/2007/04/05-xproc-irc
[7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[8] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[7] version 1.128 (CVS
log[8])
$Date: 2007/04/05 15:59:01 $
Received on Thursday, 5 April 2007 16:01:00 UTC