- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 08 Jul 2009 11:54:34 -0700
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m27hyj0zv9.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/07/02-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 148, 07 Jul 2009
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Paul, Vojtech, Henry
Regrets
Mohamed
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon 9 July 2009
4. [8]Next meeting: 16 July 2009
5. [9]Implicit outputs on p:pipeline/p:declare-step
6. [10]Escaping in p:escape-markup
7. [11]137 Default value for omit-xml-declaration
8. [12]Add encoding to p:data
9. [13]Any other business
* [14]Summary of Action Items
--------------------------------------------------------------------------
Accept this agenda?
-> [15]http://www.w3.org/XML/XProc/2009/07/02-agenda
Accepted
Accept minutes from the previous meeting?
-> [16]http://www.w3.org/XML/XProc/2009/06/18-minutes
Accepted
Next meeting: telcon 9 July 2009
Unlikely to achieve quorum; cancelled.
Next meeting: 16 July 2009
Accepted
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.
-> [17]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.
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.
Accepted.
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.
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
[18]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
[19]http://www.w3.org/2009/07/02-xproc-minutes.html#action01]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [20]scribe.perl version 1.135 ([21]CVS
log)
$Date: 2009/07/08 18:53:22 $
References
Visible links
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2009/07/02-agenda
3. http://www.w3.org/2009/07/02-xproc-irc
4. http://www.w3.org/XML/XProc/2009/07/02-minutes#agenda
5. http://www.w3.org/XML/XProc/2009/07/02-minutes#item01
6. http://www.w3.org/XML/XProc/2009/07/02-minutes#item02
7. http://www.w3.org/XML/XProc/2009/07/02-minutes#item03
8. http://www.w3.org/XML/XProc/2009/07/02-minutes#item04
9. http://www.w3.org/XML/XProc/2009/07/02-minutes#item05
10. http://www.w3.org/XML/XProc/2009/07/02-minutes#item06
11. http://www.w3.org/XML/XProc/2009/07/02-minutes#item07
12. http://www.w3.org/XML/XProc/2009/07/02-minutes#item08
13. http://www.w3.org/XML/XProc/2009/07/02-minutes#item09
14. http://www.w3.org/XML/XProc/2009/07/02-minutes#ActionSummary
15. http://www.w3.org/XML/XProc/2009/07/02-agenda
16. http://www.w3.org/XML/XProc/2009/06/18-minutes
17. http://www.w3.org/XML/XProc/2008/11/cr-comments/
18. http://www.w3.org/2009/07/02-xproc-minutes.html#action01
19. http://www.w3.org/2009/07/02-xproc-minutes.html#action01
20. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
21. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 8 July 2009 18:55:27 UTC