See also: IRC log
Date: 7 July 2009
<scribe> Meeting: 148
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
<ht> Well, If ht could type . . .
-> http://www.w3.org/XML/XProc/2009/07/02-agenda
Accepted
-> http://www.w3.org/XML/XProc/2009/06/18-minutes
Accepted
Unlikely to achieve quorum; cancelled.
Accepted
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.
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.
Accepted.
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.
Accepted.
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.
Accepted.
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.
None heard.
Adjourned; talk to you all in two weeks.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/zajim/zakim/ Succeeded: s/June/July/g Succeeded: s/quorem/quorum/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Norm, PGrosso, Vojtech, Ht Present: Norm Paul Vojtech Henry Regrets: Mohamed Agenda: http://www.w3.org/XML/XProc/2009/07/02-agenda Found Date: 07 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/02-xproc-minutes.html People with action items: norm[End of scribe.perl diagnostic output]