Raw Minutes from 6-11 AM

W3C Web Services Description WG
F2F Meeting - Paris, France
Tuesday 11 June 2002 Morning

Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0045.html

IRC log: http://www.w3.org/2002/06/11-ws-desc-irc

Reqirements Document: http://www.w3.org/TR/2002/WD-ws-desc-reqs-20020429/

*** Subject: R042

Jonathan: Full inheritance? something less?

Jeff: substitutability at service level
      only concern does this group have time to address?
      how complicated are the various solutions? should we just accept requirement and work on it further?

Keith: single port that implements multiple porttypes

Sanjiva: WSDL 1.1 has no definition of a service

Jack: we don't know the implications. We should accept the reqirement but change "should" to "may"

Jonathan: should we drop the reqmt?

David: no

Jonathan: no other reqirement contains the word "may"

Jeff: what about a well defined notion of substitutability

David: this may be more of a 2.0 type of requirement

Jeff: We should accept the requirement as "should" and move on

Jonathan: is there an issue related to this?

Jean-Jacques: When the specification is finished, we should take the spec and compare it to the requirements.

Jonathan: when we finish the specification, we will get a volunteer to do the comparison

*** Subject: R121

Jack: "containing diff parts of WSDL" - nobody can contain diff parts of WSDL documents, only elements

martin: this is not a requirement; if someone wants to stick wsdl into another document, they should start with definitions. This is for people wanting to use WSDL, not for WSDL itself

Jack: I think there is a tag issue. We need a media type

It was agreed to reject the requirement

*** Subject: R120

David: The purpose of this requirement is to have a way to talk about the conceptual part of a WSDL document. The granularity is anything with concepual significance.

Jack: except for operations and ports, everything has a qualified name; they should be fulfilling the requirement. RDF mapping will do this.

Jonathan: proposal to change conceptual element to [? - didn't get captured]

Jeff: we should accept this as a MUST requirement

Jonathan: Must wins a strawpoll

Martin: does the use of xpointer fulfill this requirement?

Jeff: second option is ID

Issue is to define conceptual element

Jonathan: how do we clarify?

action item: Martin is to follow up with Eric Prud'hommeux to see what he means by this requirement

*** Subject: Description language MAY allow restricting flow of messages

Jeff: I propose that we reject this as out-of-scope

Jonathan: Could the requirement be phrased in terms of faults

Jonathan: WG decided that this be marked as reject

*** Subject: collection of ports is a service

Jonathan: is there anything to do on this?
Jeff: no

*** Subject: documentation scenario

Jonathan: wants to put html in there?

Sanjiva: R67 covers this requirement
     This is special case requirement

Jonathan: We'll add this as a requirement and move on

Jonathan: the comments from Arch wg haven't been transmitted to us

*** Subject: Stateful Services

We need to make this more explicit

Jonathan: Is this a new requirement?

would like wsdl to have some way of defining to have separate urls and have mechanism for reverse url
how to describe a transfer from one url to another

jack: binding can say input from one url and results can be fetched from another url

Jonathan: want to something written that better describes the requirement

*** Subject: Primer

david: have an outline. want to solicit ideas
     we're trying to build around examples from simple to complex

sanjiva: would like to have examples showing both RPC and document styles

david: the outline is not yet posted but will be

kevin: We expect the document to use a top-down approach


*** Subject: Extensibility

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0052.html

martin: the processor decides how it processes a binding

glen: if you process the parent, you must process anything in it
     trying to decide first if this is the model we want; second if we have something to drop into spec

jjm: the way we're using "processed" is awkward
     can we actually require that when extensions are incompatible, you should stop

glen: it's up to you how you determine compatibility

jonathan: this is a little vague; do we need this in the spec

glen: this does not talk about the processing model

david: extensions should be "nice" to each other
      semantics of an extesion are totally up to the extension

jonathan: does everyone understand this text and the bulletpoints yesterday to take a strawpoll?

sanjiva: all bindings can be extensions; use of the mechanism is restrictive
     we have general mechanism but are using it for a specific case
     I'm uncomfortable with the direction

glen: the proposed text needs some edits

jonathan: are there any objections? none

*** subject: MEPs

issues: 
- extensibile MEPs, 
- alternate & multiple responses, 
- solicit-response and output oly operations

jjm/glen presentation on soap 1.2 MEPs

<jjmParis> glen, re. interactions between extensions, the text I was referring to is: "MUST clearly specify any known interactions with or changes to the interpretation of the SOAP body. Furthermore, it MUST clearly specify any known interactions with or changes to the interpretation of other SOAP features (whether or not those features are themselves modules). For example, we can imagine a module which encrypts the body and inserts a header containing a checksum a
<jjmParis> "


<plh-paris> question: is one-way addressed?
	question: can we remove /soap/ in the URI MEP?

<plh-paris> I've got my answer for question 2 :)

There was discussion around "time-limited exchange" of request-response mep

<plh-paris> maybe PMEP (for Protocol MEP)?
<plh-paris> TMEP, Transport MEP. AMEP, Application MEP.

<mikem> question: uri for soap 1.2 MEP?

glen: benefit to linking concepts in soap 1.2 to wsdl

<plh-paris> mike: http://www.w3.org/2000/xp/Group/2/06/06/soap12-part2.html#soapsupmep
<SteveLind> soap 1.2 part 1 - messaging framework at http://www.w3.org/TR/soap12-part1/
<mikem> thanks!
<Gudge> http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.xml is the latest ed copy 
<Gudge> http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.xml for part 2 

issue is: does it make sense to replace hard-coded <input> and <output> elements with dynamic syntax using SOAP message and feature names?

jonathan: seems like there is a coordination issue with soap and arch groups
      what do we need to do and what do we tell the other groups?


--------------------------------------------------------------------------------
Steven D. Lind                                Tel: 973-236-6787
180 Park Avenue, Bldg. 2                Fax: 973-236-6452
Room 2G25                                    sdlind@att.com
Florham Park, NJ 07932
--------------------------------------------------------------------------------

Received on Thursday, 13 June 2002 18:04:03 UTC