W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2007

XProc Minutes 5 Apr 2007

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


                                   - DRAFT -

                            XML Processing Model WG

Meeting 62, 5 Apr 2007


   See also: IRC log[3]


           Richard, Paul, Norm, Alessandro, Alex, Moz [on IRC]

           Henry, Rui, Mohamed




     * 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


  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.


   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

   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

   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
   ... 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.

   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

   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]


   [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
    $Date: 2007/04/05 15:59:01 $

Received on Thursday, 5 April 2007 16:01:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:42 UTC