1. Roll call
- BEA Systems David Orchard
- DaimlerChrysler R. & Tech Mario Jeckle
- Ericsson Research Canada Nilo Mitra
- Fujitsu Limited Kazunori Iwasa
- IBM John Ibbotson
- IBM David Fallside
- IBM Noah Mendelsohn
- Intalio Bob Lojek
- Intel Highland Mary Mountain
- IONA Technologies Oisin Hurley
- Macromedia Glen Daniels
- Martsoft Jin Yu
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Netscape Ray Whitmer
- Oracle Anish Karmarkar
- Philips Research Amr Yassin
- Planetfred Mark Baker
- Progress Software Colleen Evans
- SAP AG Volker Wiechers
- SAP AG Gerd Hoelzing
- SeeBeyond Pete Wenzel
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- W3C Yves Lafon (Scribe)
- W3C Carine Bournez
- WebMethods Camilo Arbelaez
- DaimlerChrysler R. & Tech Andreas Riegg
- Fujitsu Limited Masahiko Narita
- Intel Brad Lund
- IONA Technologies Eric Newcomer
- Macromedia Simeon Simeonov
- Netscape Vidur Apparao
- Oracle Jeff MischKinsky
- Philips Research Yasser alSafadi
- WebMethods Asir Vedamuthu
- AT&T Mark Jones
- Canon Jean-Jacques Moreau
- Canon Herve Ruellan
- Compaq Yin-Leng Husband
- Hewlett Packard Stuart Williams
- Mitre Paul Denning
- Rogue Wave Murali Janakiraman
- Software AG Michael Champion
- Systinet (IDOOX) Jacek Kopecky
- Tibco Don Mullen
- Unisys Lynne Thompson
- Active Data Exchange Richard Martin
- Active Data Exchange Shane Sesta
- AT&T Michah Lerner
- Cisco Krishna Sankar
- Cisco Raj Nair
- Compaq Kevin Perkins
- EDF (Electricite de France) Philippe Bedu
- EDF (Electricite de France) Olivier Boudeville
- Mitre Marwan Sabbouh
- Rogue Wave Patrick Thompson
- Software AG Dietmar Gaertner
- Systinet (IDOOX) Miroslav Simek
- Tibco Frank DeRose
- Unisys Nick Smilonich
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 .
No-one objects to incorporating amendment.
5. Status report
Nothing to report
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.
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.
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.
Nothing to report.
Nothing to report
HMM: Is working to bring tha document up to-date with the changes in the HTTP MEP.
6. Loose ends?
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.
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
DF: Do we care to provide that explicit token?
HFN: +1 to Noah, it would be good to have something explicit there.
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?
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 
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  (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
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.