IRC log of xproc on 2006-04-27
Timestamps are in UTC.
- 15:00:48 [RRSAgent]
- RRSAgent has joined #xproc
- 15:00:48 [RRSAgent]
- logging to http://www.w3.org/2006/04/27-xproc-irc
- 15:00:48 [Zakim]
- ok, Norm; that matches XML_PMWG()11:00AM
- 15:00:56 [richard]
- zakim, ? is richard
- 15:00:56 [Zakim]
- +richard; got it
- 15:01:11 [Norm]
- Norm has joined #xproc
- 15:01:23 [Norm]
- zakim, who's on the phone?
- 15:01:23 [Zakim]
- On the phone I see Alex_Milowski, Alessandro_Vernet, Norm, PGrosso, richard
- 15:02:25 [Norm]
- Meeting: XML Processing Model WG
- 15:02:25 [Norm]
- Scribe: Norm
- 15:02:25 [Norm]
- ScribeNick: Norm
- 15:02:25 [Norm]
- Date: 27 Apr 2006
- 15:02:25 [Norm]
- Chair: Norm
- 15:02:26 [Norm]
- Agenda: http://www.w3.org/XML/XProc/2006/04/27-agenda.html
- 15:02:32 [Zakim]
- +MoZ
- 15:02:42 [Norm]
- zakim, who's on the phone?
- 15:02:42 [Zakim]
- On the phone I see Alex_Milowski, Alessandro_Vernet, Norm, PGrosso, richard, MoZ
- 15:03:07 [Norm]
- MSM?
- 15:03:46 [Norm]
- zakim, who's talking
- 15:03:46 [Zakim]
- I don't understand 'who's talking', Norm
- 15:03:50 [MSM]
- zakim, please call Micahel-Office
- 15:03:50 [Zakim]
- I am sorry, MSM; I do not know a number for Micahel-Office
- 15:03:52 [Norm]
- zakim, who's talking?
- 15:03:56 [MoZ]
- Zakim, mute me
- 15:03:56 [Zakim]
- MoZ should now be muted
- 15:04:02 [Zakim]
- Norm, listening for 10 seconds I heard sound from the following: Norm (90%), MoZ (15%)
- 15:04:07 [ht]
- zakim, please call ht-781
- 15:04:07 [Zakim]
- ok, ht; the call is being made
- 15:04:09 [Zakim]
- +Ht
- 15:04:09 [MSM]
- zakim, please call Michael-Office
- 15:04:09 [Zakim]
- ok, MSM; the call is being made
- 15:04:11 [Zakim]
- +Michael
- 15:04:54 [MSM]
- zakim does time-sharing?
- 15:05:02 [Norm]
- zakim, who's on the phone?
- 15:05:02 [Zakim]
- On the phone I see Alex_Milowski, Alessandro_Vernet, Norm, PGrosso, richard, MoZ (muted), Ht, Michael
- 15:05:31 [MSM]
- I *believe* it means that Z heard input from Norm during 90% of its time slices, and from MoZ during 15% of them
- 15:05:44 [Norm]
- Present: Alex, Alessandro, Norm, Paul, Richard, Mohamed, Henry, Michael
- 15:05:49 [Norm]
- Regrets: Murray, Andrew
- 15:05:55 [Norm]
- Topic: Accept this agenda?
- 15:05:55 [Norm]
- -> http://www.w3.org/XML/XProc/2006/04/27-agenda.html
- 15:06:05 [Norm]
- Accepted
- 15:06:08 [Norm]
- Topic: Accept minutes from the previous teleconference?
- 15:06:08 [Norm]
- -> http://www.w3.org/XML/XProc/2006/04/20-minutes.html
- 15:06:17 [Norm]
- Accepted
- 15:06:18 [Norm]
- Topic: Next meeting: 4 May telcon
- 15:06:18 [Norm]
- Any regrets?
- 15:06:29 [MoZ]
- yes
- 15:06:53 [MoZ]
- yes
- 15:07:27 [MoZ]
- Zakim, unmute me
- 15:07:27 [Zakim]
- MoZ should no longer be muted
- 15:07:37 [Norm]
- Face-to-face meeting?
- 15:08:06 [Norm]
- Registration page: http://www.w3.org/2002/09/wbs/38398/XProcFTF2/
- 15:08:47 [Norm]
- Topic: Issue 3096: Are components side-effect free?
- 15:08:47 [Norm]
- -> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3096
- 15:09:55 [Norm]
- Norm proposes:
- 15:09:56 [Norm]
- I propose that we say that all components are non-functional. That is,
- 15:09:56 [Norm]
- a pipeline implementation must behave as if it evaluated a component
- 15:09:56 [Norm]
- every time it occurs. "Must behave as if" is spec-ease for
- 15:09:56 [Norm]
- "implementations that are clever enough to determine with certainty
- 15:09:56 [Norm]
- that a component is, in fact, functional are free to cache the
- 15:09:58 [Norm]
- intermediate results because by golly if it is, no one will be able to
- 15:10:41 [Norm]
- Richard: This doesn't preclude adding a mechanism later to allow authors to assert that a step or component is functional
- 15:10:45 [Norm]
- Norm: Yes.
- 15:11:24 [Zakim]
- -Alessandro_Vernet
- 15:11:47 [Norm]
- Richard: Does this address the converse case? Producing output side-effects and behaving the same way for given inputs
- 15:12:12 [Zakim]
- +Alessandro_Vernet
- 15:12:46 [Norm]
- Norm: This is the "functional" aspect, not the side-effect aspect
- 15:13:01 [Norm]
- Richard: Side-effects are like hidden outputs, functionality is like hidden inpus
- 15:13:04 [Norm]
- s/inpus/inputs/
- 15:14:09 [Norm]
- Alex: This is a good place to start, register a new issue about functional components?
- 15:14:21 [Norm]
- ACTION: Alex to create such an issue
- 15:14:42 [Norm]
- s/such an issue/an issue about the possibility of functional components/
- 15:15:00 [Norm]
- Proposal accepted.
- 15:15:11 [Norm]
- Issue 3113: Are components side-effect free?
- 15:15:11 [Norm]
- -> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3113
- 15:15:25 [Norm]
- s/Are components side-effect free?/Does the pipeline engine act as a resource manager?
- 15:16:10 [Norm]
- Norm: One aspect of this question is, does the pipeline engine provide the sort of URI-stability that XSLT, for example, gives the document function
- 15:16:56 [Norm]
- Richard: I strongly disagree with this as a requirement; it requires a degree of intimacy between the engine and the components that may not always be available
- 15:16:59 [Zakim]
- +Murray_Maloney
- 15:17:17 [Norm]
- Alex: Is this something that might be "at user option"
- 15:17:41 [Norm]
- Norm: I'd like to avoid that if at all possible
- 15:17:44 [ht]
- q+ to push back
- 15:18:00 [Norm]
- ack ht
- 15:18:00 [Zakim]
- ht, you wanted to push back
- 15:18:23 [Norm]
- Henry: I need some information; in my current state of knowledge I think it's a bad idea for pipeline engines
- 15:18:33 [Alessandro]
- Alessandro has joined #xproc
- 15:18:55 [Norm]
- Henry: Especially when you are running a pipeline engine as a server, you do not want to flush the cache everytime you run a pipe because it's useful to keep things around.
- 15:19:10 [Norm]
- Henry: In their parsed and ready-to-go state (provided they haven't changed)
- 15:19:47 [Alessandro]
- Alessandro has joined #xproc
- 15:19:53 [Norm]
- Henry: I'm happier saying, "no, you should expect your pipeline to behave in the way of any other web application does"
- 15:19:57 [Norm]
- Henry: Yes, things can change.
- 15:20:41 [Norm]
- Alex: If we step back and look at the web browser case, consider an image embedded 10 times on the page. The browser reuses the image.
- 15:20:55 [Norm]
- s/the page/the same page/
- 15:21:23 [Norm]
- Alex: The resolution of URI-to-resource is stable for the duration of a page is one reasonable expectation
- 15:21:48 [MSM]
- [I think the fact that browser do or do not re-fetch is an optimization they make, not part of the specification of correct browser behavior - am I wrong?]
- 15:22:27 [Norm]
- Richard: consider other things like XML pipelines, like shell scripts, where "cat foo" twice might not return the same file.
- 15:22:48 [MSM]
- [If ten <img> elements in the same HTML document refer to "my_image.jpg", and that image is served with a lifetime of 0, are correct browsers guaranteed to fetch it only once? What spec says that?]
- 15:23:29 [Norm]
- Some discussion of whether or not browsers actually behave that way
- 15:23:53 [Norm]
- q+ Murray
- 15:23:54 [MSM]
- q+ to say that as an empirical statement, it's not a very strong argument for making the behavior part of our spec
- 15:23:58 [Norm]
- ack msm
- 15:23:58 [Zakim]
- MSM, you wanted to say that as an empirical statement, it's not a very strong argument for making the behavior part of our spec
- 15:24:43 [Norm]
- MSM: Implementors will do that for performance reasons regardless of whether a spec requires it or not
- 15:24:54 [Norm]
- Richard: Is there a spec for how you display things in a web page?
- 15:24:56 [Norm]
- Alex: No
- 15:25:06 [Norm]
- MSM: In that sense, it's not clear to me that the browser analogy bears on our decision
- 15:25:20 [Norm]
- Alex: There's a user expectation of some aspect of stability
- 15:26:05 [Norm]
- Richard: I don't think the browser analogy is a good one. The engine is running a collection of potentially independently implemented components.
- 15:26:09 [Norm]
- ack Murray
- 15:26:47 [Norm]
- Murray: I'm relying on my memory, but in HTTP there's a mechanism for specifying time-to-live. So if there's a nano-second TTL, then maybe it would go get the resource again.
- 15:27:17 [Norm]
- Murray: Similarly, if I was getting the time of day from a URI then it might change
- 15:27:29 [Norm]
- Murray: So if you're worried about that, maybe you need a "caching" component.
- 15:27:39 [alexmilowski]
- q+
- 15:28:43 [Norm]
- ack Alessandro
- 15:28:45 [Norm]
- ack alexmilowski
- 15:29:04 [Norm]
- Norm: I think consensus is coming towards the answer "no"
- 15:29:18 [Norm]
- Alex: I don't agree, I think it's important that URIs are stable for the duration of an execution
- 15:29:28 [Zakim]
- -Michael
- 15:29:49 [Norm]
- Alex: If you need to identify unique resources, you can generate unique URIs with query parameters
- 15:30:15 [Norm]
- Alex: We haven't decided if the resources flowing through the pipeline have URIs or not
- 15:30:18 [richard]
- q+
- 15:30:19 [MSM]
- zakim, please call Michael-Office
- 15:30:19 [Zakim]
- ok, MSM; the call is being made
- 15:30:20 [Zakim]
- +Michael
- 15:30:27 [Norm]
- ack richard
- 15:30:53 [Norm]
- Richard: I notice that the bug is actually talking about something produced by the pipeline
- 15:31:35 [Norm]
- Norm: I think those are the same case
- 15:31:45 [Norm]
- Richard: You could provide components that fetch and store URIs stably.
- 15:34:18 [Norm]
- q+ Murray
- 15:34:37 [Norm]
- Norm describes the situation where an XSLT needs to get an ancillary resource by URI
- 15:35:02 [Norm]
- Alex: I really want some URIs to be stable throughout the duration of a pipeline
- 15:35:14 [Norm]
- ack murray
- 15:35:23 [Norm]
- Murray: I'm not convinced that we don't need a resource manager
- 15:35:47 [Norm]
- Murray: I'd like to posit the existence of a component that is a proxy server or something of that ilk
- 15:36:14 [Norm]
- Murray: That component knows if requests should always send things back from the cache
- 15:37:00 [MSM]
- [I agree fervently that as users we need resource managers, and that implementations of our language will be more usable if they use good resource managers. But we also need character sets. We don't specify a character set as part of our spec to meet that need, and the same should probably hold for resource management. Separate problem, separate spec.]
- 15:37:12 [Norm]
- Murray: I think it's the case that sometimes you're going to want the documents to remain stable and sometimes you're going to want to get current results
- 15:37:15 [alexmilowski]
- yes!
- 15:38:06 [Norm]
- Richard: But I may be using components that don't know how to use a proxy server
- 15:38:54 [Norm]
- Murray: I thought once you setup a proxy, then all requests went through that proxy.
- 15:39:01 [Norm]
- That's implementation and operating-system dependent
- 15:40:24 [Norm]
- Richard: Proxies do give a degree of generality that seems nice
- 15:40:34 [MSM]
- q+
- 15:42:51 [Norm]
- ack msm
- 15:43:37 [Norm]
- MSM: I'm not sure I'm understanding everything going on here. I agree that being able to cache and being able to gaurantee up-to-date resources are good things
- 15:43:57 [Norm]
- MSM: But lots of these things seem to be not terribly closely related to pipelines any more than we need a character set.
- 15:44:15 [Norm]
- MSM: We just rely on getting character sets from lower layers.
- 15:44:47 [alexmilowski]
- q+
- 15:44:48 [Norm]
- MSM: Building it into the pipeline engine strikes me as a breach of orthogonality.
- 15:45:37 [Norm]
- MSM: At least for the components that we require an implmentation provide, we can say what the answers are or say that they're implementation defined
- 15:46:26 [Norm]
- Murray: I think you're thinking of it in terms of the pipeline language and not the overall processing model. If you're processing large volumes of XML, you may want a proxy server that has access to pipeline descriptions so that all your documents can be passed through.
- 15:46:55 [richard]
- Beware of assuming that everything comes through HTTP. What if they're just files?
- 15:47:14 [Norm]
- Indeed. The proxy has to handle file: URIs as well.
- 15:48:15 [Norm]
- MSM: It should be orthogonal. If I've got a caching proxy installed, I want my pipeline engine to use that one, not one that it felt it needed to build in.
- 15:48:28 [Norm]
- ack alexmilowski
- 15:49:05 [Norm]
- Alex: The document function in XSLT gets the resource through the local environment that might use a local cache
- 15:49:26 [richard]
- q+
- 15:49:38 [Norm]
- MSM: The only thing the XSLT language says is that if you call the document function with the same URI, you'll get the same document
- 15:49:58 [Norm]
- Alex: You want to be able to compare the objects you get back from the document function.
- 15:50:17 [Norm]
- Alex: Do we really have the requirement that things behave this way across components?
- 15:51:17 [Norm]
- ack richard
- 15:51:53 [Norm]
- Richard: I think that Alex has drawn attention to an important point. XSLT can do this because it only says the document function behaves this way.
- 15:52:11 [Norm]
- Richard: Are we really going to say that if the stylesheet is a file: URI then it can't just open it?
- 15:52:48 [Norm]
- Murray: In a shell script, you'd handle this by copying it and then referring to the copy.
- 15:53:08 [Norm]
- Richard: Yes, and if you were using a program that had the name hard coded, then you couldn't make it use the copy
- 15:53:58 [Norm]
- Norm attempts to summarize the consensus which remains "no"
- 15:54:11 [Norm]
- HT: The discussion we've had has been drawn somewhat more narrowly than the first sentenc of the actual issue.
- 15:54:56 [MSM]
- [I wonder if there is consensus on the proposition that in cases like the example given by Norm in raising the issue, it *is* our responsibility to say whether the data stream written to uri Foo is or is not guaranteed the same as the data stream (later) read from uri Foo]
- 15:55:17 [Norm]
- HT: We've discussed in the past the use of pipeline engines as resource managers.
- 15:55:30 [Norm]
- HT: Consider output="#foo" somewhere and input="#foo" somewhere else in a pipeline.
- 15:55:50 [Norm]
- HT: One way to think about that is that the engine is managing those resources.
- 15:56:04 [Norm]
- HT: I don't believe that issue is off the table because of this discussion
- 15:56:34 [Norm]
- Norm: I agree
- 15:56:50 [Alessandro]
- Alessandro has joined #xproc
- 15:57:52 [MSM]
- I'm a little puzzled / troubled here. If I interpret output="#foo" and input="#foo" as references to resources to be managed by the pipeline, then I suddenly have an ambiguity I didn't use to have:
- 15:58:07 [MSM]
- does the input stream read the ouptut stream?
- 15:58:22 [MSM]
- or is this a pipeline which reads resource #foo, does something with it, and writes it back?
- 15:59:25 [Norm]
- Scribe lost the thread
- 15:59:27 [MSM]
- ht, I wonder if you can expound on how you would propose avoiding this ambiguity
- 16:00:12 [ht]
- So I think Richard just expressed the dichotomy in an interesting way -- do we name ports, or infosets
- 16:00:36 [MSM]
- +1: Richard's formulation of the question is an acute one
- 16:00:53 [Norm]
- ADJOURNED
- 16:00:54 [Zakim]
- -Murray_Maloney
- 16:00:55 [Zakim]
- -Ht
- 16:00:57 [Zakim]
- -richard
- 16:00:58 [Zakim]
- -PGrosso
- 16:00:59 [Zakim]
- -Norm
- 16:01:00 [Zakim]
- -Alessandro_Vernet
- 16:01:01 [Zakim]
- -MoZ
- 16:01:02 [Zakim]
- -Alex_Milowski
- 16:01:03 [alexmilowski]
- alexmilowski has left #xproc
- 16:01:07 [Zakim]
- -Michael
- 16:01:08 [Zakim]
- XML_PMWG()11:00AM has ended
- 16:01:10 [Zakim]
- Attendees were Alex_Milowski, Alessandro_Vernet, Norm, PGrosso, richard, MoZ, Ht, Michael, Murray_Maloney
- 16:01:19 [Norm]
- rrsagent, set logs world-visible
- 16:01:36 [Norm]
- rrsagent, draft minutes
- 16:01:36 [RRSAgent]
- I have made the request to generate http://www.w3.org/2006/04/27-xproc-minutes.html Norm
- 16:04:55 [PGrosso]
- PGrosso has left #xproc
- 17:58:04 [Zakim]
- Zakim has left #xproc
- 20:12:23 [Norm]
- MSM?
- 20:12:29 [Norm]
- rrsagent, bye
- 20:12:29 [RRSAgent]
- I see 1 open action item saved in http://www.w3.org/2006/04/27-xproc-actions.rdf :
- 20:12:29 [RRSAgent]
- ACTION: Alex to create such an issue [1]
- 20:12:29 [RRSAgent]
- recorded in http://www.w3.org/2006/04/27-xproc-irc#T15-14-21