See also: IRC log
Date: 23 July 2009
<scribe> Meeting: 150
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
-> http://www.w3.org/XML/XProc/2009/07/23-agenda
Accepted.
-> http://www.w3.org/XML/XProc/2009/07/16-minutes
Accepted.
Mohamed gives regrets.
-> http://www.w3.org/XML/XProc/2008/11/cr-comments/
Vojtech: I wasn't sure what the user was trying to do.
-> http://lists.w3.org/Archives/Public/xproc-dev/2009Jul/att-0042/00-part
Vojtech: I think unescape markup
ignores the charset information if the content type is a text
type.
... 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.
Norm: Yes.
... 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
characters.
... 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
Accepted.
<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.
Accepted.
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
general statement.
... 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
Accepted.
<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
ports.
... According to the rules, the other output port will be
non-primary.
<p:declare-step>
<p:output port="one"/>
<p:output port="two" primary="false"/>
</p:declare-step>
General agrement: both are non-primary.
Norm explains.
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.
Norm: Right!
... 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.
None heard.
Adjourned.
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]