See also: IRC log
-> http://www.w3.org/XML/XProc/2007/03/22-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/03/15-minutes.html
Accepted.
No regrets given.
-> http://www.w3.org/XML/XProc/docs/langspec.html
Norm: Anyone think we can't publish this as a PWD?
Henry: I'm worried that some of the XML examples are wrong.
Norm: I'll fix the XML
... Any other showstoppers?
None heard
Norm: I went through the last week or so's mail and identified several issues that we've been discussing.
Norm: Can you put documention inside of p:pipe or p:document or p:inline?
Murray: I think we should have an element dedicated to documentation instead of playing games with ignored prefixes.
Norm: Having an element for documentation does not eliminate the need for ignored preixes.
<Zakim> MSM, you wanted to agree with Murray
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.
... Documentation is a well understood need, so label it that.
Norm: Mohamed also agreed in IRC
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.
... If you don't want it to go through the pipeline, don't put it in p:inline.
Norm: I'm hearing a proposal to have p:documentation element that is just for documentation.
Murray: You might want to spell it with a shorter word.
Norm: Such as?
Murray: p:readme?
Norm: I don't like that one, how about p:doc?
<MSM> [p:doc works for me]
Norm: Everybody happy with p:doc?
Ok
Norm: Do we now want to rename "ignored-prefixes", "extension-prefixes"
Murray: What for?
Norm tries to explain.
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.
<ht> HST agrees, subject to my comment about p:inline. . .
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.
Henry: It seems relatively cheap but relatively unlikely to be useful. But it's probably better than ignoring the issue.
Murray: I'm worried about the security issue and spoofing of pipelines.
<ht> OK, so A imports and overlays part of B, and I import A and B, what do I get?
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.
Henry: I'm convinced, let's not doit.
Norm: Me too.
Norm: Can two pipelines defined in the same library see each other?
Murray: Yes, of course.
Norm: I think a consequence of this is that order no longer matters.
... 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.
Norm: Do we define the content of step with a sequence or a choice group?
Murray: What Jeni says makes sense
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Mar/0174.html
Murray: I think you have to have all the declarations first
Henry: I think it's pointless to allow variability of only limited utility.
Murray: I want them to be in any order, as long as they come before the first step.
... While I can somewhat appreciate Henry's position, I don't see that there's any great cost.
Henry: I don't feel strongly.
Norm: Anyone strongly in favor of the status quo?
... Ok, let's change it for the next draft and add a note to the spec soliciting feedback on this point.
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.
... Henry, you wanted the Schema rules, Alessandro, Alex, and Norm prefer the XSLT rules.
... Anyone other than Henry arguing for the schema rules?
Murray: I'm confused.
Norm tries to explain.
Murray: If I now write a pipeline and I want to use that process and I have a namespace bound to the prefix, example:
<Zakim> ht, you wanted to make the Dan Connolly point
Henry: If we adopt the proposal, then some names won't be in any namespace and as Dan Connolly observes, all things should be have a URI.
... We're in an inconsistent position for libraries which is the full equivalent of the schema position.
... 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.
... That's what we did for pipelines and libraries, but not what we've done for types, so I'm in an impossible position.
Norm: We don't need to answer this for the next draft, so I'm going to move on.
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.
-> http://www.w3.org/XML/XProc/docs/langspec.html#std-components
Norm: I sent in some minor comments, Henry did to. Alex, did you get anything off list?
Alex: No, not really.
Norm: Any components that anyone would prefer not to see in the next working draft?
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.
Alex: I'm happy to exclude it for now.
Henry: I support the sequence of schemas
... We looked at the minor components for most of a telcon (when I was chairing pro-tem)
... I'm not sure we've ended up with all the things we talked about.
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.
Henry: Yes, it does mean that components that succeed always have output.
Norm: Can you update the draft along those lines, Alex?
Alex: I wonder if we could use this to deal with non-XML results from httpRequest?
... This and the httpRequest object have their own sort of component vocabularies.
Norm: I'm happy if you put the result in a component results namespace or something.
Proposal: The editors shall incorporate the decisions made today and the resulting draft will be published as the next public working draft.
Accepted.
Alex: We didn't talk about the XSL-FO component, are we adding it?
Norm: Any objections?
None heard. Go for it.
Norm: I think there are three options: do nothing, you can't; do the *-with-sequence thing; or do some form of caching.
Murray: I think we should do nothing. Too clever by half.
<MSM> [and in that case, give it the name Y-Include, also spelled "why include?"]
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.
... We could say "no, in V1". I'm opposed to doing it across the board because it blows away streaming.
... You have to cache everything that comes out.
... 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.
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.
Alex: I think caching is the right way to proceed but not for V1.
<ht> HST: I want to be able to set the base URI to "#banana", i.e., not written out _anywhere_!
Murray: I assume that if I do a store, I should be able to refer to that thing later.
Norm: That's caching.
Henry: The "later" doesn't have any real meaning in our specification.
Norm: We're out of time, we'll come back to this next week if we haven't finished it in email.
None. Adjourned.