Minutes 9-11 Sept WS Desc FTF meeting (consolidated)

WS Desc F2F September 2002
DISA, Alexandria VA

Attendees:
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Dietmar Gaertner       Software AG
 Martin Gudgin          Microsoft
 Tom Jordahl            Macromedia
 Sandeep Kumar          Cisco Systems
 Philippe Le Hégaret    W3C
 Steve Lind             AT&T	
 Kevin Canyang Liu      SAP
 Michael Mahan          Nokia
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Arthur Ryman           IBM
 Adi Sakala             IONA Technologies
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 Steve Tuecke           Global Grid Forum
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM
 Joyce Yang             Oracle
 Prasad Yendluri        webMethods, Inc.

Invited Experts:
 Erik Ackerman          Lexmark
 Hao He                 Thomson
 Brand Niemann          EPA

By phone:
 Youenn Fablet          Canon
 Amelia Lewis           TIBCO
 Dale Moberg            Cyclone Commerce
 Jean-Jacques Moreau    Canon
 Don Mullen             Tibco

Agenda: [1]
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0027.html

IRC logs: [2], [3], [4]
[2] http://www.w3.org/2002/09/09-ws-desc-irc (members only)
[3] http://www.w3.org/2002/09/10-ws-desc-irc (members only)
[4] http://www.w3.org/2002/09/11-ws-desc-irc (members only)

---------------------------------------------------------------------------
9 Sep 2002, morning session
Scribe: William Vambenepe
---------------------------------------------------------------------------
Introduction 

Our host Alan Kotok welcomes us to DISA 
We go around the room, people introducing themselves 

--------------------------------------------------------------------------------
Spec update 

Requirements: 

One requirement still in draft stage.  Gudge still waiting for clarifications from Eric P. on one RDF-related issue.  We will discuss the last remaining draft requirement at some point during this F2F.

Usage scenarios: 

Sandeep doesn't know exact status.  This is a joint task force, seems that the ball is in architecture work group.  We need to know whether this current set up will work for us or we need an alternate plan for usage scenarios.

Primer: 

Current draft [5] can be ready for first publication in november (DavidB estimation). Goal: publish draft of primer next time we publish other docs (part 1 and 2).  There is potential duplication of effort between the introduction of the primer and some work done by the architecture group (because intro of primer provides a general intro to web services, including soap). This section could be shared with other WS work groups. DavidB has asked Mike Champion to bring this up to coordination group. Architecture document provides standard definitions that DavidB intends to reference in the primer.  Kevin & DavidB invite comments from work group members on current draft of primer (there is a link to it from the work group home page).

[5] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-primer.html

RDF Mapping:

Anyone thought about it or still waiting for the spec to stabilize?
Gudge: eric has done some work in the area (also did the previous mappng) 
Roberto: aren't we waiting to long to bring RDF into the picture? What if there are problems that we don't notice until late 
Phillipe: RDF mapping for WSDL: http://lists.w3.org/Archives/Public/www-ws-desc/2002Feb/0103.html 
Jon: abstract model work in some ways similar to RDF mapping, will catch some problems if there are 

Parts 1 and 2:

Gudge: need more work on interface between part 2 and 1 
Next publication date? 
Sanjiva: late October would be ok 
Gudge: need to make sure component model is complete, need to edit some of the text for clarity 

---------------------------------------------------------------------------
Abstract Model 

Discussion lead by Gudge. Gudge giving presentation on abstract component model 

Abstract model working draft [6].

[6] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.am.html 

Type systems 

Discussion: should we support type systems that don't represent the xml infoset? 
New issue: we need to include type systems that don't describe xml 
Jonathan remarks that this is something to be decided by arch group, or at least with the arch group 
JeffM: then how do we define web services? what restricts it? 

Processing model 

Question: is there a processing model for understanding a wsdl document that you must follow (e.g. understand xinclude...)? 
Answer: not currently 
DavidB: doesn't that create interop problems? 
Answer: maybe but in this case it's an xml problem, not a wsdl problem so this is not for us to solve 
Question: or do we want to create a solution to this pb specific to wsdl docs? 
WS-I will probably address this problem 
New issue: do we need to define a processing model specific to wsdl? 
Right now, only processing model info we have is the extensibility mechanism 
If xml schema is the only type system, then do we need the <message>? can we eliminate it? This issue is already in the doc 

Discussion: can you import from a doc in the same namespace as you? There is already an issue on this 

The abstract Model needs to say something about name conflicts generating errors 

Correction: "set of part definitions" needs to be changed to "list of part definitions" in sections 2.2.3 and 2.2.1 

The component model in Gudge's document is not what he thinks it should be but what the current spec describes. It is also to be used to facilitate discussions about the component model 

Correction: rather than type and element attribute on part, have a variety of property to be more extensible 

Question from DavidB: are parts important enough? Answer: we have an issue on this, decision to leave it for 1.2, waiting for 2.0 for more changes 

Question: do we need to identify everything in wsdl by URIs? It would be good for RDF mapping. There is talk in the TAG of way to turn QNAMEs into URIs 

Correction: Need to rework a part of section 2.5.2 to take into account cases where faults are not allowed 

Correction: Cut and paste error in section 2.5.2.2 

Issue: in serviceType - {portTypes} is a set of portType references (QNames) (from Arthur) 

Question: how much explanation of the purpose of the different elements do we need to put in the abstract model? We need some of this in the abstract model (without substituting to Primer). 

Discussion of relationship between extensions and the component model 

Roberto: how does extensibility work w/ the abstract model? 
We need to say something to the effect of "this list of properties may be augmented by extensions" and remove the {extensions} properties 
Igor: the point was to keep abstract model to the effects of base WSDL and let extensions augment the model 
Arthur: editorial comment: clearer to use the expression "a foo reference" rather than "a named foo" since "a named foo" implies we are adding a name to it, e.g. "a portType is a named set of operations", or "a part is a named message component" 

Question: should we formalize the separation between generic definition of a web service and a specific web service? 

Do we need to formalize this common usage patern? 
What is the abstract interface of a web service? do we need to specify that? e.g., is the binding part of the abstract interface? Different people have different answers to this question 
Discussion of assigning a different namespace to each wsdl element. What would this bring? 
In the spec we could classify elements as being part of a class of web services or a web service instance. Sanjiva: instance and class are confusing terms, this is not a problem we need to solve 
There is a part in the 1.1 spec that addresses that, is this sufficient? 
Igor: we need examples that cover a variety of use cases (creating a web service, an agent...) 
New issue: add the rational and design guidelines for using import in the import section of the spec. 

---------------------------------------------------------------------------
9 Sep 2002, afternoon session
Scribe: Joyce Yang
---------------------------------------------------------------------------
Sanjiva's binding proposal [3] and slides [4]

[3] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/att-0117/01-bindings-2002-07-24.html 
[4] http://www.w3.org/2002/09/10-wsd/all.htm

The proposal in 1.2 is to support serviceType and allow reusable binding and fix up address in <service>.  Kevin raises the overwriting issue.  Sanjiva clarifies the child level binding details overwrite the parent level binding details.

Sanjiva: <address> is for the entire service 

Gudge: asks why <service> needs an <address>? 

Sanjiva: <address> in <service> specifies the address of the "service" 

More discussions about the <address> in <service> issue 

Gudge: why isn't the <address> in <port>? 

Sanjiva: if we wsdl 1.1 aside for now, we probably don't need the concept of port. The abstraction of <service> is <serviceType>.

Arthur: You can have multiple instances of same serviceType, and this can be addressed by <port> 

Sanjiva: You can have different <service>s. The <address> in <service> is defined in the wsdl space, not extended element.

Roberto: should we force to have <address> in syntax? 

Gudge: how is that different from extension? 

Sanjiva: <address> is just the characteristic of <service> 

DavidB: If you don't have a address, you don't have a web service 

JeffM: <address> is just one of the pieces to use web services 

Marsh: what's the disagreement? 

Gudge: for <address> of <service>, is it independent of <binding> or not 

DavidB: summarize this is the issue of current disagreement 

JeffM: what's the meaning of <address> independent of <binding>? 

xxx: <service> has an address and <binding> explains what it is 

Arthur: issue: the bindings attribute lists a sequence of bindings. the spec must state overriding semantics, e.g. does a binding override the bindings that appear after it (if they define the same info) 

There is no agreement. 

Kevin describes his suggestion on Sanjiva's proposal. 

Kevin: Propose a <bindingType> construct to reuse binding information.

Tom: Is this is replacement of Sanjiva's proposal or enhancement? 

Kevin: it's semantically the same, but new syntax.

Sanjiva: in wsdl 1.1, binding specifies how and where to access the service description. The binding is the concept of binding, not necessary the <binding> element.

Sanjiva: service must sit somewhere.

WilliamV: there must be some other characteristic other than address.  The issue is to specify the common stuff and then the specific stuff.

JeffM: solving <address> problem will solve 99% of the problem. we have too many abstractions.

DavidB: It looks like people agree Sanjiva's concept on how and where to access the service.

Marsh: it looks like people agree on Sanjiva's concept.

Sanjiva: the issue is how to specify it in syntax.

JeffM: it would be helpful to have a share understanding on the underlying concepts when discussing concrete syntax.

Marsh: what do we want with this?

Sanjiva: the simple thing is we have serviceType, and we need to do something with it 

Gudge: are the binding details in <serviceType> specify default values for <portType>s? 

Sanjiva: that depends 

Marsh: this is a good chance to solve big issue like this 

Roberto: we need more examples 

Marsh: Roberto has question whether we need the new serviceType binding,..., etc 

Roberto: the existing constructs are enough. 

Marsh: take this back to email? 

Sanjiva: It has been on email for 6(?) weeks 

DavidB: as a primer editor, prefer logistics on serviceType 

Sanjiva: agree with Roberto that existing constructs is enough, but it really depends on whether we want to do more than this 

DavidB: It ugly not to do anything with it.  We have an abstract concept of a service, defined by a hierarchy of concepts: ServiceType, PortType, Operation, Messages. Binding supplies specifics for an implementation, but currently there is no way to specify implementaiton information for a Service as a whole. Currently we only define ways to supply implementation info at the port level. 

Marsh: component model for part 2? 

Gudge: not sure. probably adding properties to current components 

Marsh: how do want to move forward on this?

Sanjiva: do you want to add serviceType as the first class element with binding? 

Marsh: poll on that 
17 favor, 2 oppose 

Sanjiva: you can put different address 

Sanjiva: need more concreate example from Gudge 

Gudge: we don't really know whether we want different things on different portType. 

Adi: in the proposal, can you do two bindings for the same portType? 

Sanjiva: yes, create two <portType>s in <binding>/<serviceType> 
In the Sanjiva proposal can two or more portTypes have different binding properties? e.g. can one portType be made available over SOAP/HTTP and another over HTTP GET?  You can also do that in WSDL 1.1 

Marsh: is this desirable or necessary? 

How do I expose the same portType over multiple transports? 

Current proposal's section 3.2 does not support that. We could extend it to do it. 

DavidB: Is that intended to put binding details hierarchical? 

Gudge: yes 

Gudge emphasizes the limitation 

Marsh: is this introduced by serviceType or by Sanjiva's proposal? 

Sandeep: the issue is can you do multiple <serviceType>s 

Sanjiva: 3.1 is fine, and 3.2 has problem 

Gudge: In WSDL 1.1 I could say portTypeA == SOAP/HTTP, portTypeB == SOAP/HTTP & SOAP/SMTP how would I say this in WSDL 1.2 with Sanjiva's proposal? 

Sanjiva: We should support address at <port> for <porttype> for backward compatibility. 

Marsh: redo 3.2 proposal? 

New issue: In WSDL 1.1 I could say portTypeA == SOAP/HTTP, portTypeB == SOAP/HTTP & SOAP/SMTP how would I say this in WSDL 1.2 with Sanjiva's proposal?
More discussions on how and whether to fix session 3.2 
Sanjiva agrees to redo 3.2 tonight. 

The purpose is to address the backward compatibility issue raised by Gudge (recorded as New issue above). 

Sanjiva: we need progress 

Marsh: we can adjust agenda. agree on Sanjiva that making progess on emails may be hard 

Does a service have an address independent from port addresses? 

Is Address binding specific (or associated with a service)? 

Do we need ports at all? 

Should service\port reference bindings if bindings must specify a service type? 

Sanjiva confirms to redo the proposal and everyone is posting issues. 

How would one expose multiple instances of a port type with different bindings? (A backward compat issue with WSDL 1.1) 

If a port refers to a binding and that binding talks about a serviceType, how does this affect the service the port belongs to? 


---------------------------------------------------------------------------
Asymmetry between SOAP body and SOAP header (Kevin) 

Marsh: move on to talk about Issue 51 in the agenda 

Kevin: In wsdl 1.1, <soap:header> has a message attribute. (some slide presentation from kevin) 

Sanjiva: SOAP header message is 100% broken. Issue 51 needs to be restated as: should we remove soap:header@message or make it optional at least? 

Discussion going on on the meaning of message in soap binding... 

Quick summary on the discussion: Gudge doesn't see Soap header is broken 

Gudge: do you need to define all the headers in the porttype? the answer is no. 

Some agreement on Gudge. 

Sanjiva: Fix portType to support more protocols. 

Roberto: defines feature at the abstract level, and reuse it at the binding level 

Allen: additional abstract layer? 

Some disagreements on that. 

Marsh: conclusion? 

Kevin: continue discuss or not an issue? 

Some discussions are going on. 

Tom: it seems like we can either skip message attribute or just leave it along. 
more discussions 

Tom: prefer my proposal that <soap:header element=...>, and drop <part> in <soap:header> 

Roberto: that doesn't solve problem of soap encoded header 

Gudge: Proposal is as follows: 
- Drop parts AII from soap:body 
- Drop message and part AIIs from soap:header 
- Add element, type and localname AIIs to soap:header 
- element and type are mutually exclusive 
- if type appears then localname and namespace AIIs MUST appear 
- if element appears then localname and namespace are not needed 

kevinL: re:drop parts AII from soap:body - if this is the case, we need to make it very clear in the spec that input/message only specify parts for soap body, all headers should NOT be included in that message 

JMarsh composes the proposals from Gudge and Kevin 

[This proposal was accepted.]

sanjiva: The problem of describing contextual data is an abstract service level concept. Providing a SOAP-only solution is not the right way to do it; I believe the right way to do it is to design a solution for the abstract problem and then solve the SOAP case as a binding of the abstract solution. 

Sanjiva: same soap:binding works for outbound? 

Igor: yes, according to the doc 

Marsh asks Kevin to adopt the new proposals 

Gudge: propose make the same changes to soap:headerfault 

Igor: missing header on the fault? 

Gudge: Defined in part2 session 2.7 

Roberto: any example using soap header fault? 

Gudge: no 

Gudge: Issue: We need a way to define the headers that are allowed in a fault message.


---------------------------------------------------------------------------
New issue "Can 'use' be eliminated?"

Arthur: preferred position is to use literal only, but WS-i supports literal 

Gudge: lots usage to use existing combinations. we can't drop it. 

Marsh: close the issue? 
We should make a note to clarify the interaction between use, style, element, type etc. 

Gudge:  ACTION: Check whether there is already an issue against Part 2: can you define different encodingStyles for different children of soap:Body ( message parts ) 

Marsh: can we continue use everything in soap 1.2? 

[Not accepted - use attribute will stay.]


Arthur: proposal: disallow the empty string as a value of the encodingStyle attribute and instead use the URI for no encodingStyle that is defined in SOAP 1.2 

Roberto: define default encodingStyle value? 

Marsh: are we doing both soap 1.1 and 1.2 binding? I guess we are doing 1.2 only. 
encodingStyle attribute with the value http://www.w3.org/2002/06/encoding/none means that no claims are made about encoding ( it's 'literal literal' ) 

Gudge: encodingStyle attribute with a value of "" is not allowed 

[Accepted]
 

---------------------------------------------------------------------------
10 Sep 2002, morning session
Scribe: Martin Gudgin
---------------------------------------------------------------------------

Discussion of serviceType reuse 

Steve: General concensus that we need some kind of extension mechanism.  If WSDL 1.2 doesn't solve it, OGSI will have to solve it.  Simple serviceType extension; right now serviceType aggregates portTypes.  Want to add an element with a reference to another serviceType.  OGSI want to be able to have a model with portTypes as the basic unit of abstraction ( interface ).  Want to model services composed of these, 'flat' serviceType ( with no extension ) doesn't give us a rich enough model.  Want there to be a relationship between the 'base' serviceType and the 'derived' serviceType. For clients, if built against A, can also talk to C if C derives from A.  Grid Service defines 4 or 5 porttypes. Want to define a canonical serviceType, then extend.  Taking the Data model from DMTS SIM, and rendering it into a portType instance model, want to be able to combine stuff together.  If we have two of the same portTypes 'inherited' we would deal with such a collision by ditching one.

Tom: How does this affect bindings? 

Gudge: If we do the extension in such a way that it's an abstraction type, then it is a syntactic thing. The client just looks to see if a port type is supported or not. 

Gudge: If we do the extension so that it's a syntactic thing, then the client looks a the list of port types to see if it supports type A, B, C. 

Tom: What if there are > 1 bindings? 

Gudge: It's just another thing to consider. We don't get interoperability unless both endpoints support the same binding of the same port type. This doesn't add any complications we don't already have. 

tjordahl: How does the binding affect *this, not the other way around was my quiestion 

Gudge: overlaying some binding information ( annotating specific things in the tree; operations, portTypes etc ) as long as the annotations on the things you care about are what you expect then you're fine. If the annotation ( binding details ) are not what you want, you can't talk to the service. 

Tom: Could cut and paste and just have multiple serviceTypes 

Steve: there are some semantics associated with a given serviceType 

GudgeScrb: The semantics of a serviceType with PTs A,B,C and a serviceType that happens to have A,B,C by extension may be differnt. 

Roberto: Seems to have few or no side-effects, and we need to do something. Only one more concept we have to explain.

dbooth: So you mean the semantics of a particular ServiceType with PortTypes A, B, C may be different from a ServiceType that happens to have portTypes A, B, C whose semantics are simply the union of the semantics of portTypes A, B, C. 

Steve: Perhaps.  May have two services that can receive same message and behave differently. Tool wants to know it can send a message no more.

Jeffsch: let's take STs A,B,C, if I discover a 'C' and I want to know it's an 'A' how do I figure it out?

Steve: want to be able to derive C from BOTH B and A 

Steve: want to know that a given service 'implements' a named service type 
Issue: Do we need to define equivalence? 
Issue: If the answer to previous issue is yes, them how should equivalence be defined 

Steve: We care about QName equivalence 

Sanjiva: For the minutes: We have disagreement on whether WSDL is about wire level or not. My position: WSDL is not about wire level equivalence. Gudge says it is. 

Gudge: I said, 'Wire-level interop' 

Sanjiva: OK I disagree that its about wire level interop 

Sandeep: There are several ways of defining equivalence. And what that means. Bindings may play a role ( sorry, didn't catch all the detail ) 

KevinL: I agree with Gudge that WSDL is about establishing a common understanding of the message to be exchanged.

Steve: may not know anyway even when you find a serviceType or a portType whether you can invoke all the operations because some operations may not be bound 

JMarsh: Is this related to the UPNP example: ( the TV and picture-in-picture TV ) 

Sanjiva: We have an issue already in the spec for that 

Steve: For our purposes we don't need multiple instances of a single portType 

JMarsh: Another UPNP issue was wanting to find a common portType and allow vendors to add functionality 

JeffSch: UPNP had scenarios for extending porttype and servicetype. Suspect UPNP would also use the serviceType extension mechanism.  UPNP would probably also want PT extension 

dbooth: seems you could have more than one 'instance' of a portType 

Steve: No, because it is defined a set union of the *portTypes* in the serviceTypes 

Steve: Slightly more radical proposal. What are the units the set union is on? We are trying to get the list of portTypes. You could push down and do set union on operations by doing extension of portTypes and then throw away serviceType altogether. Doing union at the PT level may not ultimately be useful, better at op level.

dbooth: If the semantivs of an ST is MORe than the union of the PTs, then it doesn't make sense to just get the union of the portTypes 

Gudge: They way we figure out which port types a service type includes, is by walking up the tree, and putting them all together.  To figure out the semantics of that service type, you look at its name and all the names of the service types it extends. 

roberto: the name of portType is what defines the semantics.  Same for serviceTypes 

Gudge: Could have two port types with the same operations, they can have different QNames and different semantics. 

dbooth: If two port types have the same operations and QNames, but are included in different service types, then the service types have different semantics. The meaning of messages is determined by the QName of the port type and service type even if the messages are exactly the same on the wire. 

No, the meaning is determined solely by the service type. 

JMarsh: proposal is to add a 'bases' property to service type component ( set of QNames of serviceTypes this ST extends ), Modification to mapping of port types property, syntax for expressing the 'bases' property.

dbooth: If semantics is determined by the serviceType, if we have two serviceTypes A and B that use the same portType, and then derive serviceType C from A and B, does it make sense? I don't think so 

Steve: Yes, there may be cases where this does not make sense. 

Arthur: seems to be interface inheritance, one servicetype and inherit one or more service types, why not just roll up portType and serviceType and do inheritance at that level 

Steve: One question is what names do you attach semantics to. Is it at the serviceType level or portType level.  Maybe it doens't matter, maybe semantics would work at either level.

Arthur: Don't see any use to having serviceType and portType given the.... 

Steve: I tend to agree that flattening would be better 

JMarsh: Do we want to drill down into more radical proposal ( to flatten serviceType and portType ) 

Arthur: Given that serviceTypes are causing us more work, why not remove them in favour of extensible portTypes and do things at the operation level 

roberto: extensible portTypes is a radical change. people already have a notion of portType. and extending them makes things more complicated. 

sanjiva: My concern is that if we do serviceTypes we should do it properly. It will change the programming model. If we can't change anything then what are we doing here? 

Arthur: portType is mapped to interface ( typically ), and interface inheritance is well understood. 

gudge: Do we have the notion of one interface extending others? 

Gudge: I guess we do.... 

Arthur: Another way to approach this is to have the concept of a serviceReference. So you could ask a service to give you a reference to another service, a 'sub' component.  This could deal with the UPNP two tuner case.

Steve: But you lose offline modelling capabilites and it makes discovery harder 

Arthur: Service would have operations called 'GetTuner1' 'GetTuner2' and each would return a 'Tuner' Service 

JMarsh: How do we move forward on this. Could take some time, but schedule may not be realistic 
first straw poll: Do nothing vs do extension 
second straw poll: extend serviceTypes vs more radical proposal to extend portTypes and rollup serviceTypes 

Tom: This makes things more complicated. And doesn't make the 80/20 cut 
I'd like to have a new issue added somewhere: What's WSDL about - wire level interop for SOAP or for describing servies irrespective of bindings. 

Gudge: If you look at some of things we hate in other languages; e.g., in schema where you have to repeat things that you're inheriting.

Tom: Tooling doesn't have a problem with this. 

Steve: port/serviceTypes will be generated by humans. Binding level stuff will be done by machines 

dbooth: market situation, then extension would be useful 

Steve: Airline example. Standard buyticket portType that all airlines provide. Each airline provides the base and then extends 

jeffsch: vertical orgs WILL want to do this. Cut and paste not the answer. If we don't do it, then lots of other people will do it 

Steve: We launched down this path, last autumn. It became obvious to us that extension was the one piece we needed 

JeffM: How do we handle versioning? cut'n'paste doesn't have a versioning problem 

Jeffsch: Use different QNames 

Arthur: problem with versioning is don't want to break existing clients.  Inheritance allows us to add stuff without changing things.  Old clients see old portType, new clients see new stuff too.

Steve: This is the road we went down WRT OGSI. portTypes are immutable in OGSI docs. If adding portTypes or adding operations, back-compat extensions handled cleanly. More complicated stuff needs more thought.

roberto: If we were to do portType extensions, would we stop at the operation level, or would we drill down into the messages of an operation 

arthur: No, we shouldn't do that. Similar to operation overloading. 

roberto: in overloading, two operations, same name different arguments. In this case, you *replace* an operation 

Arthur: We don't want to go there 

sanjiva: we've had interface inheritance for a long time. There are no languages that support operation redefining. 

roberto: You can get on the wire compat by defining a struct with x fields and then later add more fields 

Arthur: In WSDL you should have a schema that descibes the XML. You could change that but you might break existing clients 

gudge: In designing any spec, there are multiple layers, and you can put functionality in a variety of these but part of the design process is selecting these. I agree with Arthur that it doesn't make sense to do it at a layer more granular than port type.  It's perfectly reasonable for us to make a decision like this and last call is a chance for people in the community to raise an objection. 

Sandeep: Are we talking about inheritance or union? I see that the service type would have extensibility attributes at the service type level, but when I hear service type A versus service type A+, are we talking about two different roles, or a composite role? 

Gudge: The proposal provides composition of port types but inheritance of service types (by name).  Because service C inherits from B and from A, then C is an A and is a B. 

Sandeep: I see value in service type and value in port type. 

arthur: In programming languages to mechanisms for composition. Aggregation and inheritance. Steve's proposals are inheritance based. Aggergation requires something like service reference 

Steve: OGSI has done some work in this area ( Handles ) 

first straw poll: Do nothing vs do extension 
[Extension carried by overwhelming majority]

second straw poll: extend serviceTypes vs more radical proposal to extend portTypes and rollup serviceTypes 

Steve: portType would extend multiple portTypes. 

dbooth: which semantic is important, a portType as a group of ops, or a serviceType as a group of portTypes 

dbooth: are you more likely to want to add an op to a portType, or a portType to a service? 

steve: we can live with ST extension. but I think portType extension is at least as expressive 

arthur: with proposal to extend portType it is no longer just a set of operations, it also has a set of other porttypes it extends. There is a substitition relationship with the base portTypes.

roberto: so, we're going to remove serviceType, stick with a service being an aggregate of ports 

arthur: aggregate of ports could be done with PT inheritance. Confusion now about what multiple ports mean. Suggest we use PT inheritance to model different functionality. And different ports would be used to model different access to same functionality.
arthur: aggregation is useful, but largely orthogonal to the inheritance questions. Could introduce service references later 

4 votes for serviceType extension 
16 in the room for portType, +2 on IRC 
JMarsh: Do we want to explore portType extensibility 

ACTION: Steve, William, Arthur, Gudge, Joyce to produce a proposal for portType extensibility by End Of Week 


JMarsh: Do we still need serviceType? Do we want to hang any extensibility stuff off STs 

Steve: Current draft, do we go to service implements one portType? Or multiple portTypes via bindings? 

sandeep: please clarify the second 

Steve: Do we want to go back to having a service implement multiple portTypes? 

Tom: Would that mean single port per service? Or single portType for all ports? 
roberto: there will be cases where portType inheritance will not work. Need to address the issue of operation conflicts 

---------------------------------------------------------------------------
Discussion of equivalance 

Gudge: Could say that anything we have a QName for, we can define equivalence for, e.g., port type 

Gudge: Do we want to define equivalence for things we don't have a QName for, e.g., operation? Probably some of them won't be all that useful, e.g., message equivalence. If we define equivalence based on QName, then if the name is the same, then they are equivalent. 

dbooth: Wasn't roberto asking about operations that have same name but different content 

Gudge: Essentially, message parts are already QNames since they are references to something else. 

Steve: Operations are really nested QNames 

sanjiva: names are NCNames, local to portType 

Steve: Want to make sure that two operations with the same NCNames are distinct. Prefer QNames for operations.

Gudge: The only things that have QNames are things that appear as direct children of wsdl:definitions.  message, port type, binding, service type, service. All the sub components have an NCName that is local to the thing they're in and does not play in the target namespace. 

Sanjiva: Two port types, each with an operation "foo". Are the port types in the same namespace? 

Steve: Two distinct issues. Do we continue the NCName approah? What do duplicates mean? 

sanjiva: It's a dispatch question. 

Gudge: If you make operations have QNames, how do you guarantee uniqueness? Today two separate operations can have the same NCNames. 

sanjiva: Making operation names QNames does not solve the problem. 

JMarsh/Arthur: Do we want structural equivalence for each component 

ACTION: Sanjiva to produce a proposal for equivalence of ( at least ) top-level components in the next couple of weeks 

---------------------------------------------------------------------------
Hoisting SOAP binding attributes.

jeffsch: WSDL 1.1 SOAP Binding made you repeat a lot of things even when they were all the same. Proposal was to have higher level attributes and make those be the defaults when values were not specified lower down. No need to enumerate the operations again. 

Outstanding question from Jacek: What does it mean to omit an operation? 

Jeffsch: It means that the 'missing' operation takes the default binding values 

Tom: Clarification of Jacek's issue? 

jeffsch: If you don't specify binding info for an operation, it gets the default values.  We're not adding a new feature.

jeffm: that needs to be clear 

Tom: Need to state that if there are no default and an operation is missing that is an error 

Gudge: If operation physically appears, we use values of attributes if there, or else values of the attributes of the parent. It's the same as the long paragraph already in the abstract model that specifies how default values work for another component. 

Tom: Do we have defaults for the defaults? 

Gudge: No 

Sanjiva: Why not have a default for these attributes, e.g., use is literal? 

Steve: Can we do late binding to portTypes? 

Gudge: orthogonal to this proposal 

JMarsh: Is Kevins proposal orthogonal or not 

Kevin: They are compatible 

Sanjiva: Concern about fixing the SOAP binding without doing a design 

DonM: Didn't Glen post a draft proposal on this? 

Gudge: But it's only a syntax change, no a model change. Whatever model we come up with then some mechanism for defaulting would be nice 

JMarsh: We have a proposal for making a minor change. We don't have a proposal for a complete redesign 

Tom: There is value in this change. Any redesign would need to take this into account 

Prasad: Do we really need the suffix 'default'? 

Gudge: Get editors to generate names. 

Tom: Editors need to fix 'default defaults' 

[Proposal was accepted.]

---------------------------------------------------------------------------
Removing Parameter Order

Tom: If you encounter two parts with the same name are they [in,out] or [in] [out] parameters 

sanjiva: They are [in,out]. Jacek's issue is that we need to make sure they are the same type 

Tom: Seems to provide info.  It's in WSDL 1.1, 

Sanjiva: You can't really do it. because part names are local 

Arthur: it's an rpc issue. It shouldn't be in the operation description. If it's in the spec at all it should be at the binding level. It's just a hint. It can be safely ignored.

jeffm: Parameter order matters in RPC case 

Some discussion that this is not the case 

roberto: get rid of it 

JMarsh: Any objections to removing parameterOrder? 

No objecttion 

ACTION: Editors to remove parameterOrder from the spec 


---------------------------------------------------------------------------
10 Sep 2002, afternoon session
Scribe: Jeffrey Schlimmer
---------------------------------------------------------------------------

WS-I Discussion 

JeffM: Three WGs: Basic-Profile WG, Sample Apps WG, testing WG 
Basic Profile covers HTTP 1.1, SOAP 1.1, WSDL 1.1, XML 1.0, Schema 1.0, UDDI 2.0 

jmarsh: Is the basic profile an issues list? 

jeffm: editors were tasked with coming up with a draft by today. The draft is the first attempt to put all the protocol information into one document. Up to now, it has been an issues list. This is the first attempt to produce a coherent document for those who haven't been in the meetings. 

gudge: For instance, the SOAP 1.1 calls out the XML representation, specifically to address the ambiguity about whether you're allowed to have more than the four children called out in the SOAP 1.1 spec. 

gudge: The WS-I basic profile clarifies that for fault you may not have specific children, for instance. 

jmarsh: Is there a parallel issue in the SOAP 1.2 WG to resolve this? 

gudge: Some where not on the XML Protocol WG issue list but some where. 

jeffm: the default of the WS-I effort has been to adopt the decisions from the SOAP 1.2 WG, and there's an expectation that WS-I will adopt decisions from the WSDL WG. 

gudge: WSDL is the place where the WS-I profile group has done the most work 

jeffm: about a month ago, several of the WS-I board did a presentation to the W3C, covering issues like liason and points of contact to funnel information back and forth. 

jeffm: for instance, wearing the hat of either organization, i would like feedback from counteparts in the other organization. 

jmarsh: besides jeffm and gudge, who else is involved? 

prasad, kevin and william are also involved in WS-I 

jeffm: there are probably two decisions that have been made that are of most interest. One is to use only doc/literal and rpc/literal for descriptions. The other is to use XML schema for the type system.  WS-I decided to define an XML schema based encoding for graphs. 

steve: ws-i came up with this, or did they reference it from another standards org 

gudge: ws-i came up with it 

jeffm: the point of ws-i is to mandate usage for the sake of interoperability 

steve: isn't the xml schema encoding for graphs something that should go to a standards org? 

jeffm: we could. there are time frame issues, some jitter between ws-i and other standards organizations. 

tom: can you elaborate why both doc/literal and rpc/literal? 

jmarsh: let's cover the issues in order. First is do we want a point of contact between the two groups. What's needed is like what the editors do when they look over public comments and ensure that they turn into issues that are tracked.  The point of contact would need to make sure that relevant threads are forwarded, relevant issues are tracked, etc. 

kevin: contact needs to ensure that relevant issues and discussions are shared between groups. 

jmarsh: is there a publicly-archived discussion list from ws-i? 

jeffm: no. the e-mail threads are not public, but there's nothing to stop information flow. 

jmarsh: can one forward a thread from ws-i to the w3c list? 

jeffm: no. one would have to reformulate the issue, perhaps a summary, before posting it to the w3 discussion. 

jmarsh: the contact needs to be a good filter of issues. 

Prasad volunteered to be the liason contact from w3c wsdl wg to ws-i. tbd if he'll be appointed to the same role by the ws-i. 

jmarsh: second, let's discuss the graph encoding work. 

gudge: it's based on xml schema, it defines some elements for doing references to other nodes in the graph. You just define the serialization for the schema.  Unlike soap 1.1, where there are multiple ways to serialize a graph, you can write down how it should appear and can validate against the schema. There's no weirdness about whether it's a reference or in line. 

philippe: you do have a mechanism for graphs in soap, but it's not on top of xml schema. 

gudge: yes. 

jmarsh: soap allows numerous forms, but you can't write a schema. 

sanjiva: the sender would write the schema. couldn't one do the same thing in soap 1.1. 

gudge: if you were doing literal yes. in soap 1.1 there was nothing from coming up with your own way to serialize graphs if you wanted to. In soap encoding, there was no way to say what the xml looked like on the wire. you could say what the graph looked like, but you couldn't specify whether it was in-line or a reference 

sanjiva: is this a profile of soap encoding? 

gudge: the basic profile does not support soap encoding. If you want to think of it as an encoding style, it's a post encoding style.  In ws-i, you start with xml, and if you choose to express it as a graph, there are a means to do that. 

sanjiva: this was possible before, right? 

gudge: soap encoding didn't allow this 

philipe: what are the implications for those using soap 1.1? 

gudge: they have to use literal, and if they want to use graphs, they'll use the extension 

jmarsh: shall we eliminate encoding if it's not going to be subset out? 

jeffm: the basic profile is aimed at a sweet spot for business interop and does not intend to cover all possible scenarios 

roberto: in the soap 1.2 spec, it's optional. i'm not sure we can ignore it completely. 

roberto: why did soap 1.2 keep encoding? 

gudge: there's only a handful of people who care about soap encoding in the soap wg, but they do care 

jmarsh: does the same community that want encoding in soap also want to describe it in wsdl? i assume the answer is yes, but if it is no, then it would be nice to eliminate the work item 

arthur: it's no work on our part. we just expose the encoding style attribute. 

dietmar: but then we could get rid of the use attribute! 

arthur: it's probably premature to get rid of it, but we should clarify how all these attributes interact. this was a weakness in the old spec (and in the soap spec) 

jmarsh: what is the document lifecycle for the profile from the ws-i? 

gudge: there's a technical coordination group that's above the profile working group. the wg has only decided on a way to do graphs (etc). 

sanjiva: does the document specify a URI for the graph serialization? 

arthur: you're defining a schema for pre-defined attributes. could you use the namespace as the uri for the encoding style? 

gudge: that's an option. 

jmarsh: hypothetically, if ws-i decided they didn't want to maintain the document as their own spec, and it was going to the w3c, where would it go? 

jeffm: probably the xml protocol wg 

philippe: we're not sure that xml protocol wg will exist after soap 1.2 

jeffsch: I think it's inevitable that a subtractive org will need little bits of glue from time to time and that's perfectly OK 

tom: the xml schema spec for encoding, what is the expectation if a wsdl processor encounters it? 

gudge: whatever literal does. you'll be encountering complex types and simple types. 

sanjiva: at the programming level, they should also generate pointers. 

jeffm: at the programming language artifacts that you end up marshalling the data, look like graphs. 

sanjiva: it has to be a graph, or else you'll get the wrong thing out. 

jeffm: standardizing a programming language binding is currently out of the scope of w3c and ws-i. 

tom: defining a profile seems that it will make things clear and improve interoperability, but i'm concerned about this new structure and its impact on tools. 

sanjiva: pretty much all the tools only support xml schema as the type system 

jeffm: let's say you were a toolkit designer, and you want to support passing graphs, what are you going to put on the wire? 

tom: i'd say they're encoded and use soap encoding. 

jeffm: how would the recipient understand your serialization? 

tom: by reference to the named (soap) encoding 

roberto: if you look at the abstract level, at the port type, you see the schema and can interpret it using the infoset 

roberto: when you see it on the wire, you see this other encoding, and see that you should interpret it as a graph 

sanjiva: my proposal makes the point that the graph information should be captured in the abstract part of wsdl, not in the binding. 

sanjiva: you need to extend xml schema to support graphs 

arthur: the statement has been made that xml doesn't support graphs, but it does through id and ref. 

igor: but you have to agree on how that translates to objects and references 

jmarsh: and you need to indicate whether you're using this for graph representation or some other purpose 

igor: you could use this to refer to the attribute too, right? 

arthur: if an element has any attribute whose value is id, that element has an id. 

sanjiva: does ws-i believe that graphs are in the 80% case? why not do just doc/literal? 

jeffm: there were some people who thought this was important. 

tom: i would have preferred they didn't invent this and just stay with doc/literal 

sanjiva: practically, people are not going to use this graph extension 

tom: why rpc/literal? just to give people an operation name to dispatch on? It's the one of the four cases that's least understood. it seems odd that you didn't just pick the one. 

roberto: is rpc/literal a clarification of soap 1.1 or something new 

sanjiva: if it was a wrapped version of literal, that would be a hack (not nice) 

(various discussion of tools support to recognize wrappers) 

gudge: there was a very long discussion of the four combinations. those that care about rpc were convinced by the discussion that rpc literal was the correct approach. 

igor: what happens to the object references in the case of rpc literal? there is no encoding. 

gudge: if you've got a graph, you use the graph extension 

(tom said wrapped version of literal would be nice) 

arthur: if you get an arbitrary xml document with id and idref, the interpretation is that there are pointers 

igor: who's going to mandate that? ws-i? 

arthur: it's part of the xml spec. ws-i has provided more detail, an application of that mechanism. 

philippe: an xml validator should be able to validate 

jmarsh: there is a mess between various id mechanisms now 

philippe: .. your ID/IDREF references 

did ws-i come down on one side or the other of using @element or @type? 

prasad: decided to keep both, but if you use document, then you have to use element, but you can only use one part. 

------------------------------------------------------
Sanjiva presentation begins 

http://www.w3.org/2002/09/10-wsd/all.htm

sanjiva: we could have had a list of input (or output) elements within an operation 

sanjiva: xml schema has a large set of simple, built in types. if you just use element, then you have to define a global element declaration instead of just using the simple type directly. if you allow type, then you don't need to do additional declaration. 

sanjiva: i hate the fact that there are so many different ways to do things. for instance, sam ruby has a set of 8 different ways to describe the "same" operation in wsdl. 

sanjiva: on slide 6, soap:body is the wsdl-defined element 

sanjiva: if you have a message with a part, you need someone to create a global element declaration 

sanjiva: soap rpc gives rules for how to name this ged 

arthur: it doesn't have to be an element, because it already has an enclosing envelope, right? 

gudge: you need a child inside body, you can't just have characters. You can have an empty body, and you can have elements, but you can't put characters immediately as children of body. 

tom: a function with void arguments will send an empty body using document style 

roberto: the literal / type problem conflates with the soap schema 

sanjiva: this is what people use for document literal and it's wrong 

tom: there's a soap body and underneath it are immediately...? 

sanjiva: in literal/type, then the type is the type of body (not of its child) 

gudge: you would have to derive by restriction from the soap body, and if you use that as your type, it would be perfectly coherent 

gudge: the content type of the soap body is a repeating wildcard. The way the soap binding works, if you've got a type attribute (rather than an element attribute) and a use of literal, then the type is the type of the body itself rather than the type of the child of body. 

sanjiva: this is a little unintuitive. you don't expect to be defining a type for the body. 

roberto: since it would be a derivation by restriction, would you be expected to put an xsi:type to indicate which restriction you intend? 

gudge: yes. you could. does it need to manifest itself in the soap message? i'm not convinced it does. 

roberto: this is another restriction between the abstract description of the message and the soap binding 

sanjiva: SOAP 1.2 Data Model 

roberto: is there a base type for headers? 

gudge: no 

sanjiva: SOAP 1.2 published AF document to support SWA and DIME. 

gudge: soap 1.2 data model has a specific (different) meaning: it is the encoding work in soap 1.2.

sanjiva: the reason message exists is to capture the reality that there are multiple things in the soap model: multiple header blocks, multiple body blocks, and multiple "attachments". In my view, it's not tenable to require creating a single xml schema construct to capture all of these parts.  I don't mind depending on xml schema. But if you require xml schema and try to roll everything into one structure, you're going to have to define a single complex type with all of this information.

sandeep: (agreeing) message is a container abstraction 

gudge: i agree that a complex type is the right way to capture stuff you'd put into a header and into a body. wouldn't want a complex type that's three things for a header and one thing for the body. But the soap binding doesn't work that way today. you can refer to the body with one message and headers refer to their own definitions/declarations in schema.

sanjiva: are you saying that there's one message that captures all the bodies, one for all the headers, one for all "attachments"? 

gudge: just agreeing with you that it doesn't make sense to have one that crosses all boundaries. I could see one for all that is in the body, for instance one complex type that describes all. But not for headers, which are largely orthogonal 

sanjiva: harkening back to the medical record scenario, i imagine some of it in the body and some in the "attachments", but they're all one thing 

gudge: the way you'd do that today is to define a schema type for the thing that goes in the body (the medical record) and some of the things are of type reference to the "attachments" like the binary for the x-ray etc. 

sanjiva: are you saying that the packaging is filtering up to the abstract types and messages? That would be the wrong design point. 

tom: you're trying to rationalize that message is a valuable abstraction for encapsulating the data model? 

sanjiva: not specifically, just trying to provide background because the issue of the value of message comes up repeatedly 

tom: with the changes to soap header that we agreed on yesterday, that no longer points to a message but to a separate element or type, does address your concern? 

sanjiva: i'm concerned that we broke a fundamental design point because we did something specific to soap. Earlier we pointed to a message but it wasn't clear where the message came from. Perhaps it was broken before... 

gudge: either the message goes on the wire, all and only. or the message is some of what goes on the wire, and there may be other things. 

sanjiva: i see value in separating between application data and contextual data. One man's application data is another man's contextual data.  Contextual data would go in soap headers.

gudge: agreed 

sanjiva: application data goes in the body and in the "attachments". I don't think the right way to design is to commit at the abstract level which is going where. 

roberto: at the abstract level, define a single info set and then in the binding indicate which bits go where 

sanjiva: i would love to not have both mechanisms 

jeffsch: Model it as a single Infoset.  If there was appropriate syntactic sugar that allowed us to have a single infoset that captured all the pieces of data. It is one thing, a message. One infoset, binding says how it gets written out on the wire ( maybe not in one soap:Envelope ) 

roberto: if we used xml schema, then we could use powerful description mechanisms for specifying that a 'part' is optional, repeated, etc. 

sandeep: if we had a single complex type per message, then it could easily be a complex type that aggregates other types. wouldn't that be the same as a message? 

sanjiva: the user is not thinking of defining a type -- defining a type has a very specific semantic action 

tom: i don't like the idea of having to use xml schema directly against. the message construct is pretty useful. I'm concerned about how you'd represent mime attachments as parts without the message construct. 

roberto: there are ways to do that. As a programmer, i'd be interested in more powerful mechanisms for specifying messages.

arthur: one of the reasons for getting rid of messages was that people were asking for features already in xml schema. if people think those are legitimate requirements, then perhaps we should throw out message and just go to xml schema. In terms of defining mime types, you can define types and reference them and then define a binding that says how to serialize it. 

tom: that goes against what the document literal people want -- the xml on the wire should be validated against the schema 

roberto: when you bind, you specify what part goes on the wire 

arthur: in soap, they way you specify parameters is with url encoding.  In the case of soap, the payload is xml, and literal is the easy one, but you don't want this tied into soap only. 

tom: i agree, but it strikes me as odd to define attachment types in xml schema. 

jeffsch: Yes, there needs to be some glue to fix up the stuff which is not XML 

sanjiva: i'd like to get past this point today 

tom: would there be ordering among the inputs in the alternate operation direct-to-message format? 


jeffsch: having spoken to Paul Prescod it is not a requirement to be able to respresent EVERYTHING in every binding 

gudge: xml schema defined refs so you could refer to content of a particular type, but it doesn't work quite as expected. for instance, if you have an element called long which is a reference to something else, since it's a numeric type, it can't be empty, but since it has a ref, it is empty and isn't schema valid. 

jeffsch: Don't think we need non-XML bindings 

sanjiva: I think we do 

gudge: an non-xml type systems should just be surfaced up through an xml type system, like xml schema. that's how the dime binding works today. 

tom: what harm is there in thinking of the message as other than a stack frame for a method call? 

sanjiva: a global element declaration doesn't 'describe' what the service does, which is take arguments (?) and do some computation 

(sanjiva is arguing that document is inappropriate for exposing method calls) 

tom: concerned that sending a document disguises what you're doing with a method call exposed as a message 

roberto: wsdl is bound to an actual protocol, and the infoset is mapped to a specific format. similarly, a programming language binding (proxy?) defines the mapping to and from the infoset. 

tom: it's more work for me as a tools developer to take document and expose it as a method call in the language. if you're in a document case, you'll get the right kind of function signature, very simple, with only one real data element, and the tool would have to do more work to unwrap and return the typed components. 

jeffsch: Is it about which of them become parameters vs which become fields of a structure 

tom: this is about how to determine which of the message are parameters when surfaced as a programming method. 

roberto: the distinction is in wsdl because we created these four different things. if we eliminated these, it would be a programming language binding issue. 

sanjiva: you don't see this issue in languages today. 

roberto: developers are programming against language interfaces, there's the wsdl, and there's messages on the wire. they don't all have to abstract the same way. 

sanjiva: if ws-i has already dropped encoding, i say drop it. I would like to see an encoding style attribute in the part type to allow binding to do the right thing 

tom: part name='foo' type='foo' encoding='soap encoding uri'? 

sanjiva: if you want to say that the schema that your part is typed with has been derived with the ws-i graph rules, then you should say at this level that the schema has been derived with these rules 

gudge: but it works in the completely opposite direction of the soap encoding today. the soap encoding today says the schema you see doesn't look like that on the wire. whereas the ws-i encoding says it will look like the schema on the wire. 

sanjiva: which is a better direction. 

------------------------------------------------------
Message Syntax

jmarsh: what should we do about message? We can do nothing. We can do something along the lines of sanjiva's proposal to change the syntax but not the semantics. Or we can get rid of message and just use complex types instead. Sanjiva seems to be pushing for a 'final' resolution on where message is going.

jeffsch: A well-known XML schema construct ( GED or CT ) instead of wsdl:message. For those that don't like schema we could define a new wsdl construct that can be XSLTed directly into XML Schema.  Would look very similar to what we have today. Would not do anything that you couldn't do with schema.

sanjiva: would users write new message or schema? 

jeffsch: they could choose, we would define the mapping from new message to schema. Message is a way to aggregate types ( and it's the last step ( after schema descriptions )). Why are we defining something which is SO similar to schema.  We should focus on stuff around portType/operation etc. 

tom: We might want to invest more in message because it's understood by many people. It gives us an abstraction that is clearer than the same description would be too complex in XML Schema 

jeffsch: I am concerned about the 'more than one way' problem. We have multiple ways to do things today. 

sanjiva: If we don't know where things will go in the final packaging then the abstraction should model that. So are you saying just use xsd? 

jeffsch: Is that the show-stopper? Don't want to MANDATE xsd. 

sanjiva: one issue is stylistic; defining a message is not the same as defining a type. The other is that packaging should not bubble up to the message 

gudge: defining a message is not the same thing as defining a type. defining a message in wsdl says it contains thing 1, thing 2, and thing 3. defining a type in xml schema says it contains thing 1, thing 2, and thing 3. how do they seem different? 

sanjiva: it's how it appears to me. 

tom: why do we need to get rid of message construct? 

gudge: we can do exactly the same thing with an xml schema complex type 

roberto: you can do more in schema 

gudge: to take an example, let's use sanjiva's medical record example. i have a record and three xrays i want to send. A schema description would be an array of hex (and some other details i missed), and at the binding, we say they really are hex or we say they are mime multipart with href with the uri of the part in the mime. the schema description is consistent and will validate either way, and it works just fine. the actual physical manifestation is defined as part of the binding still, not part of the abstract level. 

tom: the assertion is that there's no loss, only gain. 

gudge: there's certainly no loss; roberto's assertion is that there's gain. 

sanjiva: if we went this way, parts become xpaths. to indicate which fragments of the message are bound how, you might want to say which part of the complex type gets bound how. 

gudge: or you could just use id and href. i'd also be happy to use xpath. 

sanjiva: you can't have it both ways. 

gudge: we could decide to enable either. 

sanjiva: you have to use xpath if you don't constrain the schema. 

gudge: there are constraints where you want to say that something could be in-line or could be in an 'attachment' 

tom: why are we revisiting it? 

sanjiva: because we're not letting it go. 

arthur: we don't have to change it for wsdl 1.2 but we do have to clarify it. there are too many ways to do things in wsdl 1.1. I would be happy to take a crack at a clarification of all the combinations.

jmarsh: are you volunteering to take that action 

arthur: yes. i think we need that if we don't change it for the 1.2 spec. 

tom: the problem is that i don't have a sense for what the room is thinking. there are a number of people who are listening quietly. 

arthur: do we have an example of using parts with mime? 

roberto: there are some examples in the wsdl 1.1 spec, but it isn't complete 

arthur: we're saying there's an advantage to multiple type systems, but we've only seen xml schema and mime. 

tom: doesn't see anything particularly wrong with message, but doesn't have a strong understanding of how alternatives would affect wsdl but believe it would 

kevin: would there be > 1 input or > 1 output? 

roberto: at most 1 input and at most 1 output 

jmarsh: anybody can introduce a proposal at any time. would those who would introduce such a proposal be interested in a straw poll of the group interest? 

gudge: interesting in coming up with a proposal for removing message in favor of something schema based 

straw poll: interested in pursuing a proposal to get rid of the message construct and use xml schema as the combination mechanisms for bringing pieces of a message together 

(majority voted in favor) 

tom: are there people who would vote for even a good proposal? 

arthur: it's really complicated now 

allen: we're going to make it really hard by allowing all of xml schema to describe messages 

gudgin: you have all that today 

jmarsh: there is interest in a proposal but there are concerns about the need for the proposal. expect that there will be clear motivation for such a proposal. 

ACTION: gudgin; jeffsch; roberto et al to write proposal [to remove message and replace with complexType.]

------------------------------------------------------
@type vs. @element

jmarsh: regarding use of type and/or element, feel that ws-i found that they couldn't choose one, we won't be able to 

arthur: ws-i wasn't able to modify the binding but we can 

sanjiva: how is this related to the binding 

arthur: because you can invent rules like encoding to generate arbitrary messages, you have to modify the binding rules. 

sanjiva: they were defining usage style, and they could have easily chose one, but couldn't. we don't want to go through all the discussion again here, and not reach an outcome. 

arthur: what's the difference between an element and a complex type with just that element? none, right? 

sanjiva: there's a difference. Its the same difference between an int and a struct with an int in it 

gudge: i agree with arthur 

sanjiva: the binding defines a type for the soap:body element, and that doesn't work. it isn't the natural thing to do. 

gudge: whether it's the natural thing to do or not, what arthur described gives you the same message on the wire in either case. 

arthur: you can't do it only with element, because it has a single root, but you can do it with complex type. 

arthur: there are several, different, equivalent way to describe messages in soap. 

gudge: as long as i can get them to look the way i want them to, i don't care whether it's a complex type or an element 

allen: people have elements and don't want to re-write them. 

?: what about simple types 

sanjiva: you have to define a complex type that has an element of that type 

arthur: after you execute all the style versus etc. you have much complexity. in reality, there are fewer than 8 different kinds of messages, but there are 8 ways. 

tom: i'm the first one to say that its definitely confusing, but it feels intractable. If i can't say xsd:int, then... 

arthur: it's exactly the same number of angle brackets, isn't it? 

tom: the wsdl spec is hopefully easier to read than the xml schema primer 

sanjiva: let's move this to e-mail 

jmarsh: people seem to agree that it's not completely intractable 

tom: can we take a vote on who would like to close this issue on element/@type, and how many people would like to explore it further? 

arthur: i claim we don't need element, that we can do everything with type, in a natural way 

igor: say there's a standards body, and you want to use messages to talk to a standards org, don't you have to adjust their schema? 

arthur: if you show me the soap message that sends a rosetta net document, i can describe that in wsdl using particles types. if that's true, and we can do it in a clean way, with import (not cut-and-paste), then we don't need @element. 

sanjiva: let's take the straw poll, and if there's general consensus, let's close the issue, and if there's new information, let's re-open. I think we can do it all with type, but i don't think we will get everybody to agree to eliminating element 

jmarsh: i think we all agree that it will be simpler if we had only one 

tom: i see that encoded can only use type whereas literal can use type and element. it means that for rpc/encoded, we don't allow element, and that seems to work for them. do we have a list in our minds of what we will be doing if @element is not allowed. i don't have that list coherent in my mind. 

jmarsh: straw poll: how many people want to close this issue now and claim that it is intractable? 

(only one vote) 

jmarsh: it's an open issue, and we need a proposal (keep @type and remove @element) and rationale. There may be arguments against such a proposal, e.g., usability, interaction with other standards. 

ACTION: arthur to kick off the thread, perhaps by showing how to convert an existing @element into @type. 

------------------------------------------------------
dropping use="encoded"

sanjiva: we have existing proof that you can do rpc/literal, and by dropping encoded, we can reduce our complexity. in the case of the ws-i graph encoding thing, we need to capture that thing is used for a message part. 

jmarsh: if we drop encoded, then the ws-i graph encoding thing is general, subsequent clean up. 

sanjiva: remove the use encoded case and always use literal 

roberto: in the case of soap 1.2? 

sanjiva: leave it as an extensibility case 

allen: encoding style? 

arthur: encoding style is really an attribute of the schema (if you use literal). 

roberto: somebody who wants to use the soap data model and soap encoding would define their own extension attribute in the soap binding? 

sanjiva: (missed this) 

dietmar: if we don't have use encoded, wouldn't it be enough to use the encoding style attribute to indicate that one is using the soap encoding style? 

gudge: it comes down to whether you can describe a graph using the schema 

gudge: the ws-i encoding is not the same encoding as what's in part 2 of the soap spec 

dietmar: can we get close enough to part 2 using the ws-i encoding? 

gudge: maybe. closer with the soap 1.2 than soap 1.1, but i suspect there are some corner cases where you can't 

jmarsh: straw poll on use encoded? 

roberto: if we drop the attribute, then everything is literal? even though i can't cover part 2 of soap 1.2? 

gudge: the reason we're moving in this direction is that ws-i has dropped support 

sanjiva: we're saying that the wsdl wg binding won't support the part 2 soap encoding 

jeffm: the w3c wsdl 1.2 spec won't be able to do the soap 1.2 encoding. wearing my w3c hat, that seems like a problem. ws-i is mandating that it shouldn't be done in the basic profile... 

gudge: ... but we might not want to in every case. 

jeffm: let's say we do this, won't the xml protocol wg wake up and say 'great' or they're going to push back 

sanjiva: there are other of the many featues in soap 1.2 that we aren't going to support, and it is an optional feature, and it cuts the 8 ways in half. 

jeffm: i'm ok with not being able to describe everything in soap with wsdl 

sanjiva: in order to do a soap encoded binding, you'd need to extend this binding 

roberto: we'd been saying that it would be a real schema, not a skeleton people have been using today 

dietmar: a soap message has no attribute which makes a distinction that it is literal or encoded. why does wsdl need that information? The soap people wouldn't even notice because they don't have such a concept. 

arthur: soap doesn't describe the service, that's the purpose of wsdl. part of the description of the service is that there should be a schema for the description of the service. 

jeffm: there's an infinite number of things you can transport over tcp; some can be described, but you can always open a socket and blast raw bits. 

sanjiva: is it widely used 

roberto: maybe we don't want to recommend encoding, but i'm not sure we can be more prescriptive 

tom: i think people are using encoding because that's what their stack does 

arthur: soap predates wsdl and schema, so the messages may vary a lot 

jeffm: i may not be able to describe the messages i'm using to communicate with the other party. one goal of using wsdl is to make the number of such cases smaller. 

sanjiva: from the wsdl wg point of view, reducing cases from 8 to 4 is a good thing. i propose that we take it out, and if we get feedback, reconsider. 

gudge: the easiest way to get feedback is to post to soap builders saying that the latest draft removes encoding 

arthur: we can have wildcards, and you could generate a schema that is valid but doesn't say much 

jeffm: like sequence of octet :-) 

jmarsh: we could float a message to soap builders first 

sanjiva: this would be a perfect primer topic 

tom: is that true, when you soap encoding something that all attributes turn into elements? 

sanjiva: yes 

roberto: that's an interpretation. you could reject it. 

sanjiva: see. it's a hole, and we can eliminate that hole.  If we send a message to soap builders, we need to send enough context to motivate it. 

jmarsh: 'here's the harm, and here's how you can do it anyway' 

tom: people are going to raise the issue of graphs. are we going to reference the ws-i document? 

jmarsh: if we wrote such a message, would the wsdl wg believe it? 

jmarsh: straw poll to drop encoding: 15 in favor, 3 against, and some abstentions 

------------------------------------------------------
Non-XML type systems

sanjiva: there are things called services, they can be composed, there is a programming model, people write them, find then, use them. we do not believe that every service will be all about soap and xml. there will be lots of services that will be implemented in other protocols, and therefore wsdl should not preclude describing services that are available with other services. my preference is to allow people to use non-xml type systems, that we do not pre 

tom: what would be an example? 

sanjiva: ejb with an rmi-eop binding. wsdl 1.1 supports this today, and we have several bindings today that work with this. microsoft has ws-ml that binds a com component (?) 

(jeffsch and gudge are unaware of such an effort within microsoft.) 

sanjiva: it comes down to saying that we won't put anything down in the binding unless it's capture in the abstract level. we will not make any assumptions at the abstract level that it will be xml. 

tom: do the changes to soap header do that? 

sanjiva: yes. i think we need those changes, but it doesn't capture those in an abstract form, so if i'm doing that in rosetta net etc, i have the same security context but can't express it. 

Roberto: that's an RMI-IIOP binding. 

sanjiva: i believe there are two kinds of data you want to describe about a service: application and context. in some systems you don't have context data, in others, you do. we need to express all the information at the abstract level. 

tom: soap header now has an element that points to some abstract data? 

sanjiva: where the data comes from isn't specified. if it's in the input and output messages, you don't know if it's the same value of the type? 

tom: did we have that in wsdl 1.1 

sanjiva: no 

roberto: we could do this through the property mechanism 

tom: rmi could do that too, but your concern is that it isn't clear at the abstract level that every binding for a service must bind this context data as well as the application data. when we solved the problem for the soap binding, we didn't really solve it for other systems. 

gudge: i agree that we need to enable this, but i don't see how it bears on the question of xml type systems or not 

gudge: bindings are supposed to be concrete (not abstract) 

sanjiva: i want to be able to say that any binding needs to bind extra parts of the message 

sanjiva: the abstract description of the service has a binding-independent flavor, and that doesn't capture now that we have context (non application) data that we want to carry in a soap header. the problem i have with that is it isn't captured as an aspect of the service. 

tom: given the fact that we're discussing making message and part go away, this seems moot 

sanjiva: even if we do, the problem persists 

allen: we need to represent these other, context notions abstractly. suppose we do it with complex types. maybe we need two complex types, one for the application and one for the context. we would also need a mechanism to connect the two, to indicate that a thing has both context and application. 

tom: is xml schema the way to tie all these things together? (compared to a wsdl-specific construction, is xml schema going to make it even harder to detect the relevant bits?) 

gudge: why isn't the binding the right place to define the relationship between context and application? 

igor: could be as simple as saying, input, output, and context. every binding would decide how to bind context, perhaps as header. 

gudge: i disagree (pretty strongly) that it belongs in the port type/operation or higher because i may want to be able to access that port type via kerberos but i might also want to be able to access it via x509. i don't want to tie these into the port type. 

igor: could you define something like 'credentials'? 

gudge: that would get us into the game of defining all the possible context 

sanjiva: this seems like policy 

allen: would all context be policy? 

igor: for example, assume that a standard correlation id has been defined. wouldn't you describe this at an abstract level along with the inputs and outputs, and then bind this with other, non-abstract context? 

sanjiva: i can live with us not being to define context. as long as we don't preclude non-xml bindings. 

gudge: i could live with an xml type system but allow non-xml bindings through extensibility 

sanjiva: we have three type systems: xsd, mime, and uri-named types. we need to decide if we're going to shoe-horn everything through xsd, or handle each as first-class citizens. 

gudge: my preference would be to use xml schema to support the abstract attachment model that soap 1.2 wg has produced, and then have bindings that map to soap with attachments and dime attachments. Whatever we have in schema should allow using binhex, mime, or dime 

sanjiva: i'd like to see an xsd shoe-horn approach that we can live with 

jmarsh: i could use more data on what we're thinking here 

ACTION: gudge provide summary of using xml schema to wrap other type systems at an appropriate level of abstraction 

straw poll: interest in non-xml bindings: 8+ 


---------------------------------------------------------------------------
11 Sep 2002, morning session
Scribe: Dietmar Gaertner
---------------------------------------------------------------------------

Solicit-response and Output-only operations.

David's slides: http://www.w3.org/2002/09/11-wsa-dbooth/output-input_clean.htm 
My presentation for this morning's F2F meeting is at: 
 http://www.w3.org/2002/09/11-wsa-dbooth/output-input.ppt (PowerPoint) 
 http://www.w3.org/2002/09/11-wsa-dbooth/output-input_clean.htm (HTML) 

Topic: Solicit-response, presentation by David Booth (DB) 
Title: Should Mirror Operations be dropped? 
Four MEPs: in-out, in, out-in, out 
concerns mirror ops expressed by some people 
fault is an alternate input 
analysis: would we want mirror ops? 
ways to match client and service a) share same WSDL b) have complementary WSDLs 
shared: one WSDL per service 
shared: referencing a common document (T) 
shared: client, service ref T 
Roberto (RC) would you be using out-in or out only? 
TB1: acting in the role of a service 
TB2: acting in the role of a client 
Currently we have no way to express these types of roles 
Jonathan (JM): dicovery capability? 
DB: client is a role, service is a role 
shared: conclusion 
- need out-in? 
- need out only? 
DB: matching process; client could ask to be matched with a service 
DB: we assume that the non-mirror ops are important 
DB: mirror ops are not important 
DB: complementary service descriptions 
DB: observation: complementary approach requires mirror ops 
DB: all of the services (client) could reference a common service description 

Amy: additional info in the WSDL required to do this 
Amy: issue of adding initiator information 

DB: it looks like the mirror ops should be kept 

JJM: what about binding information? 

DB: address not shared, other info could be shared 

JJM: information in header blocks 
information whether some information is carried by soap headers or in soap bodies 

DB: address is unique 

SW: what is the binding for output only ops? 

MG: there is no sensible binding info for out only ops 

SW: only possible for bindings with a symetric protocol 

Don: leave it up to extensibility? 

jjm-rns: In other words, the shared knowledge is at the abstract level only, IMO. Specific servers may provide the same abstract service, but concretely one server may require authorisation information as a header block, whilst another may require the exact same information (same encoding) as a body block. The client only needs to know at run time, so as to build the correct soap message. But, from a client's perspective, the two services are compatible. 

Don: have experimental bindings for out-in and out only 

Don: don't understand why we would want to drop it 

SW: possible to drop and do without it; there's no loss 

MG: in the soap spec soap role is also not used (leveraged) in the spec. If you wanted out-in and out only you would have to write your own extension 

RC: we could define two port types in terms of in and in-out and invert the direction. Out only and out-in are very hard to map in prog language interfaces.
(RC=Roberto Chinnici) 

SW: I'm a single service and describing myself. How do I map out-in and out? 

JS: some people see value in the feature and some don't. The ones who don't see the value want to remove it. Trade-off: how much is in the standard and how much is left to extensions. 

TJ: as an implementor if I come to that part (out-in, out) I don't know what to do 
(TJ=Tom Jordahl) 


Joyce: out-in, out not used; would like to take them out 

PY: bindings can be defined. Either fix WSDL or leave it up to a higher layer to define 
(PY=Prasad Yendluri) 

MG: IRC sever example; client makes connection; server sends out info 

Amy: Email subscription example 

SL: users at home want to have a possibility to describe subscription services 
(SL=Steve Lind) 

JM: if we keep out-in, out we need to define bindings 

SW: not necessary to define bindings 

Don: what if we did publish a binding example? 

SW: there is no general interest to do it 

??: only 4 MEPs? 

SW: it is up to you to define your own MEP extensions 

DB: client initiating the connection, server sends message? 

SW: where would the server know how to initiate a connection? 

DB: the client's address is out of band. Period. 

JM: wondering whether there are sub-parts of the question which we can easier resolve 

SK/JM: people want to do pub-sub 
(SK=Sandeep, JM=Jeff Mischkinsi) 

... discussion back and forth... 

DB: you can only claim that HTTP doesn't work for out, out-in if there is no out-of-band info 

PY: port can be used as the address where the response is coming back 

MG: some asserting out, out-in doesn't work over HTTP some think it will 

JM: Prasad is arguing that part of the binding is already there; just needs to be reworked.  How many people are using out, out-in and would be affected if they are taken out?

Kevin, MikeM, SteveL, Don, Gudge 

TJ: if we can't implement it in an interoperable way, it's not useful 

Chris Ferris: that's why you need a concrete binding 

TJ: if the binding is not spec-ed, we get the interop problem 

JM: Sanjiva, some talk about BPEL? 

SW: no presentation at hand BPEL does not use bindings, it uses different mechanisms 

JM: anybody's position changing? 

IS: what about fixing it first. Describe in the spec how to do it. 
(IS=Igor) 

MG: in WDSL 1.1 out, out-in are spec-ed same as good as in, in-out, but no examples 

DB: out of band info needs to be specified for mirror ops 

SW: we should do the binding first 

JM: what is the harm in leaving it in? 

TJ: Danger of beeing only interoperable with your own services 

JM: you want to stick mustUnderstand on this operation? 

TJ: Yes... 

Amy: have interoperability because also soap builders take care about clarifying 

what the specs are missing 

Adi: better address in the spec instead of relying on others to clarify 

SL: If we leave in we need to describe usage scenarios in an interoperable manner 

PY: message format on the wire is not different than for in/in-out. Just where the message is to be sent changes 

SW: take an action item to describe pub-sub 

ACTION: Sanjiva describes out/out-in for pub-sub 

JS: soap group did such additional stuff in a descriptive way (e.g. Email binding) 

SW: also, non-XML binding 

JM: more proposals could help people understand to move this forward. Alternative is to take votes.  Consensus based on clarifications (by proposals) better than voting. Minority objections add risk for the CR to be sent back. 

ACTION: Jeffrey and Don define TCP binding 

RC: look for ways to have just in/in-out and mirror then to get out/out-in 

JM: take this up for 2-3 weeks to give people a chance to work out proposals 

---------------------------------------------------------------------------
Joint session with Arch begins

November FTF details:

TJ: November F2F hosted by Macromedia in Boston 

JM: Description first, joint session with Arch group, Arch meeting following 

TJ: Wireless connection available 

JM: Thanks to Allan Kotok for organising this meeting 

Alan: Thanks belong to his boss at DISA who payed the check. 

JM: Options for January: Sidney (!) or US West Coast 
JM: Other option: Sri Lanka 
Sri Lanka: 15 believe they would be able to go.  7 believe they would not.
Sydney: 25 believe they would be able to go.  3 believe they would not.

JM: Sidney appears to be a viable option (~25 voted yes).  Will pursue this option.


---------------------------------------------------------------------------
Topic: REST 

David Orchard, Mark Baker from the Architecture Group: 
(TAG) 
Presentation on REST 
TAG published principles of web architecture 
Identifiers, Formats, Protocols 
Identifiers: URIs are it; use absolute URIs 
Uses of URIs: 
- Comparison 
- Interaction (dereferencing) 
QNames vs URIs: TAG gives no guidance 
Issue: range of http: URI schemes 
CF: mapping between QNames and URIs? 
Discussion on QNames vs. URIs ... 

Topic: REST 
REpresentational State Transfer; from Roy Fielding's thesis 
Basics of REST: constraints 
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 
client/server separate data from control logic 
stateless protocols 
intermediaries can cache data 
uniform interfaces 
REST: Architectural Components 
- data elements 
(resource, resource identifiers, representation, etc.) 
- connectors (client, server, cache, resolver, etc.) 
- components (user agents, gateways, proxies, etc) 

Francis: this is a strong statement about what architecture is 

DO: REST is making this statement 
Uniform Interface: 
principle of REST: GET/POST/PUT/DELETE are the interaction verbs 
more ad hoc communication without a priori knowledge of the interface 

CF: but there is always a priori knowledge 
CF: important point is that these verbs have been written down in the spec, not that they are GET/POST/... 

DH: please focus questions on basic principles of REST 
(DH=Dave Hollander) 

REST is about applications knowing about the interactions going on 
App has to know, e.g. about the reliability interactions 
You can't hide these from the application 

Frances: Q: in what sense is GET/POST/... a spanning set of verbs? 
Frances: Q: in what sense does REST combine resources together? 

DO: REST does not distinguish between things and info about things 
DO: things and info about things are modelled together 
??: what about modularity of operations? how does the compositional model work? 
DO: example soap: use soap header to place additional context info. From REST perspective this info should be in the URI instead in the message body 

Questions and personal opinions: 
- REST compliance required for web architecture? 
- where is REST (currently) broken and WS can help? 
- is REST interaction model useful for WS? 
- what about all those Web sites that don't follow REST? 
- Ist SOAP 1.2 Binding Framework sufficient? 

...discussion on the status of REST (recommended by TAG?) ... 

Mark Baker: REST compared 
MB: will compare with other "object models" 
MB: OO-RCP 
MB: Internet Email 
MB: Tuple Spaces (tuples not identified) 
Object identification in REST: 
- URI scheme as key innovation 
- resources and representations identified by URIs 

Sanjiva: am I confused or didn't URIs precede REST by about 10 years? 
dbooth: Sanjiva, the REST viewpoint: "REST makes the Web work. There are lots of sites that do non-RESTful things, but there are enough that are RESTful that the Web still works." Analogy: "Cool URLs are persistant. There are lots of broken URLs, but there are enough that that work that the Web still works." 
I.e., REST documents WHY the Web works. 
Sanjiva: So URIs were not a REST innovation as indicated by the previous slide 

MB: OO-RPC binding style by object (reference) 
MB: Email binding style: late binding for mailboxes 
... discussion about the distinction; HTTP extension framework allows for defining own stuff... 
MB: Tuple Spaces binding style: late binding 
REST binding style: late binding; see a URI, invoke GET/PUT/... 

DBooth: Frank, memory addresses have only two operations: READ and WRITE, but we build fully functional apps on top of them. 

MB: discussion of App State Engines for OO-RPC, Email, Tuple Spaces compared to REST 
MB: REST app state engine: Hypermedia, "walking a typed graph" 
MB: ... state changes as hypermedia links 
Example - lightbulbs - for OO-RPC, Email, etc. 
MB: REST lightbulbs: GET returns state; PUT to turn on and off 
"PUT" writes a representation. 
A GET on a related URL might give you a list of all the possible lightbulb states. 
DBooth:  A "POST" *might* turn off the light, depending on the particular semantics of that particular post. A "PUT" *does* turn off the light, because it explicitly writes the new state. 
Discussion about uniform interfaces... 
Presentation finished.

Meeting adjourned.

Received on Wednesday, 18 September 2002 17:50:58 UTC