XML Processing Model WG

Meeting 62, 5 Apr 2007


See also: IRC log


Richard, Paul, Norm, Alessandro, Alex, Moz [on IRC]
Henry, Rui, Mohamed


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/04/05-agenda.html


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/03/29-minutes.html


Next meeting: telcon 12 Apr 2007

No regrets given.

5 Apr 2007 WD

Was published today!


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?



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/04/12 16:26:39 $