W3C XML Protocol Working Group teleconference, 20 March 2002

1. Roll call

Present 29/23 Excused Regrets Absent

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
today.
-- TBTF: nothing to report.
-- Conformance:
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" [22]

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 [13] 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 
  list.
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 
  solving this?
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
  attachments.
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
  Last Call? 
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
  the appendix. 
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 
  http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0086.html
Henrik: it is fine except it shouldn't suggest we plan to add any such 
  extension ourselves.
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
  closing text.
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 
  xmlp-comment text.

-- 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 
  xmlp-comment text.

-- 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 
  attributes.
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
  places.
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 
  xmlp-comments.

-- 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 
  failure description.

-- 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.