XProc Minutes of 19 Mar 2009

See http://www.w3.org/XML/XProc/2009/03/19-minutes

Meeting: XML Processing Model WG
Date: 19 Mar 2009
Agenda: http://www.w3.org/XML/XProc/2009/03/12-agenda
Meeting: 138
Chair: Norm
Scribe: Norm
ScribeNick: Norm
Regrets: Henry
Present: Norm, Mohamed, Alex, Richard

We're using the agenda from 12 Mar because that meeting was cancelled.

Topic: Accept this agenda?
-> http://www.w3.org/XML/XProc/2009/03/12-agenda

Accepted.

Topic: Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2009/02/26-minutes

Accepted.

Topic: Next meeting: telcon 26 Mar 2009?

Richard and Mohamed give regrets. Maybe cancel?

Topic: Issues around http-request, encodings, and content-types

Topic: 094 p:http-request, content-type, and encoding

Norm attempts to summarize. Henry said this wasn't an issue, which it
isn't for replies, but I think it is for requests.

Alex: We also have the problem that we've only got one set of
serialization parameters.

Norm: Ah, so in fact you simply can't do this. Maybe Henry was right.

Alex: You could do this by having some preceding steps individually
serialize each of the chunks then you could base64 encode it and the
right thing would happen.

Norm: If only we had a "serialize and return as text" step. You could
do it with p:store, but that might not always work.

Norm: I'm ok if we say you can't do this.

Alex: You can do this, but you have to figure out how to encode the
individual pieces yourself. And I think that's OK for version 1.0.

Norm: Let's look at the message that Alex sent.

  What sequence of *bytes* do we get from these non-XML media types:

  <c:body content-type="text/plain">XProc</c:body>

Richard: An application should produce an encoding that can include
all of the Unicode characters. So, utf-8 is a reasonable choice.

Alex: Implementations are free to choose it.

Norm: So the answer is "XProc" in an implementation-defined encoding
that MUST support all of Unicode.

Richard: It's a QoS issue if the implementation chooses an unexpected
encoding that the server doesn't understand.

Richard: Is there any encoding that HTTP processors are required to
understand?

Mohamed: I think only 8859-1.

Richard: Which means that HTTP processors aren't guaranteed to understand
arbitrary XML encodings.

  <c:body content-type="application/sparql">PREFIX k: &lt;
  http://www.atomojo.org/O/keyword/> SELECT ?e WHERE { ?e k:software () }
  </c:body>

Alex: The answer should be the same, but it's not a text media type.
The media type for application/sparql says that it's a sequence of
Unicode characters.

Norm: I think the same section applies and so the same rules apply.
It's not an XML media type.

  <c:body content-type="text/plain"><foo/></c:body>
  <c:body content-type="application/xquery"><foo/></c:body>

Both of these are errors.

You do not get the results of text serialization, they're just errors.

Norm: So you could use application/xquery+xml?

Alex: I don't think that's a defined media type.

Norm: Fair enough. So what would I do?

Alex: You'd have to escape it with escaped markup.

Topic: 098: p:http-request c:/response/c:body/@content-type value

Norm attempts to explain it.

Alex: I think it should contain the real content-type.

Norm: So in the 098 example, the c:body element will contain the escaped
markup that resulted from processing the response as text, but the 
content-type will still say application/xml.

Some discussion if this makes sense or not.

Basically, you lose either way if you're trying to round-trip XML.

Norm: I suppose we could pass back the override-content-type.

Alex: I think it's very convenient to have the value in the attribute,
but it should be the *same* value.

Norm: Florent also asks if the content-type includes the parameters.

Alex: I think it's a *literal* copy.

Norm: I thought it was sort of useful to not have to parse the parameters.

Alex: I think we might have been there once, but we've backed off.

Norm: Ok. I don't care what the answer is as long as we agree what the
answer is.

Topic: Case of method parameter.

Norm: Does it matter if the method parameter is u/c or l/c?

Alex: I think the spec says that it has to be upper-case.

Norm: I think the most consistent thing to do is say it must be
upper-case, but lots of folks are going to use lower-case.

Alex: We could certainly say that case doesn't matter.

Norm: I'm inclined to agree, and they're English words so there aren't
any case transliteration problems.

Norm: Proposed: they are case-insensitive values.

Accepted.

Topic: Any other business?

None heard.

Adjourned.