See also: IRC log
-> http://www.w3.org/XML/XProc/2007/04/05-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/03/29-minutes.html
Accepted.
No regrets given.
Was published today!
Norm: So caching is the problem of referring by URI in one component to an output of a previous component.
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.
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.
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.
None.
Adjourned.