See also: IRC log
Date: 23 July 2009
<scribe> Meeting: 150
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
Mohamed gives regrets.
Vojtech: I wasn't sure what the user was trying to do.
Vojtech: I think unescape markup
ignores the charset information if the content type is a text
... It only uses the charset information when the data is base64 encoded, to decode the data.
... I propose two solutions.
... The output of unescape markup used the wrong charset.
... It only uses charset if the data is binary and base64 encoded.
... 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.
... The other solution is similar, in p:data set the charset so that p:data applies the right charset encoding.
... I think that if he got XML that was incorrectly encoded, that's a bug.
Vojtech: It depends how he passed that data to unescape-markup.
Norm: If p:data was used, then
the charset should have been used when loading the data.
... If p:http-request was used and the return type was something Unicode, then the charset should have been used.
... If the return type was binary, then the result should have been base64 encoded and the charset should have been used when expanding that.
... 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.
... We're equally careful in p:http-request and p:data, so I think this is just a bug.
Vojtech: I tried these approaches in Calumet and they worked.
Norm: Ok, I think that makes it clear that this is an implementation error in XML Calabash
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
... But at least in our implementation, the charset implementation still remains in the c:result wrapper.
... I wonder if that's correct.
Norm: In p:http-request, we're
explicit that the content-type value must be an exact copy of
the response header.
... 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.
Vojtech: Even when inferring a content type you could do some magic to infer the charset.
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.
Proposal: do that
<scribe> ACTION: Norm to update the spec to specify the charset in p:data to be as explicit as it is in p:http-request. [recorded in http://www.w3.org/2009/07/23-xproc-minutes.html#action01]
That covers 143 as well.
Norm: The semantics of p:wrap are intended to be recursive, unlike what I initially said.
Close without action.
Vojtech summarizes his email.
Norm: I think the answer is that you get an empty sequence if you try to read it.
Vojtech: And if sequence=false, then you get a dynamic error?
Norm: Yes, I think that's the case.
Vojtech: There's discussion of this in p:for-each but not generally
Norm: Right, I think we need a
... 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
<scribe> ACTION: Norm to say this in the spec. [recorded in http://www.w3.org/2009/07/23-xproc-minutes.html#action02]
Vojtech: In viewport you can
specify one output port. The spec says that p:viewport must
contain a single primary output port.
... So do I have to set it primary explicitly, or is will it default to primary?
Norm: Yes, it will default to primary=true
Vojtech: A second question:
suppose you have a declare-step and you declare two output
... According to the rules, the other output port will be non-primary.
<p:output port="two" primary="false"/>
General agrement: both are non-primary.
Vojtech: There's an implicit pipe binding in the p:with-option, so I think it's bound.
Norm: Yes, I think you're right.
Proposal: yes, that counts.
Mohamed: I don't think it's sufficient for cycle checking.
Norm: I think it is sufficient for cycle testing, there's a dependency between them.
<scribe> ACTION: Norm to attempt to clarify this in the spec. [recorded in http://www.w3.org/2009/07/23-xproc-minutes.html#action03]
No news, it'll be a while before we can return to this.
Norm: Vojtech gets a gold star
for some truly tortuous tests this week.
... I think some of the burden is on my to update the coverage report.
Vojtech: For tests for unconnected output ports, there is no well-defined static error for this case.
... I made unconnected input ports static error and unconnected output ports static error 3.
... We should look through the spec and make sure that there's an error code for every MUST and MUST NOT.
Vojtech: I'll do the review.
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/progrss/progress/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: PGrosso, +95247aaaa, MoZ, Norm, Vojtech, Ht Present: Paul Mohamed Norm Vojtech Henry Agenda: http://www.w3.org/XML/XProc/2009/07/23-agenda Found Date: 23 Jul 2009 Guessing minutes URL: http://www.w3.org/2009/07/23-xproc-minutes.html People with action items: norm[End of scribe.perl diagnostic output]