IRC log of xproc on 2011-10-20

Timestamps are in UTC.

14:01:27 [RRSAgent]
RRSAgent has joined #xproc
14:01:27 [RRSAgent]
logging to http://www.w3.org/2011/10/20-xproc-irc
14:01:30 [Zakim]
Zakim has joined #xproc
14:01:32 [Norm]
zakim, this is xproc
14:01:32 [Zakim]
ok, Norm; that matches XML_PMWG()10:00AM
14:02:05 [Norm]
zakim, passcode?
14:02:05 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Norm
14:02:15 [Zakim]
+Norm
14:02:20 [Norm]
Meeting: XML Processing Model WG
14:02:20 [Norm]
Date: 20 October 2011
14:02:20 [Norm]
Agenda: http://www.w3.org/XML/XProc/2011/10/20-agenda
14:02:20 [Norm]
Meeting: 200
14:02:20 [Norm]
Chair: Norm
14:02:21 [Norm]
Scribe: Norm
14:02:23 [Norm]
ScribeNick: Norm
14:02:54 [Norm]
zakim, who's here?
14:02:54 [Zakim]
On the phone I see Vojtech, PGrosso, Norm
14:02:55 [Zakim]
On IRC I see RRSAgent, Norm, PGrosso, Vojtech, Liam, ht, caribou
14:03:00 [Zakim]
+??P15
14:03:58 [jimfuller]
jimfuller has joined #xproc
14:04:13 [jimfuller]
lurking on irc, regrets on telcon with client at the moment
14:04:18 [jimfuller]
(last minute telcon that is!)
14:04:47 [Norm]
Present: Norm, Vojtech, Henry, Paul
14:04:52 [Norm]
Regrets: Mohamed, Jim
14:04:56 [Norm]
Topic: Accept this agenda?
14:04:56 [Norm]
-> http://www.w3.org/XML/XProc/2011/10/20-agenda
14:05:01 [Norm]
Accepted.
14:05:05 [Norm]
Topic: Accept minutes from the previous meeting?
14:05:05 [Norm]
-> http://www.w3.org/XML/XProc/2011/10/13-minutes
14:05:09 [Norm]
Accepted.
14:05:14 [Norm]
Topic: Next meeting: telcon, 32 October 2011 in Santa Clara
14:05:24 [PGrosso]
s/32/31/
14:05:53 [Norm]
Accepted. Skipping the telcon next week, meeting 31 Oct/1 Nov in Santa Clara
14:06:04 [Norm]
Topic: XML processor profiles
14:06:47 [Norm]
Henry: Some of the comments had already been addressed. Liam was commenting on a preceding draft.
14:06:59 [alexmilowski]
alexmilowski has joined #xproc
14:08:22 [Norm]
Norm: I was hoping to make some progress on the remaining comments, but didn't get the feedback I requested.
14:08:30 [Norm]
...I think this has to be our focus for the f2f.
14:08:58 [Zakim]
+Alex_Milows
14:09:11 [Norm]
Present: Norm, Vojtech, Henry, Paul, Alex
14:09:12 [jimfuller]
Norm, if we can grab some time next week, I think we can punch/summarise through most of Michael's comments in about an hour, I hvae done my first pass and now just need a bit of your time
14:09:24 [jimfuller]
then we can summarise to WG
14:10:12 [Norm]
Norm: What about the prose I wrote?
14:10:18 [Norm]
Henry: It seems long, but I'm happy to include it.
14:11:49 [Norm]
Norm: I propose if no one objects, we include it for the next draft. I think it'll help address at least a couple of comments that we have open.
14:11:52 [Norm]
No one objects.
14:11:54 [jimfuller]
+1
14:12:01 [Norm]
Norm: I'll resolve the remaining editorial issues with Paul and the pass it along.
14:13:48 [Zakim]
+JimFuller
14:15:10 [Norm]
Topic: XProc issues
14:15:18 [Norm]
-> http://www.w3.org/XML/XProc/xproc-candidate-issues/
14:15:54 [Norm]
Norm: Let's look at 009 as a place to start.
14:18:11 [Norm]
s/009/013/
14:19:30 [Norm]
Alex: If it's sent back as application/octet-stream, then there's no information lost because there's no charset.
14:22:00 [Norm]
Norm: So maybe my first suggestion about charset param is not necessary.
14:22:10 [Norm]
Jim: What if you want to override the charset?
14:22:34 [Norm]
Norm: That seems a little odd to me.
14:23:23 [Norm]
Vojtech: We now have c:body and c:data, I think that it would make sense if they were interchangable. The c:data has a charset attribute.
14:24:00 [Norm]
...Maybe it would be better if we just had c:data or c:body, but if we have to have both, they should be interchangable.
14:24:25 [Norm]
Norm: We got here by adding c:data late in the process and not really taking the time to work out the consequences.
14:24:44 [Norm]
Norm: On the basis that c:data has a charset attribute, I think c:body should as well.
14:25:15 [Norm]
Alex: I'm rereading the section on converting entity bodies, which I know we've talked about in the past.
14:26:03 [Norm]
...It feels like it could be tightened. It leaves open a lot of interpretation; especially if you get back something from http-request.
14:27:05 [Norm]
Norm: It also handles application/sparql and application/json.
14:27:24 [Norm]
Alex: We said charset for text/ types, maybe we should have said it for non-text/ types as well.
14:27:47 [Norm]
Norm: Ok that might be worth reviewing.
14:28:10 [Norm]
Alex: We could at least say non-normatively that the presence of a charset was a good way to make assumptions about the characters.
14:29:07 [Norm]
Norm: Let's move this up a level; is there anyone who disagrees with Vojtech's assertion that c:body and c:data should be interchangeable.
14:29:29 [Norm]
Vojtech: There are at least two steps, p:xquery and p:unescape markup that make explicit statements about c:data, we'd have to allow c:body there as well.
14:29:51 [Norm]
Norm: My inclination would be to do just that, to say everywhere that we use c:data that c:body is allowed and vice-versa.
14:30:02 [Norm]
ACTION: Norm to write a proposal to do that.
14:30:41 [Norm]
Vojtech: It has implications in how p:data and p:http-request are handled as well.
14:33:50 [Norm]
Norm describes the shortcomings of p:unescape-markup as outlined in the message
14:33:57 [Norm]
Norm: I think we should default the charset.
14:34:02 [Norm]
Alex: Why can't we auto-detect?
14:34:11 [Norm]
Norm: That turns out to be really, really hard.
14:35:10 [Norm]
Alex: The flip side of that is, that we're guessing too. Forcing them to guess is good.
14:36:35 [Norm]
Norm: Wait one sec. I did these in the wrong order. Consider my point 3 first. If p:unescape-markup gets a c:body or c:data elment that specifies the encoding, then it should use that encoding without causing errors.
14:36:38 [Norm]
General agreement.
14:38:20 [Norm]
Norm: describes the problem of a missing encoding in that case.
14:38:42 [Norm]
Vojtech: I think that's a problem in the step that *produced* the data. Fix it in the http-request.
14:38:54 [Norm]
...Make sure you have what you expected after you get the data.
14:39:08 [Norm]
Alex: If you look at the specification of this step.
14:39:34 [Norm]
...It doesn't say anything about the element that it expects to receive. Now we're saying if it receives a c:body it can do something with that.
14:39:53 [Norm]
...I wonder if it's better to just have an option that says you should look at this thing and if it has certain elements or attributes, use them.
14:40:09 [Norm]
...For example, a content-type attribute or a charset attribute. Then you can have it as whatever you want.
14:40:14 [Norm]
Vojtech: I proposed the same thing in my response.
14:40:26 [Norm]
...We can just have an optional option to enable or disable this behavior.
14:41:24 [Norm]
Norm: Ok. I don't recall that part of the discussion. Adding an option to specify that the encoding and/or content type are in attributes on the incoming element makes sense to me.
14:42:31 [Norm]
Norm: In summary: We don't want unescape-markup to default the charset, you have to get that right yourself, and we don't want c:data or c:body treated specially, we want an optional option to specify that content-type or encoding or charset are encoded in attributes on the root element.
14:42:52 [Norm]
Alex: I wonder if it makes sense to categorize the different situations and then see what we've got.
14:43:16 [Norm]
...One of the cases that we don't cover well is that I have a random bit of markup with a content-type attribute. I have to write a pipeline to pick that out and get it into options.
14:43:34 [Norm]
...Another is the the case Norm has, where you get different responses from the web.
14:43:47 [Norm]
...It might be nice to outline solutions for the different cases and then see where we are.
14:44:17 [Norm]
ACTION: Alex to outline the various possibilities for input to p:unescape-markup.
14:45:32 [Norm]
Vojtech: What about 014?
14:45:49 [Norm]
Topic: Issue 014, can steps have foward-references?
14:45:57 [Norm]
Vojtech: I think it's the case, but it's not clear from the spec.
14:48:29 [Norm]
Norm: I think it is the case however, if you read our import story.
14:49:50 [Norm]
General consensus that it's a case of lazy evaluation.
14:50:16 [Norm]
Norm: There's a related question about lazy evaluation.
14:50:59 [Norm]
...Can you avoid imports if you don't need them?
14:51:08 [Norm]
Vojtech: No, because you have to report static errors.
14:51:16 [Norm]
Norm: So you have to do it half lazily.
14:51:58 [Norm]
Henry: Yeah, that is sort of unfortunate, but I think that's the way it is.
14:53:59 [Norm]
Henry: It is or is not a static error to write a pipeline that invokes a step that isn't defined.
14:54:36 [Norm]
Vojtech: Forwards-compatible mode applies here.
14:54:46 [Norm]
s/applies here/is relevant here.
14:55:46 [Norm]
Norm: In short: we do allow forward references and we do check for static errors.
14:55:56 [Norm]
Topic: Any other business?
14:56:20 [Norm]
None heard.
14:56:27 [Norm]
Adjourned.
14:56:30 [Zakim]
-PGrosso
14:56:31 [Zakim]
-JimFuller
14:56:31 [Zakim]
-Vojtech
14:56:32 [Zakim]
-Alex_Milows
14:56:32 [Zakim]
-Norm
14:56:36 [Zakim]
-ht
14:56:38 [Zakim]
XML_PMWG()10:00AM has ended
14:56:38 [Norm]
rrsagent, set logs world-visible
14:56:39 [Zakim]
Attendees were Vojtech, PGrosso, Norm, ht, Alex_Milows, JimFuller
14:56:42 [Norm]
rrsagent, draft minutes
14:56:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/10/20-xproc-minutes.html Norm
14:56:45 [alexmilowski]
alexmilowski has left #xproc
14:58:57 [PGrosso]
PGrosso has left #xproc
16:29:59 [Zakim]
Zakim has left #xproc