W3C XML Protocol Working Group teleconference minutes: 21 March 2001

1. Roll call

PRESENT 35/29
Xerox     Ugo Corda
Akamai Technologies Mark Nottingham
AT&T Michah Lerner
Bowstreet Alex Ceponkus
Canon     Jean-Jacques Moreau
Engenia Software    Jeffrey Kay
Ericsson Research Canada Nilo Mitra
Fujitsu Software Corporation  Kazunori Iwasa
Group 8760     Dick Brooks
Hewlett Packard     David Ezell
Hewlett Packard     Stuart Williams
IBM  David Fallside (DF, below)
IDOOX     Jacek Kopecky
Intel     Randy Hall
Jamcracker     David Orchard
Library of Congress Ray Denenberg
Lotus Development   Noah Mendelsohn (Scribe)
Matsushita Electric Ryuji Inoue
Microsoft Corporation    Henrik Nielsen (Action items scribe)
Mitre     Paul Denning
Mitre     Marwan Sabbouh
Netscape  Ray Whitmer
Netscape  Vidur Apparao
Philips Research    Yasser alSafadi
Philips Research    Amr Yassin
Rogue Wave     Patrick Thompson
Rogue Wave     Murali Janakiraman
SAP AG    Volker Wiechers
Software AG    Michael Champion
Sun Microsystems    Marc Hadley
Tibco     Frank DeRose
Unisys    Nick Smilonich
Unisys    Lynne Thompson
W3C  Yves Lafon
WebMethods     Randy Waldrop

AUTOMATICALLY EXCUSED
AT&T Mark Jones
Bowstreet James Tauber
Canon     Herve Ruellan
Engenia Software    Eric Jenkins
Fujitsu Software Corporation  Masahiko Narita
IDOOX     Miroslav Simek
Library of Congress Rich Greenfield
Microsoft Corporation    Paul Cotton
SAP AG    Gerd Hoelzing
Software AG    Dietmar Gaertner
W3C  Hugo Haas

REGRETS
OMG  Henry Lowe
Allaire   Glen Daniels
Allaire   Simeon Simeonov
Calico Commerce     Rekha Nagarajan
Cisco     Krishna Sankar
Commerce One   David Burdett
Compaq    Yin-Leng Husband
DaimlerChrysler R. & Tech     Mario Jeckle
DaimlerChrysler R. & Tech     Andreas Riegg
DataChannel    Brian Eisenberg
DevelopMentor  Don Box
DevelopMentor  Martin Gudgin
IBM  John Ibbotson
Interwoven     Mark Hale
Novell    Scott Isaacson
Oracle    David Clay

ABSENT WITHOUT EXPLANATION
Active Data Exchange     Richard Martin
Active Data Exchange     Eric Fedok
Commerce One   Murray Maloney
Compaq    Kevin Perkins
Data Research Associates Mark Needleman
Epicentric     Dean Moses
Epicentric     Bjoern Heckel
IBM  Fransisco Cubera
Informix Software   Soumitro Tagore
Informix Software   Charles Campbell
Interwoven     Ron Daniel
IONA Technologies   Oisin Hurley
IONA Technologies   Eric Newcomer
Oracle    Jim Trezzo
Progress Software   Peter Lecuyer
Tradia    Erin Hoffman
Tradia    George Scott
Vitria Technology Inc.   Richard Koo
Vitria Technology Inc.   Waqar Sadiq
XMLSolutions   Kevin Mitchell
XMLSolutions   John Evdemon

2. Agenda review, call for AOB (5 mins)

>> Done

3. Approval of minutes from March 14 telcon [1] (5 mins)

>> Draft was not posted, so deferred to next week.  Draft expected
>> within a day or two.

4. Review action items, see [2] (5 mins)


2001/02/27: RPC subgroup (Ray W) Issue 45, is RPC a
module or not? Answer needed before closing the issue.  Ray: "I
believe that viewing RPC is module is dominant opinion."
>> DF: We will have detailed report later in the day.  Issue
>> is discharged.

2001/03/14: Henrik Create new WD by Friday
>> This was done

2001/03/14: Hugo Update the status saction of the
requirements document. Request publication of the new Working
Draft.
>> This was done

2001/03/14: Henrik Include figure 2.1 in the WD.
>> This was done

2001/03/14: Eric Jenkins To talk to JeffK in order to
make sure that he is aware that he owns this issue.
>> This was done

2001/03/14: Henrik and others.  To follow up on Noah's
work on issue 41.
>> No progress...still pending.

5. AMG report, StuartW (10 mins)

>> StuartW:
>>
>> AMG has meeting weekly by phone.  Aiming for document ready for
>> WG by end of March.  Snapshot has been posted to AMG members.
>> Will ask Yves or Hugo to post at stable URL and forward to
>> members.
>>
>> Status of doc: 5 sections Intro and terms: in good shape
>> Overview: in sync with requirements doc Service Model: as
>> presented at f2f Applications and module: considerable discussion
>> on email, ongoing.  Mark Jones will take lead in wrapping up.
>> Bindings: Marc Hadley has been working on this.
>>
>>
>> Plans (proposed by Stuart): Draft due to group a week from Friday
>> (4/30).  Open discussion planned through week of April 2 and 9th.
>> Possible aim to take to WD around 4/11 (plus publication delays)
>> Expects AMG group to dissolve around that time, except to work on
>> document at direction of WG.
>>
>> DF: we'll be aiming for publication on the 13th DF: on telcon on
>> the 28th, AMG group will give an overview.  Members are
>> encouraged to review the draft in advance of the 3/28 call.
>>
>> DF: Looking to start second telcon each week with focus on
>> technical matters.  Only the single weekly call will be required
>> attendance.  The other call will be primarily technical, as
>> opposed to the process-heavy nature of the main call.  Details to
>> be rolled out in the next week or two.

6. Report on template for XML Protocol Binding specification, report, HenrikFN & MarcH (5 mins)

>> MarcH: Discussion has occurred on the list.  Tracking peoples
>> comments and revising text accordingly.  Rolled the text into
>> section 5.1.5 of the AMG document.  Please look at it there and
>> comment.

7. (25 mins)

At the f2f meeting in Boston last month, we discussed when to publish the XMLP Specification as a Working Draft. The WG's sentiment was to publish when we have provided some additional value to what otherwise may be construed as the SOAP 1.1. specification with a W3C header. The purpose of this discussion is to identify what constitutes sufficient "additional value".

Note that we already have a number of "value-add" items: (i) the
Requirements WD [3], especially the Glossary (ii) the Issues list
[4] which was created by applying our requirements against the
SOAP 1.1 spec (iii) an Abstract Model WD (this does not exist
yet, but will very likely exist before we publish a spec WD)

Incorporating issue resolutions into the spec also adds value to
the spec.  The issue list contains a number of issues (44, 50,
56, 60) that have to do with providing bindings between XMLP and
transports. More specifically: I50 - notes the R501 requirement
to support a broad range of protocol bindings is only partially
met by SOAP 1.1's HTTP binding I60 - notes the R612 requirement
to explicitly describe an HTTP binding is not met by SOAP's
implicit HTTP binding I56 - notes the R600 requirement that XMLP
not rely on the feature of any particular transport and that SOAP
1.1 implicitly relies on a request/response transport to provide
message correlation I44 - notes the R200 requirement to support
matching request/response messages through a correlation ID is
not met through SOAP 1.1's (non-normative) reference to a
correlation ID Taken together, these issues would be resolved by
describing the binding of XMLP to an arbitrary transport, and how
to handle correlation of request/response messages.

In addition to these issues there are 2 other related and
on-going work items: (i) the AM Binding work (MarcH) which seems
to be relatively advanced (ii) the template for an XMLP binding
specification (MarcH & Henrik)

The chair proposes that the WG focus on resolving issues
50,60,56,44 (along with the other 2 work items) and decide that
some degree of their resolution is sufficient for XMLP WD
publication. We will need to find one or more owners for the
issues, and a timetable from them.

>> DF: Overarching issue: what does it take to represent progress so
>> we can publish?  One way to do this is to use issue resolution to
>> drive changes to the specification.
>>
>> Vidur: It might also make sense to change the terminology in the
>> SOAP specification to match the abstract group's spec.
>>
>> Henrik: What if they go out at the same time?  Bringing in the
>> glossary and hooking them together.
>>
>> Noah: Let's be careful with the signals we send as to whether we
>> are trying to remain very compatible with SOAP itself, vs. just
>> doing something in the same spirit.
>>
>> Henrik: Yes, I agree.  We should be careful with what we present,
>> and we shouldn't break things unless we need to.  There are 39
>> SOAP implementations out there.
>>
>> DF: Noah, what might you do?
>>
>> Noah: well, not sure.  Two speculative ideas: (1) stick with SOAP
>> syntax, indicate that our charter gives it to us as a starting
>> point, and that we are making incremental changes...not sure how
>> far those incremental changes will take use or (2) rename the
>> syntactic elements to match our abstractions...I (Noah) think
>> that the SOAP community would view the latter as disruptive and
>> unnecessarily inflamatory at this stage.

>>** NOTE: the first of these proposals is referred to in the discussion
>>** below as "Noah's Caveat".  At the end of the call, DF asked Noah to
>>** include in the minutes proposed specific wording for the caveat.  Here
>>** is a cut:  note that this exact wording was not proposed on the call
>>** itself and thus should not be viewed as a formal part of the record:
>>**
>>** Proposed wording:  "The XMLP Workgroup charter calls for the group to
>>** use SOAP version 1.1 as the basis for our proposals except where
>>** 'solutions that are agreed to be improvements' are found.
>>** In order to avoid predjudicing our analysis of either requirements or
>>** use cases, the workgroup has intentionally developed its own
>>** vocabulary for use in discussing proposals;  that vocabulary is
>>** explained in the glossary of this working draft, and is used where
>>** appropriate in the prose descriptions of the protocol.  With few
>>** exceptions, no changes have yet been proposed to the syntax or
>>** operation of SOAP Version 1.1 itself.  Such changes may possibly be
>>** proposed in the future as a result of our further analysis.  In the
>>** meantime, this draft therefore uses duplicate or closely-related
>>** terminology for certain concepts.  Our eventual recommendation
>>** will be presented using a single,consistent set of terminology."


>>
>> Frank DeRose: I'm uncomfortable if the spec doesn't
>> match the glossary.
>>
>> Henrik: Absolutely not to (2).  The SOAP syntactic constructs map
>> closely to those that we have in the glossary.
>>
>> DF (as WG member): I think it's not decoupling the spec from the
>> glossary.  It's how we weave them.
>>
>> Henrik: Third proposal...use the last parts of glosssary (not
>> sure what that means) and not change Soap.
>>
>> DF: Summary: seem to have general agreement to resolve glossary
>> with spec, but we need to be careful how we do it.
>>
>> DF: Sense of group; "do we think that for publishing the spec, we
>> need to do some resolution of glossary and spec" No dissent.
>>
>> Frank deRose: the time issue is important
>>
>> DF: Question is how.  I'd like someone to go away and do a
>> proposal.  Henrik volunteers and is assigned.
>>
>> DF: If we can put the glossary into the spec, and use as
>> appropriate, is it sufficient to publish as WD?
>>
>> Henrik: yes, because figure 2.1 will go into spec.
>>
>> Jeff Kay: should we also include the use cases?
>>
>> ???: query showed applications of their use cases
>>
>> DF: they distinguish use cases from useage scenarios
>>
>> DF: (baby proposal - not the original) Start with today's editors
>> copy as today, plus merged glossary, plus list of issues from our
>> issues list.  Figure 2.1 would go into the glossary, plus caveat
>> explaining differences of terminology and abstractions between
>> the AMG and glossary vs. the SOAP syntax (which stays more or
>> less unchanged.)  Q (Henrik): should issues list be inline or a
>> link?  DF: Proposal: verbatim issues list goes in spec...this is
>> part of making it clear how much is uncooked.
>>
>> Jeff Kay: people might wonder why we built all these
>> abstractions, if all we're going to do is republish SOAP.
>> Proposal: identify those things in SOAP 1.1 that do and don't
>> meet requirements as we have identified them.
>>
>> Ray D: I wasn't clear on the answer to my question about
>> how we are resolving with the abstract model.  We should make
>> clear that the ultimate design might lead to divergence from the
>> original SOAP specification.
>>
>> General agreement with Ray's concern...Noah: I intended that to
>> be included in the caveat.
>>
>> Henrik: note, the abstract model is NOT a set of
>> requirements....the abstract model and the syntax are both
>> reflections of the requirements
>>
>> Ray D: (1) you could look at AMG is something that just
>> influences the requirements and gets chucked or (2) it is a
>> useful by product of our work but...either way...it's ultimate
>> role is to get absorbed into our specification.
>>
>> DF: The two have to work in harmony, they are at different
>> levels.
>>
>> Stuart: I would say companion.
>>
>> Frank DeRose: normative vs. non-normative?
>>
>> *** DF: we will publish as a WD an XMLP specification containing
>> (1) current editors version of the spec (2) glossary...we will
>> have applied the glossary to the editors copy...we are not
>> changing the syntax of the SOAP language at this point, but we
>> will use glossary terminology in the prose...will also contain
>> figure 2.1 (3) "Noah's" caveat (4) verbatim the list of issues,
>> along with some header saying "this list of issues we will apply
>> against the body...etc.,...ties in with caveat" We would expect
>> to publish as a separate WD at essentially the same time,
>> the AMG draft.***

>>  NOTE: THE PROPOSAL ABOVE WAS SLIGHTLY AMENDED BY JEFF KAY TO
>> POSSIBLY INCLUDE A MATRIX OF CASES IN WHICH SOAP 1.1. DOES MEET
>> REQUIREMENTS, AND ADOPTED AS A RESULT OF THE DISCUSSION
>> IMMEDIATELY BELOW [Ed.]
>>
>> DF: Any dissent?
>>
>> Jeff Kay: it would be desireable to show more of how our
>> requirements analysis is impacting the spec.
>>
>> DF: For now, the evidence is in the issues we are listing.
>> Remember: we generated the issues by mapping SOAP against the
>> issues.
>>
>> Jeff Kay: suggest we include the mapping for the time being of the
>> requirements to the specification.  Specifically want to include
>> the requirements that were met as well as those that resulted in
>> issues.
>>
>> Noah: can we just put in an editors note linking to Henriks'
>> document that captures the full mapping of SOAP 1.1 to the
>> requirements?
>>
>> Jeff: I agree, but couldn't we build a matrix inline?
>>
>> DF: OK, Jeff, can you take it as an action item to look into
>> doing the matrix?
>>
>> DF: We'll take that as a friendly amendment.
>>
>> ***DF: Any dissent to adopt this plan, as amended with Jeff's
>> suggestion?  No dissent...so decided.***

8. Report on template for XML Protocol Module, report, DavidC & GlenD (10 mins)

>> not covered due to lack of time

9. Issue reports (15 mins) -- RPC subgroup, RayW [5a] [5b] -- Issue 47, DavidE [6] -- Issue 48, DavidE [7]

>> not covered due to lack of time

10. Any Other Business (5 mins)

>> Meeting page is up for Rennes meeting >> NEW ACTION ITEMS >>----------------------------- >> Henrik: create editors copy of the requirements document >> based on 3/19 WD and update figure 1. (due next telcon) >> Stuart: forward link to AMG document to dist-app (within >> next day or so?) >> Henrik: develop proposal for merging glossary into spec. >> (due next telon) >> Jeff Kay: look into developing a matrix to be published >> in the upcoming WD highlighting requirements which were >> successfully met by SOAP 1.1.

>>>>CALL ENDED AT 4:33 PM <<<<


References.
[1] http://www.w3.org/2000/xp/Group/1/03/14-minutes
[2] http://www.w3.org/2000/xp/Group/Admin/#pending
[3] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/
[4] http://www.w3.org/2000/xp/Group/xmlp-issues
[5a] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0005.html
[5b] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0159.html
[6] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0024.html
[7] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0010.html