IRC log of xproc on 2007-03-22

Timestamps are in UTC.

14:44:58 [RRSAgent]
RRSAgent has joined #xproc
14:44:58 [RRSAgent]
logging to
14:45:16 [Norm]
Meeting: XML Processing Model WG
14:45:17 [Norm]
Date: 22 Mar 2007
14:45:17 [Norm]
14:45:17 [Norm]
Meeting number: 60, T-minus 32 weeks
14:45:17 [Norm]
Chair: Norm
14:45:17 [Norm]
Scribe: Norm
14:45:19 [Norm]
ScribeNick: Norm
14:58:04 [Zakim]
XML_PMWG()11:00AM has now started
14:58:11 [Zakim]
14:59:04 [Zakim]
14:59:39 [Norm]
zakim, who's on the phone
14:59:39 [Zakim]
I don't understand 'who's on the phone', Norm
14:59:42 [Norm]
zakim, who's on the phone?
14:59:42 [Zakim]
On the phone I see Norm, Murray_Maloney
15:01:03 [Andrew]
Andrew has joined #xproc
15:01:24 [Zakim]
15:01:45 [Zakim]
15:01:50 [Andrew]
zakim, ? is Andrew
15:01:50 [Zakim]
+Andrew; got it
15:02:47 [ht]
zakim, please call ht-781
15:02:47 [Zakim]
ok, ht; the call is being made
15:02:49 [Zakim]
15:04:36 [Norm]
zakim, who's on the phone?
15:04:36 [Zakim]
On the phone I see Norm, Murray_Maloney, Alessandro_Vernet, Andrew, Ht
15:05:14 [ht]
15:06:48 [Norm]
Present: Norm, Murray, Alessandro, Andrew, Henry
15:06:55 [Norm]
Topic: Accept this agenda?
15:06:55 [Norm]
15:06:59 [Norm]
15:07:03 [Norm]
Topic: Accept minutes from the previous meeting?
15:07:03 [Norm]
15:07:06 [Norm]
15:07:11 [Norm]
Topic: Next meeting: telcon 29 Mar 2007
15:07:21 [Norm]
No regrets given.
15:07:24 [Norm]
Topic: Review of editor's draft
15:07:24 [Norm]
15:07:56 [Norm]
Norm: Anyone think we can't publish this as a PWD?
15:08:34 [Norm]
Henry: I'm worried that some of the XML examples are wrong.
15:08:50 [MSM]
zakim, please call msm-office
15:08:50 [Zakim]
ok, MSM; the call is being made
15:08:52 [Zakim]
15:08:56 [Norm]
Norm: I'll fix the XML
15:09:26 [Norm]
Norm: Any other showstoppers?
15:09:28 [Norm]
None heard
15:09:53 [Norm]
Norm: I went through the last week or so's mail and identified several issues that we've been discussing.
15:10:09 [Norm]
Topic: Placement of ignored content?
15:10:30 [Norm]
Norm: Can you put documention inside of p:pipe or p:document or p:inline?
15:10:52 [Norm]
Regrets: Mohamed
15:11:11 [Norm]
Murray: I think we should have an element dedicated to documentation instead of playing games with ignored prefixes.
15:11:21 [MSM]
q+ to agree with Murray
15:11:55 [Norm]
Norm: Having an element for documentation for eliminate the need for ignored preixes.
15:12:11 [Norm]
ack msm
15:12:11 [Zakim]
MSM, you wanted to agree with Murray
15:12:47 [Norm]
Michael: I wanted to agree with Murray. You don't want to get rid of ignored content but you want to limit it to extensions.
15:13:20 [Norm]
...Documentation is a well understood need, so label it that.
15:13:29 [Norm]
Norm: Mohamed also agreed in IRC
15:13:32 [ht]
q+ not to allow documentation inside p:inline
15:13:36 [MSM]
s/for eliminate/does not eliminate/
15:13:39 [Norm]
ack ht
15:14:29 [Zakim]
15:14:38 [Norm]
Henry: I'm happy to leave the question of where documentation is allowed to the editor, but I don't want it to be allowed in p:inline. The p:inline content shouldn't have any special rules.
15:14:53 [Norm]
...If you don't want it to go through the pipeline, don't put it in p:inline.
15:15:13 [Norm]
Norm: I'm hearing a proposal to have p:documentation element that is just for documentation.
15:15:26 [Norm]
Murray: You might want to spell it with a shorter word.
15:15:28 [Norm]
Norm: Such as?
15:15:43 [ht]
zakim, mute me
15:15:43 [Zakim]
Ht should now be muted
15:15:53 [Norm]
Murray: p:readme?
15:16:06 [Norm]
Norm: I don't like that one, how about p:doc?
15:16:09 [MSM]
[p:doc works for me]
15:16:14 [Norm]
Norm: Everybody happy with p:doc?
15:16:14 [Norm]
15:17:12 [Norm]
Norm: Do we now want to rename "ignored-prefixes", "extension-prefixes"
15:17:39 [Norm]
Murray: What for?
15:17:44 [Norm]
Norm tries to explain.
15:19:03 [ht]
zakim, unmute me
15:19:03 [Zakim]
Ht should no longer be muted
15:19:05 [Norm]
Norm: I don't think we have to worry about where p:ignored-prefixes is allowed or any defaults for ignored prefixes now that we have a documentation element.
15:19:20 [Norm]
Topic: Import precedence
15:19:36 [ht]
HST agrees, subject to my comment about p:inline. . .
15:19:50 [Norm]
Norm: The question is, should you be to declare a step or define a pipeline with the same name as some declared step or pipeline that you imported from a library.
15:20:46 [Norm]
Henry: It seems relatively cheap but relatively unlikely to be useful. But it's probably better than ignoring the issue.
15:21:03 [Norm]
Murray: I'm worried about the security issue and spoofing of pipelines.
15:21:36 [ht]
OK, so A imports and overlays part of B, and I import A and B, what do I get?
15:21:44 [Norm]
Murray: If your library imports Alex's, but you've put some subtle change in, maybe you can steal data from me. Or maybe I'll have a hard time debugging it.
15:22:10 [Norm]
Henry: I'm convinced, let's not doit.
15:22:22 [Norm]
Norm: Me too.
15:22:24 [Norm]
Topic: Pipeline visibility
15:22:36 [Norm]
Norm: Can two pipelines defined in the same library see each other?
15:23:31 [Norm]
Murray: Yes, of course.
15:23:42 [Norm]
Norm: I think a consequence of this is that order no longer matters.
15:24:51 [Norm]
Norm: So you can't do a single pass, you have to be prepared to encounter qnames for pipelines that you haven't seen declarations for yet.
15:24:58 [Norm]
Topic: Order of input/output/param/option
15:25:56 [Norm]
Norm: Do we define the content of step with a sequence or a choice group?
15:26:33 [Norm]
Murray: What Jeni says makes sense
15:28:12 [Norm]
15:28:20 [Norm]
Murray: I think you have to have all the declarations first
15:29:06 [Norm]
Henry: I think it's pointless to allow variability of only limited utility.
15:29:41 [Norm]
Murray: I want them to be in any order, as long as they come before the first step.
15:30:00 [Norm]
Murray: While I can somewhat appreciate Henry's position, I don't see that there's any great cost.
15:30:04 [Norm]
Henry: I don't feel strongly.
15:30:27 [Norm]
Norm: Anyone strongly in favor of the status quo?
15:30:49 [Norm]
Norm: Ok, let's change it for the next draft and add a note to the spec soliciting feedback on this point.
15:31:02 [Norm]
Topic: Interpretation of type name on declare-step
15:31:43 [Norm]
Norm: Is an unprefixed name in the type attribute of p:declare-step implicitly in the default namespace a la Schema rules, or in no namespace, a la XSLT rules.
15:32:27 [Norm]
Norm: Henry, you wanted the Schema rules, Alessandro, Alex, and Norm prefer the XSLT rules.
15:32:41 [Norm]
Norm: Anyone other than Henry arguing for the schema rules?
15:34:01 [Norm]
Murray: I'm confused.
15:34:04 [Norm]
Norm tries to explain.
15:34:37 [Norm]
Murray: If I now write a pipeline and I want to use that process and I have a namespace bound to the prefix, example:
15:35:05 [ht]
q+ to make the Dan Connolly point
15:35:13 [ht]
q- not
15:35:26 [Norm]
ack ht
15:35:26 [Zakim]
ht, you wanted to make the Dan Connolly point
15:37:40 [Norm]
Henry: If we adopt the proposal, then some names won't be in any namespace and as Dan Connolly observes, all things should be on the web.
15:39:53 [Norm]
s/on the web/have a URI/
15:40:14 [Norm]
Henry: We're in an inconsistent position for libraries which is the full equivalent of the schema position.
15:40:52 [Norm]
Henry: I prefer the following summary of the schema rules: whenever something is a reference, the full namespace bindings are available, but for naming things you don't use the namespace bindings at all.
15:41:23 [Norm]
Henry: That's what we did for pipelines and libraries, but not what we've done for types, so I'm in an impossible position.
15:42:07 [Norm]
Norm: We don't need to answer this for the next draft, so I'm going to move on.
15:42:26 [Norm]
Murray: Ok, though I'm tending to lean towards Norm's answer because I think XSLT is going to be closer than Schema for our users.
15:43:16 [Norm]
Topic: Review of the step library
15:43:16 [Norm]
15:43:34 [Norm]
Norm: I sent in some minor comments, Henry did to. Alex, did you get anything off list?
15:43:38 [Norm]
Alex: No, not really.
15:44:00 [Norm]
Norm: Any components that anyone would prefer not to see in the next working draft?
15:44:24 [Norm]
Henry: Yes, if we're not going to settle the caching question until after this draft, then we should remove the xinclude-with-sequence component.
15:44:38 [Norm]
Alex: I'm happy to exclude it for now.
15:45:56 [Norm]
Henry: I support the sequence of schemas
15:46:14 [Norm]
Henry: We looked at the minor components for most of a telcon (when I was chairing pro-tem)
15:46:33 [Norm]
Henry: I'm not sure we've ended up with all the things we talked about.
15:47:22 [Norm]
Topic: Output from components that currently have no output.
15:48:09 [Norm]
Norm: Murray suggested that the components that currently have no output could usefully have a single output that identifies the location where the content was actually written.
15:48:22 [Norm]
Henry: Yes, it does mean that components that succeed always have output.
15:48:53 [Norm]
Norm: Can you update the draft along those lines, Alex?
15:49:09 [Norm]
Alex: I wonder if we could use this to deal with non-XML results from httpRequest?
15:49:55 [Norm]
Alex: This and the httpRequest object have their own sort of component vocabularies.
15:50:33 [Norm]
Norm: I'm happy if you put the result in a component results namespace or something.
15:51:08 [Norm]
Proposal: The editors shall incorporate the decisions made today and the resulting draft will be published as the next public working draft.
15:51:21 [Norm]
15:51:49 [Norm]
Alex: We didn't talk about the XSL-FO component, are we adding it?
15:51:57 [Norm]
Norm: Any objections?
15:52:03 [Norm]
None heard. Go for it.
15:52:15 [Norm]
Topic: Solution for the caching problem
15:53:03 [alexmilowski]
alexmilowski has joined #xproc
15:53:11 [alexmilowski]
alexmilowski has left #xproc
15:53:39 [alexmilowski]
alexmilowski has joined #xproc
15:55:02 [Norm]
Norm: I think there are three options: do nothing, you can't, do the *-with-sequence, or do some form of caching.
15:55:09 [Norm]
Murray: I think we should do nothing. To clever by half.
15:55:14 [MSM]
[and in that case, give it the name Y-Include, also spelled "why include?"]
15:56:13 [Norm]
Henry: In certain cases, because tools expect to reference things by URI, and pipelines may want to compute those resources, that the ability to assing URIs to things as they flow through the pipeline and then getting access to those things by URI, in the case where that's what you want to do, seems to be valuable.
15:56:37 [Norm]
...We could say "no, in V1". I'm opposed to doing it across the board because it blows away streaming.
15:56:48 [Norm]
...You have to cache everything that comes out.
15:57:41 [Norm]
...That's much too high a burden. So my proposal was to adopt an intermediate position, allowing authors to do caching for a part of the pipeline.
15:58:21 [Norm]
Norm: I think we could decide not to do something for V1, but I'm really, really reluctant to go there. I think it's horribly near a requirement.
15:58:29 [Norm]
Alex: I think caching is the right way to proceed but not for V1.
16:00:14 [MSM]
q+ to point out that if we locate dynamically created resources (call them ports) in URI space, this question may look different
16:00:18 [ht]
HST: I want to be able to set the base URI to "#banana", i.e., not written out _anywhere_!
16:00:30 [ht]
q+ to push on that
16:00:31 [Norm]
Murray: I assume that if I do a store, I should be able to refer to that thing later.
16:00:32 [Norm]
Norm: That's caching.
16:00:33 [Norm]
Henry: The "later" doesn't have any real meaning in our specification.
16:00:34 [Norm]
Norm: We're out of time, we'll come back to this next week if we haven't finished it in email.
16:00:35 [Norm]
Topic: Any other business?
16:00:36 [Norm]
None. Adjourned.