See also: IRC log
Amended with proposals from Alex, Norm, and Mohamed
Rui gives regrets for 3, 10 May.
Norm: I think I should move name and type down from err:errors to err:error.
Rui: If we have a nested try/catch and the inner catch fails, what will the outer catch get?
<MSM> [what data stream is referred to in the line and column numbers?]
<rlopes> All of them, maybe?
Henry: The error in the catch?
Rui: Yes, in the catch.
Henry: I think the catch should be transparent to the error and the outer try gets the failure as if the had occurred directly inside it.
MSM, The line/column are whatever the step thinks is helpful.
MoZ: So the first error is lost and the outer catch gets the errors from the inner catch.
<rlopes> yes, that's what I was thinking
Norm: I suppose we could say that all the errors are propagated upwards, but for V1, I'd rather not.
<MSM> [MSM meditates on the utility of an XSLT processor (for example) giving two locations (in input, in stylesheet)]
Norm: Is everyone happy enough to put this in the next spec?
MoZ: Does #error contain a single document or a sequence?
Norm: A single document, I think.
MoZ: But the document may contain multiple error elements.
<MSM> [MSM then wonders whether location info should be in a p:loc child of p:error, rather than in attributes ... or perhaps that's just too complicated?]
Michael: Do we want to consider allowing a step to provide multiple locations?
Henry: Maybe an alternative way would be to allow the error element to contain error elements.
Michael: It's not forbidden, so we could allow it.
Henry: I think most of the XML vocabularies do use attributes for this.
MoZ: For the location, if we are doing some streaming, it's not obvious that the SAX API give the location every time.
Norm: I think the location information is optional; not all steps will always be able to give it.
MoZ: That's why I was supporting MSM, so that we could have an other mechanism to identify the location.
MSM: There's nothing that
prevents you from putting a different location in the content
of the error.
... If you have a specialized way of identifying a location, that's OK, we just don't expect the framework to understand it.
... Having thought about it now for a few minutes, I think this is probably OK.
Norm: I guess what I'd like to suggest is that we go with this for the next draft and see if real world experience makes us want to change it.
<MSM> [p:code optional? No - better to require that people define an ERROR U000 miscellaneous unknown catastrophe]
MSM: We have href/line/column optional, but is code really supposed to be optional?
Norm: I think for components that don't have defined errors, there's no point insisting on a bogus error code.
Accepted, as amended above.
Henry: Why is it only the outer match that gets selected in:
Norm: Consistency with p:viewport.
Henry: In the p:viewport case,
there's nothing there to match, that's why. The same is true of
delete and replace.
... In the rename case, you can continue processing the subtree.
... I'd hate to have to write select expressions all over the place when I just want to hit all the elements that match a pattern.
... In the markup pipeline, all of these components use match semantics and no one has ever complained.
Norm: You could sell me either way.
Alex: I'm looking at these two
renames and I think the select version looks really
... I'd prefer to use match here.
<ht> This one surely looks simpler:
<ht> <p:option name="match" value="@foo"/>
<ht> <p:option name="name" value="bar"/>
Henry: I really really really think people are going to want to write that.
Richard: I agree that people will
want to write these short things, but there are cases that are
hard with match; I'd prefer to have both.
... The first para of a book, for example.
Norm: You're suggesting that it should use select or match
Richard: I agree that having both would be extra work, but it would be obvious.
Alex: I could live with both.
Mohamed: Is there really some matching pattern that we really cannot have with match that we can have with select.
Norm: So I'm hearing a consensus that we want both on some.
... I note that there's a very substantial set of match patterns that's easy to stream and select patterns tend to be much harder. I suspect that getting interop on the select side is going to be harder.
Richard: I'm not convinced by that because you can look at a select pattern and determine if it's really a match. Then you're in the same case.
Alex: If you're going to worry
about the streaming in all these components, you can't do it in
the general case.
... The reality is, are we making it harder for the implementor that can only stream in one case.
Richard: If we had a way of asserting that something was streamable, then I'd think Henry has a point. But we don't, so you have to test pattern.
Alex: You could just say that if
you use select, you lose.
... People interested in streaming are already interested in a subset of XPath.
<alexmilowski> (really a subset of XProc)
Alex: I'm in favor of putting both options on all these components.
<MoZ> +1 for both on some
<MoZ> agree with Henry's position for delete and replace
Norm: Only on some?
MoZ: I think that both makes sense on rename, but for delete and replace, I really like the fact that it's the same as viewport.
Norm: But I think that anything that's true of rename is true of delete.
<alexmilowski> what about delete //*/@id ?
MoZ: I'd prefer to be consistent with viewport than with components.
Alex: I'm not sure I see an inconsistency. They have some similarity to viewport, but they're more similar to themselves.
Richard: I didn't understand Alex's example.
Alex: If I want to delete all ID
attributes, there are lots of ways to write that as a select or
... My point is that if we're not putting a huge burden on implementors, then it's a question of what authors find easier.
... We should make things easier for authors.
Richard: I feel I should point
out that //*/@id is a match pattern. You're allowed to write
rooted match patterns.
... It is slightly tedious to implement delete when you might get back lists of nodes that contain descendants.
Straw poll: Should we allow both select and match patterns on all of the microcomponents?
Yes: 3, No: 3, Abstain: 2
Norm: I suggest we take this to email and come back to it in a week
Paul: The last email I saw was Norm proposing which one's use select and which one's use match. Why did you abstain?
Norm: Yeah, I just abstained in
the hope it would help get consensus.
... We need to get to last call.
Alex: Can we close some of these issues directly in email, or maybe with the W3C voting tool?
Henry: I think each of these does merit discussion.
Henry: I like the idea, but I
hate the name.
... The only thing I would consider as an alternative is to be able to annotate any connection with a URI.
... This is mostly for debugging. Maybe we should try for something even lighter weight.
... Adding an optional journal, log, or URI attribute to some elements.
<MoZ> +1 for henry's proposal, it is a debuging feature and should be thought more broadly
Alex: Any implementor could provide features to do this.
Norm: Yes, but I don't want it to be an implementation-dependent feature, I want to be able to run an unmodified pipeline through my implementation and yours and compare the results.
<scribe> ACTION: Henry to look at the language and see if a broader debugging proposal can be made. [recorded in http://www.w3.org/2007/04/26-xproc-minutes.html#action01]
Alex: For attributes it replaces the string value; for elements it should replace the descendants, yes?
Norm: Hmmm. Maybe.
Henry: Wait. We have to address the case where the delete component ends ../text().
Alex: It deletes all the text nodes.
Henry: Given that you can write text() at the end of the pattern, whether that allows us to clarify the question about the diffrence between elements and attributes.
Norm: I think I want attributes to be treated specially.
Henry: So we can write .../foo or ../foo/node() for the two cases.
Alex: If you say text() shouldn't it merge adjacent text nodes.
... Do we have consensus to add string-replace?