XML Processing Model WG

Meeting 148, 07 Jul 2009


See also: IRC log


Norm, Paul, Vojtech, Henry


Accept this agenda?

-> http://www.w3.org/XML/XProc/2009/07/02-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2009/06/18-minutes


Next meeting: telcon 9 July 2009

Unlikely to achieve quorum; cancelled.

Next meeting: 16 July 2009


Implicit outputs on p:pipeline/p:declare-step

Norm summarizes.

Norm: Actually, it doesn't apply to p:pipeline.

Vojtech: I don't like a default output port on p:declare-step because it's anonymous. But Henry suggested that we call it "result" and I think maybe that's ok.

Henry: I appreciate that the situation is complicated; but it seems like it catches the 80/20.

Vojtech: One thing I find weird. Suppose you have a declare-step in a library that has an implicit output; then you can't refer to it by name

Norm: That's fixed if we say the name is "result"

Vojtech: We say similar things about viewport.
... So it's not such a big deal. Saying the rule doesn't apply to p:declare-step is maybe a bigger change.

Norm: I can see advantage of keep the rule and naming it result.
... but then that's inconsistent unless we always say that the implicit output is named "result".

Henry: It's hard to guess which inconsistency is least likely to bite people.
... The inconsistency that I rejected is maybe not so bad.
... If what we're saying is that either you get full scale defaulting or you get none.
... If you need, for good reasons to change it from pipeline to declare step, you're going to have to declare an input port so you might as well declare an output port at the same time.
... So we could say there's no defaulting on the way in or the way out.

1. We special case p:declare-step so that the implicit output port rule doesn't apply.

2. We don't do that, and then we have odd issues with ths anonymous port name

3. If we fix the odd issues by giving the port a name, then it's different because the other implicitly created ports don't have that name

4. We can fix that point by making the name always "result" in all cases.

Norm: My concern about 4 is that it can lead to less readable pipelines. Because users willb e able to refer to ports by name that are not explicitly named anywhere.

Henry: I'd be happier to go with 1 if we make at least some of our library examples use p:pipeline.
... We don't have any library examples, so I'm inclined toward 1.

Vojtech: It's my second favorite, but I can accept it.
... I don't like anonymous outputs, but maybe that's a personal issue.

Henry: Maybe we should put this in countdown for a week.

Norm: Ok, I'll highlight this tentative decision and give folks two weeks to push back.

Escaping in p:escape-markup

Norm: This is CR#135.

Norm summarizes.

-> http://www.w3.org/XML/XProc/2008/11/cr-comments/

Norm: We could change the spec to say what is escaped, but I think that would be a bit weird.
... Anyone want to argue for a change here?

Paul: Let's stay away.

Henry: What does serialization say?

Norm: Oh, right. This isn't about unescape markup at all. All unescape markup does is turn those characters into literal characters in the data model.
... This is all about serialization.

Henry: Serialization says that characters that must be escaped...must be escaped.
... Nothing else seems relevant. I don't think we need to say anything.
... Adding more requirements would be obnoxious.

Proposed: Close without action.


137 Default value for omit-xml-declaration

Vojtech: I brought it up, but I don't think we need to do anything about it.

Henry: I've found, in general,that I'm more often irritated when I get it and didn't want it than vice versa.

Vojtech: I'm ok.

Proposal: Close without action.


Add encoding to p:data

Norm summarizes.

Vojtech: The way it is in the spec now, there are two or three possibilities about how the XQuery step handles the input.
... It's all based on the content-type information.

Norm: Ok, the question of whether or not p:xquery is ever allowed to base64 decode a chunk of data is open, but I still don't see a downside to adding the encoding information to the output of p:data

Vojtech: And we could say that steps are allowed to decode it

Norm: I'm not as sure about that anymore

Vojtech: It seems to be just XQuery

Norm: I'm willing to add that rule to XQuery; XQuery already has a weird bunch of rules.

Proposal: Add [c:]encoding to the output of p:data.


Proposal: Add a new rule to the p:xquery step that says it can base64 decode c:data content
... if it's encoded.

<scribe> ACTION: Norm to proposal the exact text of the new rule for p:xquery that can base64 decode [recorded in http://www.w3.org/2009/07/02-xproc-minutes.html#action01]

We'll come back to this in two weeks as well.

Any other business

None heard.

Adjourned; talk to you all in two weeks.

Summary of Action Items

[NEW] ACTION: Norm to proposal the exact text of the new rule for p:xquery that can base64 decode [recorded in http://www.w3.org/2009/07/02-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/07/08 18:53:22 $