1. Roll call
- Canon Jean-Jacques Moreau
- Canon Herve Ruellan
- Compaq Yin-Leng Husband
- DaimlerChrysler R. & Tech Mario Jeckle
- DevelopMentor Martin Gudgin
- EDF (Electricite de France) Olivier Boudeville
- 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
- Macromedia Glen Daniels
- Martsoft Jin Yu
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Netscape Ray Whitmer
- Philips Research Amr Yassin
- Planetfred Mark Baker
- Progress Software Colleen Evans
- Rogue Wave Murali Janakiraman
- SAP AG Volker Wiechers
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- Systinet (IDOOX) Jacek Kopecky (Scribe)
- W3C Yves Lafon
- WebMethods Camilo Arbelaez
- WebMethods Asir Vedamuthu
- Compaq Kevin Perkins
- DaimlerChrysler R. & Tech Andreas Riegg
- Developmentor Aaron Skonnard
- EDF (Electricite de France) Philippe Bedu
- Fujitsu Limited Masahiko Narita
- Intel Brad Lund
- Macromedia Simeon Simeonov
- Netscape Vidur Apparao
- Philips Research Yasser alSafadi
- Rogue Wave Patrick Thompson
- SAP AG Gerd Hoelzing
- Systinet (IDOOX) Miroslav Simek
- W3C Hugo Haas
- Hewlett Packard Stuart Williams
- Active Data Exchange Richard Martin
- BEA Systems David Orchard
- IONA Technologies Oisin Hurley
- Matsushita Electric Ryuji Inoue
- Mitre Paul Denning
- Oracle Jeff MischKinsky
- Software AG Michael Champion
- Software AG Dietmar Gaertner
- Unisys Lynne Thompson
- Active Data Exchange Shane Sesta
- AT&T Mark Jones
- AT&T Michah Lerner
- Cisco Krishna Sankar
- Cisco Raj Nair
- IONA Technologies Eric Newcomer
- Mitre Marwan Sabbouh
- Oracle Anish Karmarkar
- Tibco Don Mullen
- Tibco Frank DeRose
- Unisys Nick Smilonich
2. Agenda review and AOB
3. Approval of minutes
Minutes of 20 Feb 2002 and 13 March 2002 approved as posted.
4. Review of Action Items:
-- On Email binding appendices:
MarkB sees the current email binding (RFC 2822) as insufficient in our attempt
to exercise our binding framework.
Noah does not share MarkB's concerns, he thinks the current Email binding is a
usable binding, and it shows a "second binding of SOAP".
DavidF: we'll set up a conferecnce call on this topic.
5. Status reports
-- Primer: incorporated comments.
-- Spec: the editors have done a lot of work, expect to publish a snapshot on
Friday and to clear the ed to-do list plus most of the issues we might resolve
-- TBTF: nothing to report.
Oisin sent the report in his regrets email, and DavidF read the report:
There is no new version on the website, there will be one Friday morning EST.
This version will contain additional assertions, and have removed obsolete
ones. Trying to coordinate with IBM and Microsoft and Soapbuilders list.
-- Usage Scenarios: waiting on example for S10.
-- Requirements doc: ok
-- Email binding: setting up the meeting to resolve MarkB's concerns.
6. There is a proposal for an "attachment feature" 
in other words there is an instantiation of option B ("Introduce today an
abstract attachment 'binding feature', but defer 'implementation' of this
feature to other specifications/notes, such as, for example SOAP+Attachment or
DIME.") from the list of options proposed  for resolving issue 61,
"external payload reference". At its meeting this week, the TBTF briefly
discussed the attachment feature proposal and with a few reservations they
agreed with it. The purpose of this agenda item is to decide whether the WG
agrees to (i) adopt the option B, and (ii) ask the TBTF to come up with a
refined attachment feature proposal in the very near future.
DavidF: we have a proposal for introducing an abstract concept of an
attachment and deferring the concrete implementations of this feature. There
were some comments on the lists and TBTF concall, mostly agreement.
PaulC: why do we do this? SOAP with Attachments has proven it can be done
without our explicit help.
DavidF: there has been a feeling that SOAP 1.2 should acknowledge attachments.
The proposal gives us a hook so that later on we could do a concrete
implementation. This is also a small piece of work.
PaulC: still, we are doing more than we must.
Noah: I've had a slightly different proposal on xml-dist-app.
[scribe disconnected, reconnected]
DavidF: we probably should now send this back to the TBTF and to the mailing
JohnI: we may task the TBTF to give us something next week.
Noah: the TBTF should copy the initial discussion email to the public list.
PaulC: Is it the opinion of the WG that we cannot go to Last Call without
Jean-Jacques: There is currently an issue closing issue 61. The
proposal would enable us to close issue 61. The proposal involves
only minor modifications to the HTTP binding. It provides a hook
that specs like DIME or S+A could use to add proper support for
DavidF: We will move this issue back to the TBTF and public discussion for a
week, then we'll revisit the topic.
PaulC: I have no objection to waiting a week.
7. Regarding the rewrite of Part 2 sections 2 and 3, is this the right direction?
Asir: this is not changing any functionality, so why do we have to do this for
Noah: this is much crisper than the last version...
Jacek: I have sent some comments that I think should be replied to by the
authors and probably also seen by the WG.
Gudge: I'll reply when I get to it, I've been busy.
DavidF: we've had external comments that liked the rewrite extremely much.
Asir: we should also have had an appendix with examples and it does not seem
to be there.
Gudge: The appendix is in there in a rough form. It was meant to provide
explanation on how XML Schema could be used with SOAP Encoding data, if you
were expecting any examples on Encoding, that's not what was meant to go in
Asir: why do we move from XML Schema?
Gudge: we get a better layering - moving typing to a higher layer, possibly
with a different type system than that provided by XML Schema.
Noah: This rewrite clarifies much our relation to XML Schema, removing many
loose ends, particularly with respect to validation.
Asir: if this is only about validation, can't we only add a comment saying
validation is not required? Or just required for builtin simple types?
Noah: that might have been the other way but SOAP 1.1 was never saying
explicitly that it does require validation of simple types, which is the only
real reference to XML Schema.
DavidF: we don't want to reopen the issue. Asir are you suggesting we go back
to the old text?
Asir: I was only asking for clarification. I'm not saying we should go back,
maybe we don't need to do that before Last Call. No objections to
incorporating it now if we have time to review it before LC.
DavidF: there will be time to review the rewrite before submitting the specs
to Last Call.
9. Issues having proposals that impact spec and other texts
-- Issue 41
DavidF: we have two proposed solutions, solution 2 being commented on as the
way to go.
Amr: we also have an amended proposal in
Henrik: it is fine except it shouldn't suggest we plan to add any such
Noah: I'm mostly OK with it, but it suggests that it's true that the target
URI should be in the envelope. We should be explicit that in some cases it
may be needed there, in other cases not.
Chris: we have raised this issue with the WS Architecture group.
DavidF: but we aren't in the position to wait for them to tell us whether or
not they are going to handle this.
DavidF: proposal: resolve issue 41 by accepting the amended text (pointed to
by Amr) without the square-bracketed text, which would be mentioned in the
HFN: suggestion that we just send the whole text to xmlp-comments as the
closing text, and change nothing in the spec.
DavidF: revised proposal: no change to the spec, amended proposal text going
into xmlp-comments as closing text.
No objections raised.
DavidF: issue 41 is closed with the revised proposal. Henrik will submit
-- Issue 189
Noah: for SOAP in general there is no issue, the HTTP binding should be clear
on the XML version it uses.
Henrik: The current spec (part 1) says that while the examples use XML 1.0,
it's not really mandatory as we're based on infoset.
DavidF: any objection to closing 189 by referencing this text?
Noah: I have some editorial comments which I will give to the editors.
No objections raised.
DavidF: Issue 189 is closed with the proposed text. JeanJacquesM will send
-- Issue 186
DavidF: the proposal is that we provide explicit text specifying uniqueness
constraints on the attributes ref and id. Is there any objection to closing
the issue with this proposal?
HFN: aren't we duplicating some external work?
Noah: XML Schema doesn't apply, DTDs we don't want, any other external work?
We could say "these attributes have the semantics as if a DTD was there."
Jacek: this might interfere with other application attributes named id and
ref, wouldn't it?
Gudge: no, not really, we'd say this only for SOAP Encoding id and ref
DavidF: again, any objection to the proposed text?
No objections reaised.
DavidF: issue 186 closed with the original proposed text. MartinG will send
text to xmlp-comment.
-- Issue 176
Proposal: we'll clarify the rules on how some particular "important" i
nformation items can or can not be changed. This has changed slightly with
the resolution to 137. Specifically, it clarifies what a SOAP receiver and
sender MUST and MUST NOT do with respect to some information items in some
Noah: it might need to be changed with some cleanups (DTD related) we make.
DavidF: any objections?
No objections raised.
DavidF: issue 176 is closed with the proposal. Henrik to send text to
-- Issue 187
Noah: the bindings should describe have some kind of a binding failure and a
badly formed SOAP message would be such (others being transmission link
breakage etc.). We'll have to introduce a broad model for binding failures.
It should affect the binding framework and the state machines. TBTF should
come up with a good answer to the broader issue and we'll resolve 187 as a
special case of that.
DavidF: any objections to moving this to the TBTF?
No objections raised.
DavidF: we will send this issue back to the TBTF to make a proposal on
-- Issue 167
DavidF: it is proposed that we issue a health warning.
Gudge: this issue should be covered by the rewrite of Part 2, sections 2 and 3.
No objections raised to this resolution with the understanding that Gudge
will check 167 is indeed covered by the rewrite.
-- Inconsistencies in versioning model, (from the agenda addendum).
Henrik: VersionMismatch is on the namespace URI, Upgrade header has the whole
root element QName. Proposal: we'll check everything on QNames. This carries a
lot of editorial work. We'll also mandate sending the Upgrade header.
DavidF: can we agree on this?
No objections were raised.
DavidF: we accept the proposal.
10. Assign people to create proposals
194: Encoding style in SOAP Header/Body: Henrik will create a proposal.
195: Why mandate RPC return value QName? No volunteer.
163: Jacek volunteered to come up with a proposal.
191: Noah volunteered to come up with a proposal.
192: Chris volunteered to summarise the positions in the discussion and
create a proposal.
193: The issue list already contains a proposal. We'll put it on agenda for
next week's telcon.
DavidF: thanks the editors for their hard work, and reminds the WG that we
shall have a new version of the spec to read on friday.
End of call.