IRC log of xproc on 2009-07-23
Timestamps are in UTC.
- 15:01:46 [RRSAgent]
- RRSAgent has joined #xproc
- 15:01:46 [RRSAgent]
- logging to http://www.w3.org/2009/07/23-xproc-irc
- 15:01:47 [Norm]
- Meeting: XML Processing Model WG
- 15:01:47 [Norm]
- Date: 23 July 2009
- 15:01:47 [Norm]
- Agenda: http://www.w3.org/XML/XProc/2009/07/23-agenda
- 15:01:47 [Norm]
- Meeting: 150
- 15:01:47 [Norm]
- Chair: Norm
- 15:01:49 [Norm]
- Scribe: Norm
- 15:01:51 [Norm]
- ScribeNick: Norm
- 15:02:26 [Zakim]
- +Norm
- 15:02:39 [Zakim]
- +Jeroen
- 15:02:52 [MoZ]
- Zakim, Jeroen is Vojtech
- 15:02:52 [Zakim]
- +Vojtech; got it
- 15:03:24 [Norm]
- Zakim, who's on the phone?
- 15:03:24 [Zakim]
- On the phone I see PGrosso, MoZ, Norm, Vojtech
- 15:05:59 [ht]
- ht has joined #xproc
- 15:06:08 [ht]
- zakim, please call ht-781
- 15:06:08 [Zakim]
- ok, ht; the call is being made
- 15:06:10 [Zakim]
- +Ht
- 15:06:59 [Norm]
- Present: Paul, Mohamed, Norm, Vojtech, Henry
- 15:07:39 [Norm]
- Topic: Accept this agenda?
- 15:07:39 [Norm]
- -> http://www.w3.org/XML/XProc/2009/07/23-agenda
- 15:07:44 [Norm]
- Accepted.
- 15:07:58 [Norm]
- Topic: Accept minutes from the previous meeting?
- 15:07:58 [Norm]
- -> http://www.w3.org/XML/XProc/2009/07/16-minutes
- 15:07:59 [Norm]
- Accepted.
- 15:08:18 [Norm]
- Topic: Next meeting: telcon 30 July 2009
- 15:08:30 [Norm]
- Mohamed gives regrets.
- 15:08:54 [MoZ]
- Zakim, mute me
- 15:08:54 [Zakim]
- MoZ should now be muted
- 15:08:59 [Norm]
- Topic: Recent comments on the CR draft
- 15:09:07 [Norm]
- -> http://www.w3.org/XML/XProc/2008/11/cr-comments/
- 15:09:50 [Norm]
- Topic: 142 charset on unescape-markup?
- 15:10:03 [Norm]
- Vojtech: I wasn't sure what the user was trying to do.
- 15:10:34 [Norm]
- -> http://lists.w3.org/Archives/Public/xproc-dev/2009Jul/att-0042/00-part
- 15:11:26 [Norm]
- Zakim, who's talking?
- 15:11:36 [Zakim]
- Norm, listening for 10 seconds I heard sound from the following: Vojtech (25%), Ht (84%)
- 15:11:41 [Norm]
- Zakim, mute ht
- 15:11:41 [Zakim]
- Ht should now be muted
- 15:11:55 [ht]
- zakim, disconnect me
- 15:11:55 [Zakim]
- Ht is being disconnected
- 15:11:56 [Zakim]
- -Ht
- 15:11:57 [MoZ]
- Zakim, unmute me
- 15:11:57 [Zakim]
- MoZ should no longer be muted
- 15:12:06 [Norm]
- Vojtech: I think unescape markup ignores the charset information if the content type is a text type.
- 15:12:08 [ht]
- zakim, please call ht-781
- 15:12:08 [Zakim]
- ok, ht; the call is being made
- 15:12:09 [Zakim]
- +Ht
- 15:12:27 [Norm]
- ...It only uses the charset information when the data is base64 encoded, to decode the data.
- 15:12:39 [Norm]
- ... I propose two solutions.
- 15:13:24 [Norm]
- Vojtech: The output of unescape markup used the wrong charset.
- 15:13:38 [Norm]
- ...It only uses charset if the data is binary and base64 encoded.
- 15:14:22 [Norm]
- ...To make sure that the charset is used, use p:data and set the content-type to something binary. That assures that the data is base64 encoded and the charset will be used when decoding the data.
- 15:14:43 [Norm]
- ...The other solution is similar, in p:data set the charset so that p:data applies the right charset encoding.
- 15:14:56 [Norm]
- Norm: Yes.
- 15:15:20 [Norm]
- Norm: I think that if he got XML that was incorrectly encoded, that's a bug.
- 15:15:46 [Norm]
- Vojtech: It depends how he passed that data to unescape-markup.
- 15:16:05 [Norm]
- Norm: If p:data was used, then the charset should have been used when loading the data.
- 15:16:28 [Norm]
- ...If p:http-request was used and the return type was something Unicode, then the charset should have been used.
- 15:16:51 [Norm]
- ...If the return type was binary, then the result should have been base64 encoded and the charset should have been used when expanding that.
- 15:17:25 [Norm]
- Norm: I can't think of any way to get data in the wrong character set into p:unescape-markup that isn't an implementation bug.
- 15:18:19 [Norm]
- Norm: We're equally careful in p:http-request and p:data, so I think this is just a bug.
- 15:19:24 [Norm]
- Vojtech: I tried these approaches in Calumet and they worked.
- 15:19:36 [Norm]
- Norm: Ok, I think that makes it clear that this is an implementation error in XML Calabash
- 15:20:04 [Norm]
- Vojtech: Related to this, I have a question about p:data. If you use p:data to load a text file that's in Windows-1252 then p:data converts it to Unicode characters.
- 15:20:22 [Norm]
- ...But at least in our implementation, the charset implementation still remains in the c:result wrapper.
- 15:20:25 [Norm]
- ...I wonder if that's correct.
- 15:22:43 [Norm]
- Norm: In p:http-request, we're explicit that the content-type value must be an exact copy of the response header.
- 15:23:01 [Norm]
- ...In p:data, we have the added complication that sometimes we ahve to infer a content type. But we should probably say that it should be an exact copy if we do have one.
- 15:24:11 [Norm]
- Vojtech: Even when inferring a content type you could do some magic to infer the charset.
- 15:25:19 [Norm]
- Norm: I think we should add the same clarification here that we have in p:http-request, that the content type will reflect any charset specified even in the case where those characters have been converted to Unicode.
- 15:25:34 [Norm]
- Proposal: do that
- 15:25:40 [Norm]
- Accepted.
- 15:26:03 [Norm]
- ACTION: Norm to update the spec to specify the charset in p:data to be as explicit as it is in p:http-request.
- 15:26:28 [Norm]
- That covers 143 as well.
- 15:26:35 [Norm]
- Topic: 144 Semantics of p:wrap
- 15:27:05 [Norm]
- Norm: The semantics of p:wrap are intended to be recursive, unlike what I initially said.
- 15:27:07 [Norm]
- Accepted.
- 15:27:18 [Norm]
- Close without action.
- 15:27:37 [Norm]
- Topic: 145 Compound steps with unconnected output ports
- 15:27:54 [Norm]
- Vojtech summarizes his email.
- 15:29:03 [Norm]
- Norm: I think the answer is that you get an empty sequence if you try to read it.
- 15:29:12 [Norm]
- Vojtech: And if sequence=false, then you get a dynamic error?
- 15:29:25 [Norm]
- Norm: Yes, I think that's the case.
- 15:30:08 [Norm]
- Vojtech: There's discussion of this in p:for-each but not generally
- 15:30:16 [Norm]
- Norm: Right, I think we need a general statement.
- 15:30:37 [Norm]
- Norm: Proposed: unbound output ports on a compound step return an empty sequence when they're read, it's an error if they don't specify sequence=true
- 15:30:54 [Norm]
- Accepted.
- 15:31:00 [Norm]
- ACTION: Norm to say this in the spec.
- 15:31:35 [Norm]
- Topic: 146 Primary output port in p:viewport
- 15:32:02 [Norm]
- Vojtech: In viewport you can specify one output port. The spec says that p:viewport must contain a single primary output port.
- 15:32:30 [Norm]
- ...So do I have to set it primary explicitly, or is will it default to primary?
- 15:32:35 [Norm]
- Norm: Yes, it will default to primary=true
- 15:33:38 [Norm]
- Vojtech: A second question: suppose you have a declare-step and you declare two output ports.
- 15:33:49 [Norm]
- ...According to the rules, the other output port will be non-primary.
- 15:34:26 [Norm]
- <p:declare-step>
- 15:34:26 [Norm]
- <p:output port="one"/>
- 15:34:26 [Norm]
- <p:output port="two" primary="false"/>
- 15:34:26 [Norm]
- </p:declare-step>
- 15:34:42 [Norm]
- General agrement: both are non-primary.
- 15:35:35 [Norm]
- Topic: 147 primary output ports
- 15:35:37 [Norm]
- Norm explains.
- 15:37:00 [Norm]
- Vojtech: There's an implicit pipe binding in the p:with-option, so I think it's bound.
- 15:37:07 [Norm]
- Norm: Yes, I think you're right.
- 15:37:22 [Norm]
- Proposal: yes, that counts.
- 15:37:43 [Norm]
- Mohamed: I don't think it's sufficient for cycle checking.
- 15:38:49 [Norm]
- Norm: I think it is sufficient for cycle testing, there's a dependency between them.
- 15:39:48 [Norm]
- ACTION: Norm to attempt to clarify this in the spec.
- 15:40:46 [Norm]
- Topic: Default XML processing model?
- 15:41:01 [Norm]
- No news, it'll be a while before we can return to this.
- 15:41:06 [Norm]
- Topic: Test suite progrss?
- 15:41:25 [Norm]
- Norm: Vojtech gets a gold star for some truly tortuous tests this week.
- 15:41:41 [Norm]
- Norm: I think some of the burden is on my to update the coverage report.
- 15:42:17 [Norm]
- Vojtech: For tests for unconnected output ports, there is no well-defined static error for this case.
- 15:42:19 [Norm]
- Norm: Right!
- 15:42:52 [Norm]
- Norm: I made unconnected input ports static error and unconnected output ports static error 3.
- 15:43:19 [Norm]
- Norm: We should look through the spec and make sure that there's an error code for every MUST and MUST NOT.
- 15:43:57 [Norm]
- Vojtech: I'll do the review.
- 15:44:10 [Norm]
- s/progrss/progress/
- 15:44:13 [Norm]
- Topic: Any other business?
- 15:44:18 [Norm]
- None heard.
- 15:44:21 [Norm]
- Adjourned.
- 15:44:30 [Zakim]
- -Norm
- 15:44:32 [Zakim]
- -PGrosso
- 15:44:32 [Zakim]
- -Vojtech
- 15:44:33 [Zakim]
- -Ht
- 15:44:33 [Zakim]
- XML_PMWG()11:00AM has ended
- 15:44:34 [Zakim]
- Attendees were PGrosso, +95247aaaa, MoZ, Norm, Vojtech, Ht
- 15:44:44 [Norm]
- RRSAgent, set logs world-visible
- 15:44:48 [Norm]
- RRSAgent, draft minutes
- 15:44:48 [RRSAgent]
- I have made the request to generate http://www.w3.org/2009/07/23-xproc-minutes.html Norm
- 15:46:53 [PGrosso]
- PGrosso has left #xproc
- 17:32:08 [Zakim]
- Zakim has left #xproc