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
>> Done
>> Draft was not posted, so deferred to next week. Draft expected >> within a day or two.
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.
>> 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.
>> 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.
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.***
>> not covered due to lack of time
>> not covered due to lack of time
>>>>CALL ENDED AT 4:33 PM <<<<