W3C XML Protocol Working Group teleconference, 8 May 2002

1. Roll call

Present 28/22 Excused Regrets Absent

2. Agenda review

The WG Charter has been extended through July 31 (only the date has been changed in the revised Charter document).
The IP clause of the Charter will probably be changed again (through an AC review) to reference the Current Patent Policy.

3. Approval of minutes

No changes requested - the posted version of the minutes is approved.

4. Review of action items

- Issue 205
DF: Last telcon (May 1) we ran out of time before revisiting issue 205, and this issue was inadvertantly omitted from this
week's (May 8) telcon agenda. HFN has pointed out that MarkB is satisfied with our resolution of 205 when coupled with an
additional friendly amendment (). Is anyone not comfortable incorporating HFN's amendment?
MH: can you restate this?
HFN restates amendment, see [100].
No-one objects to incorporating amendment.

5. Status report

-Primer
Nothing to report
-Spec
Editors: the editor's to-do list is pretty much empty now, will work on readability checks.
OH: conformance document will be linked
CF: The spec diffs are OK but indicating changes directly in the text is much better
MH: will work on this.
DF: The next diffs should be small, and it may not be worth working on this.

-TBTF
DF: Most of the items from the last TBTF meeting are in the agenda of this meeting. 
HFN volunteered to draft the text for the HTTP binding as requested in the agenda.

-Conformance
Anish: New document posted and linked from the team page. Working for
integration for May 14th. It will be up to date for the latest spec. 
Some editorial issues may still be there but the core will be there for
the WG to review.
PC: How many tests come from implementors, and how many from reading the spec?
OH: We do not have an answer to that.

-Usage scenarios
Nothing to report.

-Requirements
Nothing to report

-Email binding
HMM: Is working to bring tha document up to-date with the changes in the HTTP MEP.

6. Loose ends?

None reported.

7. LC Planning

Conformance document is pretty much up to date and it will be available
next week. We also have outstanding issues and we have to resolve them before 
going to LC. If we can finish issues by May 14th, we can start review of the 
whole thing and plan to go to LC.

Assuming the major issues are finished on this telcon, the editors indicate they can
have a new snapshot by May 14th, possibly by the end of the previous week.

DF: when the new spec snapshot becomes available, the WG should do a detailed review.
Any other small details that are completed after May 14th can be reviewed separately.

WG agrees.

8. Remaining active issues

- Issue 195
HFN: the proposal has 2 sides, we have qname or we don't say anything about return values.
Noah: we need to clarify our goals in resolving this issue. RPC is a wire representation,
used by many languages. Troubles arise when you have optional return values.
HFN: we got the same pb with SOAP/1.1 it might be a good idea to have it explicit in the
message.
DF: Do we care to provide that explicit token?
HFN: +1 to Noah, it would be good to have something explicit there.
MB: +1
RW: not sure it is necessary, especially in the proposed way.
OH: potentially useful, from implementors point of view it is clearly a plus.
DF: sounds like the majority wants an explicit marker, so what kind of marker  should we have?
HFN: the choices are:
- local names (has sets of pb, conflicts...)
- qnames (can't be easily  described easily in a schema)
- global unique name (wrapper)
CF: use the ID of the return value and identify in a header
RW: the Wrapper helps a little but not as much as I would like. Another 
alternative is to identify outbound edge, a clearly identify type that 
identify the wname of the return value.
OH: is that like Chris' reference option?
DF: wrapper seems to be the least unliked option
MH: Ray talked against wrapper, did someone say anything against qnames?
DF: qnames seems to be the best option then. Does anyone object to resolving issue 195 using
QName to identify the result?
No-one objected.
DF: Issue 195 is closed with this resolution. RayW to write resolution text.

- dealing with root
MH has provided a summary of the root issue [101]
NM: we allow refs from the header to the body and the reverse.
MH: we identify rpc struct with tagging.
HFN: the body is one struct, you can't have multiple top level using RPC
convention, as it is not allowed.
HFN: agreed we don't need a root attribute.
MH: should we add that in the RPC convention there should be only one child?
HFN: if you are not using RPC you can have as many top levels as you want. RPC is more restrictive.
DF: Option a in [101] (explicitly disallow top-level multi-refs) seems to resolve the root issue.
Does anyone object to resolving the root issue by adopting this option?
No one objects
DF: we will adopt this formulation.

- issue 194
DF: Proposal is that the encoding style attribute cannot appear in any elements defined in the
envelope namespace.
MH: I think "cannot" is "MUST NOT".
DF: Is there any objection to closing issue 194 by saying the encoding style attribute must not
appear in any elements defined in the envelope namespace?
No one objects.
DF: issue 194 is closed with this resolution.

- proposal by TBTF to update return code 204
HFN: not supporting 204 will make our integration with HTTP more problematic (e.g. for some MEPs).
NM: if 204 would be mapped to a non-response fixed SOAP reply. Then it
would be treated at the SOAP level. HTTP 204 says "it's a success"
YL: 202 doesn't make any assumption wrt processing as 204 do, is the same model valid there?
(Scribe missed the reply.)
CF: having no body back is valid. 
HFN: the SOAP processor can see that the 204' SOAP reply is generated
MH: it would contain no header, so if we have a "echo this header", it will fail.
MH: I really don't think this proposal would work. 
DF: discussion will continue on email and hope to have it for next telcon.

[100] http://lists.w3.org/Archives/Public/xml-dist-app/2002May/0044.html
[101] http://lists.w3.org/Archives/Public/xml-dist-app/2002May/0052.html