Web Services Description Working Group 2002-03-14 meeting minutes

Web Services Description Working Group 2002-03-14 meeting minutes

Full minutes: http://www.w3.org/2002/ws/desc/2/03/14-minutes (members only)

Participants:
* Keith Ballinger, Microsoft Corporation 
* David Booth, W3C 
* Roberto Chinnici, Sun Microsystems 
* Mike Davoren, W. W. Grainger 
* Tom Jordahl, Macromedia 
* Jacek Kopecky, Systinet 
* Alan Kotok, DISA 
* Sandeep Kumar, Cisco Systems 
* Philippe Le Hégaret, W3C 
* Kevin Canyang Liu, SAP 
* Pallavi Malu, Intel 
* Jonathan Marsh, Microsoft Corporation 
* Mike McHugh, W. W. Grainger 
* Jeff Mischkinsky, Oracle Corporation 
* Dale Moberg, Cyclone Commerce 
* Jean-Jacques Moreau, Canon 
* Radhika Roy, AT&T 
* Jochen Ruetschlin, DaimlerChrysler Research and Technology 
* Arthur Ryman, IBM 
* Waqar Sadiq, Electronic Data Systems 
* Adi Sakala, IONA Technologies 
* Jeffrey Schlimmer, Microsoft Corporation 
* Sandra Swearingen, U.S. Department of Defense, U.S. Air Force 
* William Stumbo, Xerox 
* William Vambenepe, Hewlett-Packard Company 
* Sanjiva Weerawarana, IBM Corporation 
* Don Wright, Lexmark 
* Prasad Yendluri, webMethods, Inc. 

Regrets:
* Michael Champion, Software AG 
* Laurent De Teneuille, L'Echangeur 
* Youenn Fablet, Canon 
* Dietmar Gaertner, Software AG 
* Martin Gudgin, DevelopMentor 
* Dan Kulp, IONA 
* Steve Lind, AT&T 
* Johan Pauhlsson, L'Echangeur 
* Igor Sedukhin, Computer Associates 
* Dave Solo, Citigroup 
* Jerry Thrasher, Lexmark  

Absents:
* Mike Ballantyne, Electronic Data Systems 
* Tim Finin,University of Maryland 
* Mario Jeckle, DaimlerChrysler Research and Technology 
* Michael Mealling, Verisign 
* Stefano Pugliani, Sun 
* Krishna Sankar, Cisco Systems 
* Daniel Schutzer, Citigroup 
* Aaron Skonnard, DevelopMentor

Review of outstanding action items
- Jean-Jaques. Consolidated SOAP 1.2 requirements. [done] 
dbooth; keithba. Draft definitions. [done] 
- Philippe. Set up authors with CVS. [on going] 
- jeffsch; keithba. New text for DR042. [incomplete] 
- keithba. Write up open-content model design. [incomplete] 
- Sandeep. Requirement for defining capabilities for description. [incomplete] 

Agenda items

FACE TO FACE

(See full minutes for details.)

WS-I. 

Regarding groups we should liaison with, we should explicitly add WS-I. It's a new organization and wasn't in place when this WG was formed.

Would very much like to coordinate closely with WS-I, whether the WSDL WG creates a WSDL 1.2 or something else, to leverage experience on un-used features of WSDL 1.1 and avoid re-creating them in a new recommendation. 
Note that both organizations are taking feedback from vendors on WSDL 1.1 issues.

Recognize that it's valid for this WG to indicate to WS-I that we won't be fixing the WSDL 1.1 spec and instead go forward with a more significant redesign. Or not. But see value to being clear 

WS-I: COLLISION OF CHARTER. 

Believe that WS-I will define profiles and best practices. A profile for WSDL could say, for instance, that the schema will be 2001 XSD, may only use certain capabilities within XSD. WS-I profile will be a subset.

Concern that a profile is in fact a spec. Concern re: test cases in both WS-I and in WSDL WG. This WG will be developing a test suite. If we don't consider what's coming from WS-I, there will be problems.

Expect clarifications from WS-I but don't expect them to conflict with the WSDL 1.1 specification.

These may not be conflicting issues. The results of WS-I can feed into this WG efforts; if their profile comes out within the next six months, it can feed into this WG effort in the definition of the next version of WSDL.

Believe that profiles and best practices will evolve along with the specifications, implying that there's little need to go back and rework WSDL 1.1.

Consider the parallels between XML Schema and corresponding groups of vendors. Schema is quite general, while specific groups define and interop based on subsets. However, the XML Schema specification is already at recommendation stage while WSDL 1.1 is not.

Concern that WS-I is at an early stage, and we will have more data on our joint relationship. Don't want to panic about what might / might not happen.

WS-I: CURRENT WSDL WG CHARTER. 

Could focus tightly on fixing interop problems, making minimal improvements, with an accelerated timeframe, to fix interop problems. Alternatively could work on a description language that has similarities to WSDL and a migration path from WSDL 1.1 but would really be a new language.

Winding back, should we fix interop issues in WSDL 1.1 first, or should we re-engineer and create a new WSDL?

Concern that there is no body that maintains WSDL 1.1. 

Originally, some intention to both: (a) clean up WSDL 1.1 quickly, and (b) make more substantial. Believe the scope of WSDL WG is WSDL 1.1, defined to allow the WG to move as fast as possible to fix WSDL 1.1.

Note that language of charter requires justifying any changes on clear technical basis. New features are out of the scope of the WG. Thus, working directly on a WSDL 2.0 implies that we need to request a change in the charter. 

Per charter, all changes must be based on technical reasons. Must prove that a technical requirement is part of WSDL 1.1; if not, it is out of the scope.

Re: technical reasons, can one prove that inheritance is part of WSDL 1.1? Could argue that the spec isn't clear here and therefore even something like inheritance is justified as clarifying.

Concern that our charter does not provide for a significant re-design, only for fixing the WSDL 1.1 spec.

Pushback on charter limiting scope to fixing WSDL 1.1. Another reading looks more like collecting requirements, evaluating against WSDL 1.1, and enhancing where necessary.

Interest in moving forward on defining a clean approach, taking the best of WSDL 1.1, and making a significant investment for the future.

WS-I: AMOUNT OF WORK.

Remind us that key points of a specification are to avoid ambiguity and promote interoperability. If clarifications / best practices need to be defined, that means that there are shortcomings in the specification that should be fixed. If there is such a lack that is a pressing need, then the WSDL WG is the best place to fix those shortcomings.

Acknowledge that there are pretty obvious faults in WSDL that can be traced to problems in the spec, both ambiguities as well as legal combinations that don't make sense. Problems arising today in interop.

Note that WSDL 1.1 specification doesn't include a formal glossary, requirements, formal model.

Note that the XML Protocol WG set out to create SOAP 1.2, but it still took them nearly two years.

Concern that fixing interop issues may not be as simple as people are thinking. (cf. XML Protocol WG note above.) Believe that this effort will undermine the longer-term goal of creating a new WSDL.

Propose that this WG define a subset of WSDL 1.1, call it WSDL 1.2, and after that work on a WSDL 2.0.

Seems like doing a WSDL 1.2 is going to be an adequately challenging task to take up over the next year. Feel that the more we can constrain our scope, the easier our lives are going to be.

Concern that our own struggles to define common terms indicates that we don't share a common understanding (yet) that will be needed for a more significant revision of WSDL.

On the other hand, interoperability is not our only design concern. We are also interested in aligning with the overall W3C architecture.

No clear resolution. Encourage e-mail discussion. May discuss during upcoming face-to-face meeting.

WSDL DOCUMENT LICENSE STATUS.

Ariba copyright statement might have limited our ability to use the WSDL 1.1 draft. However, it appears that the terms from IBM and MS to the W3C allow us to go ahead with WSDL 1.1 as the basis for our working draft, independent of additional information from Ariba. See this as positive since it establishes a status quo and fits in with the most direct reading of our charter.

Recommend adopting WSDL 1.1 as our first working draft, insert issues into that draft, and make changes as necessary.

USAGE SCENARIOS.

General admonishment to focus usage scenarios on usage of _description_ as compared to usage of _web services_.

UC0001. Fire and forget. One-way message with no delivery guarantee.

UC0002. One-way message with some delivery guarantees. Faults may be returned.

Concern that description of this UC is describing an intermediary broker. Note that while the description conveys what the service expects, the delivery semantics could make a difference in what the client needs to do. For instance, if the client wants some delivery guarantees, and the description of the service indicates that there are no such guarantees, the client will need to do some additional application-level retry etc.

Is guaranteed delivery a property of the transport protocol? Not exclusively, but a description includes a binding that conveys transport protocol. 

Independent of this particular use case, see value in providing a specific mapping to WSDL (probably WSDL 1.1 at this point). Along these lines, the Query WG include snippets in their usage scenarios to show exactly what the impact of a scenario is on the XML. As the WG updates the language, they need to refresh these snippets, and if done well, these snippets can become the basis for test cases. Request submitters to contribute snippets.

ACTION: Sandeep will take a first pass at providing snippets for use cases in 2.1 Messaging.

Summary of action items
* 2002.02.14. Jonathan Marsh will map the Face-to-Face meetings 6 months in advance. 
* 2002-03-07. Philippe. Set up authors with CVS. 
* 2002.03.07. Jeffrey and Keith will go propose new text for DR042. 
* 2002.03.07. Keith to discuss open content model design. 
* ?. Sandeep. Requirement for defining capabilities for description. 
* 2002.03.14: DavidB will request a phone bridges for the duration of the meeting. 
* 2002.03.14: Sandeep will take a first pass at providing snippets for use cases in 2.1 Messaging. 

Scribe: Jeffrey Schlimmer