Agenda
See also: IRC log
->
Accepted.
->
Accepted.
Henry gives regrets for 5 Apr
->
Henry: In 4.5, you forgot to make the inheritance edit
<ht> Try's environment stuff is _two_ generations out of date
Mohamed points to a prefix problem in 2.1, http-request
Alex will fix that.
Norm will fix the environment stuff in try/catch as well.
Some discussion of the new "c:" namespace for standard component inputs and outputs
Proposed: Remove XHTML from the default set of ignored prefixes
Accepted.
Proposed: We will publish the current draft with the modifications described immediately above as our next Public Working Draft
Accepted.
Norm: I'm suggesting that we identify all the static and dynamic errors with QNames so that implementations can report them.
Henry: I'd like to suggest we use our own namespace.
Proposal: The editor will incorporate this change.
Accepted.
Mohamed had some comments:
->
Mohamed: Join sequences is just an identity with a bunch of inputs.
Henry: I think Mohamed is right.
Norm: I think Mohamed is right as well.
Alex: Are we clear about what multiple inputs do?
Norm: Yes, I think so.
<scribe> ACTION: Norm to clarify what p:input means when it contains a document and a pipe. [recorded in]
<scribe> ACTION: Alex to remove join-sequences [recorded in]
Mohamed: The load component uses the phrase "parameter" where an option is actually used. We should fix that.
Norm: Yes, I think we need to clarify that text.
<ht> ACTION: Alex to replace 'parameter' to 'option' as appropriate in the explanatory text of the built-in step appendices [recorded in]
<ht> Mohamed: Wrt p:load I'm not sure the order of option and output is very good
<ht> Norm: The change we made last week freeing those up should fix that
<ht> Mohamed: Ah, good
Mohamed: For p:subsequences, what will the XPath be for selecting the first or all but the first documents in the sequence?
Alex: Right now, this doesn't select by order, it selects by contents.
Norm: I think we're going to need additional options for selecting by order
<ht> Alex, note that "applies and XPath" in 1.5 Subsequence should be "applies an XPath"
Alex: The real use case here is getting the outputs from xslt
Norm: I propose "start" and "length" with "first" and "last" as magic tokens.
Henry: Surely we don't need
"first".
... I'd prefer to use -1 as the magic token.
Norm: We could do it that way.
Norm reviews the fn:subsequence function from XPath2 F&O
Henry: Instead of inventing new
syntax, we say that in the context of this evaluation, we say
that there's a parameter in the pipeline namespace that's bound
to the index of the document.
... Then you can say $p:position = 3 to get the third.
... But we'd also have to have $p:last and I wouldn't want to have to implement that in the way that it's implemented in XPath because I don't know what the last document is until slightly after I've found it.
... I sort of like $p:position (a number) and $p:last (a boolean).
Alex: Last is really hard for streaming.
Henry: The problem is you'd have
to inspect the XPath to know if you needed to keep track of the
positions.
... I think the right combination is to use p:position, because that's free. Then you can do almost anything you want.
Alex: I don't think I understand.
Henry: We have an option called "last-only" or something like that
Norm: You think in V1, we can get away without being able to get the last three documents?
Henry: Absolutely.
Alex: I think we need to support
the common use case.
... We need last because the XSLT 2 component gives the principle result as the last document.
... No where else do we have a variable bound for XPath, do we?
<ht> So I have in mind something like option name="last-handling" with values 'exclude' or 'only' or 'default'
Norm: Alex, do you think you have enough information to try writing this up?
Alex: Yes.
Henry: In 3.2, insert still says that "start" is required but it also provides a default for it in the text. That's an editorial fix. I think it should not be required, there should be a default.
Mohamed: I wanted to reconsider
p:map as part of the caching story.
... I'd like to have two outputs for XSLT 1 and XSLT 2, one that produces the principle result and another that produces the sequence of alternate outputs
... I'd like to be able to get the primary output even if one of the secondary outputs isn't well formed.
Norm: I'm not sure about that part
Alex: I like the idea, but is this inconsistent with XSLT2?
Henry: I like Mohamed's alternative better than forcing the principle result to be last.
Norm: I'm happy with the idea. Anyone uncomfortable about it?
Richard: Does this mean that exsl:result-document won't write the results to disk?
Norm: Yes, I think that's what I mean.
Henry: I think we're going to
have to say something about the safety of XProc. Consider what
we'd say if we needed a "Security Considerations"
section.
... I'd like to be able to say that conformant implementations will never write to disk unless you can see it in the pipeline.
Richard: Surely that depends on the components.
Henry: Yes, but all of the components specified in our document should be safe, except for store.
Richard: But we're talking about extensions to XSLT. Surely a language that allows extension can't be prevented from writing to disk.
Alex: I think for XSLT 1, we can say that the alternate documents appear on the port. We don't have to say anything about whether or not XSLT also serialized them.
Henry: It sounds like we have agreement about the secondary port, but we need to come back to the discussion of safety of components.
None.
Adjourned.