Web Services Description Working Group 2002-02-21 meeting minu

Web Services Description Working Group
2002-02-21 meeting minutes

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

(Note that these are the official minutes, the unapproved version was also sent to the public list.  This version is reposted for completeness.)

Attendance
Participants (35):

- Mike Ballantyne, Electronic Data Systems 
- Keith Ballinger, Microsoft Corporation 
- David Booth, W3C 
- Roberto Chinnici, Sun Microsystems 
- Glen Daniels, Macromedia 
- Mike Davoren, W. W. Grainger 
- Laurent De Teneuille, L'Echangeur 
- Youenn Fablet, Canon 
- Dietmar Gaertner, Software AG 
- Martin Gudgin, Developmentor 
- Mario Jeckle, DaimlerChrysler Research and Technology 
- Tom Jordahl, Macromedia 
- Jacek Kopecky, Systinet 
- Dan Kulp, IONA 
- Sandeep Kumar, Cisco Systems 
- Kevin Canyang Liu, SAP 
- Pallavi Malu, Intel Corporation 
- Jonathan Marsh, Microsoft Corporation (Chair) 
- Mike McHugh, W. W. Grainger 
- Jeff Mischkinsky, Oracle Corporation 
- Dale Moberg, Cyclone Commerce 
- Jean-Jacques Moreau, Canon 
- Johan Pauhlsson, L'Echangeur 
- Waqar Sadiq, Electronic Data Systems 
- Adi Sakala, IONA 
- Krishna Sankar, Cisco Systems 
- Jeffrey Schlimmer, Microsoft Corporation 
- Igor Sedukhin, Computer Associates 
- Sandra Swearingen, U.S. Department of Defense, U.S. Air Force 
- Jerry Thrasher, Lexmark 
- William Vambenepe, Hewlett-Packard Company 
- Sanjiva Weerawarana, IBM Corporation 
- Don Wright, Lexmark 
- Prasad Yendluri, webMethods, Inc. 
- Jochen Ruetschlin, DaimlerChrysler Research and Technology 

Regrets:

- Alan Kotok, DISA 
- Rich Salz, Zolera Systems 
- Daniel Schutzer, Citigroup 
- Philippe Le Hégaret, W3C 

Absents:

- Michael Champion, Software AG 
- Tim Finin, University of Maryland 
- Arthur Ryman, IBM 
- Dave Solo, Citigroup 
- Aaron Skonnard, DevelopMentor 

Agenda
- Approval of Minutes 
- Refined Editor Appointments 
- Usage Scenarios 
- Requirements List 

Review of outstanding action items

2002.02.14. Jonathan Marsh will map the Face-to-Face meetings 6 months in advance. Due date: Unspecified. Status: continued. 

2002.02.14. Jeffrey Schlimmer will assign initial priorities/dispositions to the requirements, and we will then discuss them later. Due date: Unspecified. Status: done. 

2002.02.14. Waqar will jumpstart the creation of user scenarios. Due date: Unspecified. Status: done. 

2002.02.14. Jeffrey will create a specific list of requirements for discussion next week (the top 5 or 10 or whatever he thinks is appropriate). Due date: Next teleconference (Feb. 21, 2002). Status: done. 

Agenda items
Approval of Minutes
Scribe today: Roberto Chinnici.

Resolution: Last week's minutes approved without comment.

Jonathan reminded everybody that minutes should be sent to the private list first, so that confidential information can be filtered.

Refined Editor Appointments
Jonathan announced that Prasad Yendluri would join Waqar Sadiq as an editor for the usage scenario document, and that Krishna Sankar would join Jean-Jacques Moreau and Martin Gugdin as an editor for the binding description document.

No disagreements were voiced.

Usage Scenarios
Jonathan reminded that Waqar had started collecting usage scenarios, and that contributions were welcome. He also stated that the WG would start examining usage scenarios after completion of the work on the requirements document.

Waqar said that he hoped to tie usage scenarios with requirements, and David Booth pointed out the usefulness of use cases to derive requirements.

Jonathan asked whether we should handle the usage scenarios and requirement documents in parallel, and there was agreement on this.

Resolution: Starting with the next conference call, we will spend half of the time on requirements and half on usage scenarios.

Jonathan also proposed to submit all usage scenarios to the ws-arch WG for consideration. No disagreements were voiced.

Jonathan then asked people for opinions on the issue of service references.

Jeffrey and David Booth offered DR085 and UC012 as pointers to this issue.

Waqar said that the ws-arch WG should deal with it first.

Sanjiva said that the result of this WG should enable service references.

Igor asked whether we should wait for the ws-arch WG to sort out this issue, and Waqar seconded him by making an analogy with object references in the CORBA world. Waqar then added that we need a deeper understanding of references before we can handle them in this WG.

Jonathan pointed out that Jean-Jacques had forwarded a message by Noah Mendelssohn (originally sent to the xml-dist-app WG) on this very issue. He also said that he wasn't sure whether it should be treated as a requirement and asked for opinions on it.

Nobody seemed to be familiar with the message, so Jonathan proposed to examine it at a later time.

Jean-Jacques said that he expected the ws-arch WG to take a position on this issue, and Jonathan proposed to wait and follow the work of the ws-arch WG on it.

Jeff Mischkinsky proposed to mark it as an action item to make sure we follow up on it.

Jonathan pointed out that we already have use cases and requirements covering most of this issue, and he asked whether this should be on the issue list.

Sanjiva proposed to keep it as a requirement.

At this point the discussion fell through to the next agenda item, requirements.

Requirements List
Jonathan asked how we should deal with requirements that come in after the grace period we set initially.

Jeffrey described the notation used in the current draft of the requirements document: "DR" for draft requirements and "R" for requirements that have been accepted.

Igor asked how rejected requirements would be handled, and Jeff Mischkinsky proposed to use a "NR" prefix for them. Jonathan then pointed out that the "NR" category would make it easier to sort out duplicate requirements, as well as previously rejected ones.

There was general agreement on this classification for requirements.

Resolution: It was agreed to use the "R" prefix for requirements, "DR" for draft requirements -- in particular requirements added after the grace period -- and "NR" for requirements that have been rejected.

Requirement DR001
The discussion initially focused on what "not assuming any particular mode of communication between peers" meant.

David Booth offered as an explanation that if we intend to exclude some modes of communication, we'd better have a good reason to do so.

Jonathan pointed out that this requirement was drafted from the charter.

There was general agreement that we need to clarify this requirement, and David Booth offered to replace the offending words with the following: "not assuming any particular transport or protocol for communication between peers".

Resolution: This wording was accepted and nobody objected to making it requirement R001.

Requirement DR004:
Jeffrey and Jonathan pointed out that DR003 and DR004 look similar.

Dale said that DR004 explicitely required the use of the XML Infoset model, while DR003 was more of a meta-requirement and didn't mandate that usage.

Martin pointed out the link between DR003 and DR008 and said that the MUSTs there should not be weakened to SHOULDs.

Glen said that DR003 was not specific enough; Keith then suggested to be more specific about MUSTs and warned against a MUST forcing us to use a tool which is not the best for the job.

Jonathan asked for objections to adopting DR004 as is, and nobody objected.

Resolution: DR004 accepted, making it into R004.

Requirement DR008:
Martin said that the requirement, as written, seemed to talk only about the schema for the description language that this WG will produce. He then proposed to consider two aspects of this problem: whether the specification should use the latest version of schema, and whether it should allow people to use other schema versions in their documents.

Jonathan proposed to split the requirements in two, following Martin's proposal.

Resolution: Create a new R-requirement stating that the specification produced by this WG will use the latest schema language.

The ensuing discussion centered around extensibility and what requirements to place on processors in terms of the version of XML schema that they should support.

Discussion:

Glen: we should let people use WSDL 1.2 to describe services defined previously.

Jacek: we cannot preclude the use of other schema languages, including older schema version.

Sanjiva agrees with Jacek.

Martin: does it mean we'll support all old versions of schema?

???: not explicitely, as long as we provide the necessary extensibility mechanisms.

Glen: would conformance requirements mandate support for older schemas?

Tom Jordahl: should not require old scheme, but allow it.

Tom Jordahl: we can set a direction here for other WG's too.

Glen: how are we going to phrase it? "any description you see that uses 2001 schema MUST be dealt with, everything else is covered by the extensibility clause".

Glen: or we could say "you MUST support previous versions of schema too".

Jeff Mischkinsky: keep it to the current version only.

Martin: WSDL MUST support W3C XML Schema 1.0 as a mechanism for describing types etc. and WSDL MUST provide an extensibility mechanism allowing other schema languages.

Jonathan: so what's left of DR008 is the requirements on processors.

Jeff Mischkinsky: the conformance statement in the requirements must be clear.

Jeff Mischkinsky: this is a meta discussion.

Jonathan: it's useful to have the requirements be as specific as we can.

Jonathan: if we cannot be specific, let's word this out so that we have some freedom later to do the right thing.

David Booth: it's "MUST support the latest schema rec and MUST support extensibility"

Glen: +1 to specifying 1.0.

Martin: we should not use "latest", because we don't know what future schema versions (esp. 1.1) will look like.

Jonathan: it's unlikely that there'll be a new schema rec before we come out.

Jacek: we shouldn't require support for schema 1.0, it's not well adapted to all uses.

Gudge: how can we test conformance then?

???: conformance can be split in two: one part not using types, one part using types (and specifying there which schema language to use).

WSDL 1.1 as of now requires schema.

Sanjiva: "element" and "type" in "part" require schema.

Jacek: it's not really explicit.

Sanjiva: the spec is vague, but that was the intent.

Jonathan: I have heard that Relax NG could be combined with the XML schema datatypes.

Martin: Relax NG doesn't have a type system for complex types.

Waqar: it's an extensibility issue, there's going to be many more; the issue is really about conformance testing.

Martin: Relax NG does have a type system for simple types ( it's XML Schema 1.0 Part 2 ;-) )

Waqar: if you look at all extensibility elements, it's going to be hard to write conformance on all them.

Jonathan: so you're saying: we shouldn't put conformance reqs in the overall reqs document?

Waqar: yes.

OK, I can see now how WSDL 1.1 message/part requires XML Schema, but I don't think we need to keep this requirement

Jonathan: "WSDL must support XML schema 1.0 as a mechanism to define types" without stating any conformance requirements (wording originally from Gudge).

???: why do we need to state extensibility explicitely?

Jonathan: it's nice to have a requirement for what we want to do here.

???: are we going to word all of what we want to retain from WSDL 1.1 as requirements?

Jonathan: I think we should.

Jonathan: in Gudge's wording, do we want to make sure that it hasn't any conformance implications?

(some people agreed)

Jeff Mischkinsky: we split the requirement in two, right?

Jonathan: yes

Jeffrey: "the schema for the spec and examples will be written using the latest publicly available schema spec".

Jeffery: "WSDL must support the XML schema 1.0 type system".

Jeffrey: (third item): "WSDL must support extensible type systems".

???: can we work on the exact wording off line?

Jeffrey: I'll split the requirements in the three ones above.

Jonathan: does anyone have objections?

Jeff Mischkinsky: I'm not confortable with support for other schemas which are not W3C recs.

Gudge: they don't have to be used, though.

Jeff Mischkinsky: if I'm writing a WSDL 1.2 processor, what do I have to support exactly?

Sanjiva: we need a mechanism to define an infoset, and xml schema lets us do that, but we don't preclude other mechanisms.

Jonathan: isn't it an interoperability problem?

Jeff Mischkinsky: extensions can become a way to create WSDL dialects (which is bad -- [my words, scribe's note])

Jacek: if people try to use schema languages that are substantially different from XML schema, it will break some of the assumptions we made.

Tom Jordahl: extensibility elements should be optional, conformance-wise.

Sanjiva: I agree.

Tom Jordahl: we can agree on XML schema 1.0 be valid, and not mention any future schema languages (because they don't exist yet), *and* make older schema versions optional (hence not relevant for conformance).

Jonathan: can we solve this by using SHOULD in that requirement?

Jeff Mischkinsky: assume we base it on schema, revisit it only if we run into problem.

Sanjiva: WSDL 1.1 allows you to use other type systems but defines support for schema.

Keith:we shouldn't marginalize other W3C standards.

Tom Jordahl: we can only spec what exists today. let's not spend time discuss the hypothetical 1.1 XML schema.

David Booth: Perhaps we need to further split this requirement: (1) we REQUIRE that XML Schema be supported; and (2) we SHOULD allow extensions?

Sanjiva: I would prefer (1) XML Schema MUST be supported, and (2) other type systems MUST be supported via extensibility (but we will not define them).

David Booth: I agree with sanjiva.

???: two different aspects: (1) it must be possible to extend an element, (2) it is possible to extend and here's an extension we defined in the spec.

Sanjiva: keep only the most up-to-date schema version as MUST.

Jacek: important parts of SOAP are modeled as extensions (in the xmlp WG); in WSDL, we can specify a normative extension for XML Schema 1.0.

Sanjiva: that's what 1.1 does.

Jacek: in 1.1, "element" and "type" are not really extensions, because they are not namespace-qualified.

Jacek: if we make them ns-qualified, they become extensions.

Sanjiva: we felt a standard extension was useful, but point well taken.

Jonathan: we have two positions on XML Schema 1.0: (1) require it for conformance, (2) make all type systems equal.

Tom Jordahl: do the simplest thing for users, require XML Schema 1.0 and make everything else optional.

Jonathan: we should take this to the list and try to reach some wording everyone agrees with.

Sanjiva:[1] XML Schema MUST be supported, [2] Other type systems MUST be possible via extensibility

???: I'm worried about extensions and interoperability.

Glen: +1

Sanjiva: the spec should be open to extensions, but conformance requirements don't include support for optional extensions.

Youenn, Keith: +1

Jacek: wording is OK as long as it doesn't preclude XML Schema being modeled as an extension.

Jonathan: "XML schema 1.0 must be supported, other type systems must be allowed via extensibility".

Glen: I believe we are in fact saying that implementations that do not support Schema 1.0 are NOT going to be compliant. I'm not sure if that's where you [Jacek] want us to be

Resolution: Create two new requirements stating that XML schema 1.0 must be supported, other type systems must be allowed via extensibility.

Requirements DR011/DR013
No objections to DR011 being made into a full requirement.

Jeff Mischkinsky objected that simplicity was not misurable, and Martin replied that complexity could be judged by comparison with other things.

David Booth pointed out that DR013 was unnecessary given R011, and everybody agreed.

The discussion moved back to R011, and Tom Jordahl asked for an explanation of the meaning of "decentralization" in this context. ??? and Jonathan offered an explanation based on the absence of a central registry and the use of URIs.

There was agreement on the need to clarify what those requirements actually meant, and Jeffrey offered to create mother lode requirements for "simplicity", "modularity" and "decentralization", keeping DR011/DR013 at the draft stage for the time being.

Resolution: Introduce new requirements focused on the three aspects mentioned in DR011: simplicity, modularity and decentralization.

Requirement DR021
Jonathan remarked that the first part of this requirement was already taken care of in DR004.

Martin proposed to remove the term "interface" and to clarify what is meant by that in another requirement.

Jonathan offered the following wording for DR021: "The description language must describe the messages generated and accepted by the web service".

No objections were raised.

Resolution: Change the wording of DR021 to the one above and make it R021.

Requirement DR023
This requirement was found redundant with R021 and the resolution for DR008.

Roberto asked whether the "data type" aspect of DR023 was covered by R021 and Sanjiva confirmed that it was.

Resolution: Mark DR023 as redundant

ACTION: Jeffrey will send an updated requirements document to the list. 

ACTION: Jeffrey will seed the discussion on the public mailing list with a few choice issues. 

Summary of new action items
2002.02.21. Jeffrey will send an updated requirements document to the list. Due date: Unspecified. 
2002.02.21. Jeffrey will seed the discussion on the public mailing list with a few choice issues. Due date: Unspecified. 
2002.02.14. Jonathan Marsh will map the Face-to-Face meetings 6 months in advance. Due date: Unspecified. 

--------------------------------------------------------------------------------

Scribe: Roberto Chinnici

Received on Thursday, 28 February 2002 13:52:13 UTC