See also: IRC log
-> http://www.w3.org/XML/XProc/2011/10/20-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2011/10/13-minutes
Accepted.
Accepted. Skipping the telcon next week, meeting 31 Oct/1 Nov in Santa Clara
Henry: Some of the comments had already been addressed. Liam was commenting on a preceding draft.
Norm: I was hoping to make some progress on the remaining comments, but didn't get the feedback I requested.
... I think this has to be our focus for the f2f.
<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
<jimfuller> then we can summarise to WG
Norm: What about the prose I wrote?
Henry: It seems long, but I'm happy to include it.
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.
No one objects.
<jimfuller> +1
Norm: I'll resolve the remaining editorial issues with Paul and the pass it along.
-> http://www.w3.org/XML/XProc/xproc-candidate-issues/
Norm: Let's look at 013 as a place to start.
Alex: If it's sent back as application/octet-stream, then there's no information lost because there's no charset.
Norm: So maybe my first suggestion about charset param is not necessary.
Jim: What if you want to override the charset?
Norm: That seems a little odd to me.
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.
... 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.
Norm: We got here by adding c:data late in the process and not really taking the time to work out the consequences.
... On the basis that c:data has a charset attribute, I think c:body should as well.
Alex: I'm rereading the section on converting entity bodies, which I know we've talked about in the past.
... It feels like it could be tightened. It leaves open a lot of interpretation; especially if you get back something from http-request.
Norm: It also handles application/sparql and application/json.
Alex: We said charset for text/ types, maybe we should have said it for non-text/ types as well.
Norm: Ok that might be worth reviewing.
Alex: We could at least say non-normatively that the presence of a charset was a good way to make assumptions about the characters.
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.
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.
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.
<scribe> ACTION: Norm to write a proposal to do that. [recorded in http://www.w3.org/2011/10/20-xproc-minutes.html#action01]
Vojtech: It has implications in how p:data and p:http-request are handled as well.
Norm describes the shortcomings of p:unescape-markup as outlined in the message
Norm: I think we should default the charset.
Alex: Why can't we auto-detect?
Norm: That turns out to be really, really hard.
Alex: The flip side of that is, that we're guessing too. Forcing them to guess is good.
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.
General agreement.
Norm: describes the problem of a missing encoding in that case.
Vojtech: I think that's a problem in the step that *produced* the data. Fix it in the http-request.
... Make sure you have what you expected after you get the data.
Alex: If you look at the specification of this step.
... 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.
... 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.
... For example, a content-type attribute or a charset attribute. Then you can have it as whatever you want.
Vojtech: I proposed the same thing in my response.
... We can just have an optional option to enable or disable this behavior.
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.
... 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.
Alex: I wonder if it makes sense to categorize the different situations and then see what we've got.
... 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.
... Another is the the case Norm has, where you get different responses from the web.
... It might be nice to outline solutions for the different cases and then see where we are.
<scribe> ACTION: Alex to outline the various possibilities for input to p:unescape-markup. [recorded in http://www.w3.org/2011/10/20-xproc-minutes.html#action02]
Vojtech: What about 014?
Vojtech: I think it's the case, but it's not clear from the spec.
Norm: I think it is the case however, if you read our import story.
General consensus that it's a case of lazy evaluation.
Norm: There's a related question about lazy evaluation.
... Can you avoid imports if you don't need them?
Vojtech: No, because you have to report static errors.
Norm: So you have to do it half lazily.
Henry: Yeah, that is sort of unfortunate, but I think that's the way it is.
... It is or is not a static error to write a pipeline that invokes a step that isn't defined.
Vojtech: Forwards-compatible mode is relevant here..
Norm: In short: we do allow forward references and we do check for static errors.
None heard.
Adjourned.