W3C home > Mailing lists > Public > www-ws-desc@w3.org > January 2003

Minutes: 20 Jan 2003 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 24 Jan 2003 11:41:58 -0800
Message-ID: <330564469BFEC046B84E591EB3D4D59C0900D69B@red-msg-08.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

--------------------------------------------------------
Monday 20 January
--------------------------------------------------------
Present:
 Erik Ackerman          Lexmark
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Youenn Fablet          Canon
 Steve Graham           Global Grid Forum
 Martin Gudgin          Microsoft
 Tom Jordahl            Macromedia
 Philippe Le Hégaret    W3C
 Steve Lind             AT&T
 Kevin Canyang Liu      SAP
 Michael Mahan          Nokia
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Dale Moberg            Cyclone Commerce
 Don Mullen             Tibco
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 William Vambenepe      Hewlett-Packard
 Steven White           SeeBeyond
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

Observers:
 Martin Duerst          I18N

Phone:
 (3:30-4:30) Glen Daniels           Macromedia
 (9:00-3:30) Amelia Lewis           TIBCO
 (briefly)   Lily Liu               webMethods

09:00 Introductions and logistics
    - Assignment of scribes
        (pool of likely victims: Erik Ackerman, Sanjiva, Jeff
        Mischkinsky, Igor Sedukhin, William Vambenepe,
        Martin Gudgin, Jeffrey Schlimmer)

Order of scribes:
  William Vambenepe, Igor Sedukhin, Jeffrey Schlimmer, Martin Gudgin
  Yoenn Fablet

[William scribes]

09:20 Message Exchange Patterns/Output operations.
    - Unified SOAP/WSDL MEPs [2].
    - Interaction proposal alternatives [3].
    - Solicit/Response MEP [4].

  [2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0022.html
  [3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/att-0005/01-interaction-patterns-jan-13-2003.html
  [4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0035.html

Topic: Don's Proposal

Don:      Minor modification to SOAP MEP. Create abstract MEP specification.
Jonathan: Ideally arch group would own description of abstract meps.
Don:      Arch group already created template doc based on soap spec.  Not 
          much activity recently on that. They own MEP framework but are 
          hesitant to create specific abstract MEPs.  They just own the 
          definition of what an abstract MEP is.  We could own some abstract 
          MEPs ourselves.
Jonathan: Does the group have any feedback on the proposal?
group:    (silence)
Jonathan: Have people read the proposal?
group:    (silence)
JeffSch:  Is the idea to at some point have indication in the portType of the 
          MEP implemented and in our spec more info on how a MEP is further 
          defined based on its URI?  Would this be a normative part of the 
          spec?
Don:      We would define several MEPs.  In the operation syntax you would 
          indicate what MEP is used by this operation.  Other people can 
          create their own MEPs too.
JeffSch:  So this is a proposal for how the MEPs created by this WG would 
          be described?
Don:      Yes.
Jonathan: Wsdl 1.1 has 4 "MEPs" (not by that name) but how they relate to 
          SOAP MEPs is undefined.  At least we need to describe that. 
          That's the 1st pb.  The 2nd pb is for output operations. If we 
          can define them better, we can keep output operation. 3rd pb is 
          how do you charaterize a MEP in WSDL.  Don's proposal addresses 
          the 1st pb.  For the 2nd pb, amy has shown how you could write 
          an abstract MEP for output operations.
JeffSch:  Is the proposal (for the 1st pb) that something goes in our spec 
          to explain the relationship with SOAP MEPs?
Jonathan: We would point directly to the abstract MEP framework and to the 
          MEPs we support (probably the 4 in wsdl 1.1).  And SOAP would 
          also point to the same abstract MEPs. Therefore reconciling SOAP 
          and WSDL.  The proposal is for Arch WG to own it. if necessary 
          we could start writing it.
Don:      Ideal scenario is Arch owns the definition of what a MEP is and 
          our spec describes specific MEPs.
Jonathan: If we own abstract request-response MEP, how does SOAP use it?
Don:      SOAP binding would indicate which one of the 2 SOAP MEPs 
          correspond to the request-response wsdl MEP used.  SOAP MEPs 
          could be simplified by stripping out the abstract part and 
          pointing to the abstract definition.  Pb of timing.
Arthur:   Wsdl has "primitive" MEPs. When do you run into things like 
          BPEL? what kind of complexity does WSDL cover?
Don:      There's an inherent risk of people abusing this mechanism
Jonathan: Abstract MEPs are not going to be machine-readble. The 
          resulting interop pb will hold people back from going too wild.
          So, we won't put anything technically that limits potential for 
          abuse, but we will restrict ourselves to the most primitive MEPs 
          and not go overboard.
Amy:      If you have control flow then you know you are in the space of 
          choreography.  If you have complex MEPs with a sequence of 
          messages, you can define them as a choreography or as a simple 
          MEP (if the flow is sequential, without choices or branches, 
          even of it is lengthy). I am concerned that we seem to shy away 
          because of fear of touching choreograhy. I don't think it's such 
          an issue, if we go in this direction, interop pbs will stop us.  
          Should not put limit on MEPs in terms of nb of messages.
Steve:    Don, can you enumerate MEPs?
Don:      Reques-resp, solicit-reps, input only, a couple of variation on 
          output only...
Youenn:   MEPs define nodes, but we don't know which node will be the 
          service. So in a request-response MEP, you don't know whether the 
          service will be on the sending or receiving end. so we need to 
          be able to identify that. And in this case, i am not sure we 
          need solicit-reponse. It is just the miror of a request-response.
JeffSch:  It would be simpler if the MEP said "i am defining inputs and 
          outputs" and if you are implementing this MEP you know which are 
          input or output.
Youenn:   Disagree. when you implement it, which node you are won't change 
          which MEP you are using. Either we identify in the spec which node 
          is the service. or in the wsdl we say "this is the MEP, and I am 
          this node". In jeffsch's way, the same MEP will be defined twice, 
          once from each point of view -> concern of duplication.
JeffSch:  Concern we discussed at last telecon: if I don't understand the 
          URI of the MEP, how much do I undrstand the messages?
Youenn:   MEP identified as URI. we can create a schema to describe the roles.
JeffSch:  Intermediaries will have to process this schema, won't always know
          what to do.
Youenn:   Intermediaries will process the wsdl and this schema.
Gudge:    You're assuming they have access to it.
Youenn:   Yes.  You can define a triangular relationship (3 parties) with a 
          MEP and the service says who he is.  With jeffsch's proposal we 
          have a spec to describe each of these nodes.
JeffSch:  The trade off we are discussing is the value to be able to do 
          identity comparison (they point to the same MEP) vs a simpler 
          rule for an intermediate (doesn't need to retrieve additional 
          docs).
Youenn:   I don't think the 2nd one is simpler.  The different between 
          choreography and MEPs is that MEPs are one-way interactions. MEPs 
          will be simpler than choreography. If we only have 4 MEPs that we 
          define, all WSDL processors will have these 4 MEPs so the 
          difference won't be big (as opposed to 2 MEPs) but I still prefer 
          the latter.
JeffSch:  Still concerned by what happens if the intermediary doesn't 
          understand a MEP.
Youenn:   I could write a proposal of this schema.
Don:      Jeffsch, you want an intermediary who doesn't understand the MEP 
          to understand the direction of the messages?
JeffSch:  if you don't understand the MEP, you should still understand the 
          schema describing the schema of the message.  2nd question, should 
          you be able to understand the direction of a message? Useful for 
          an intermediary.
Youenn:   In my proposal, in the wsdl file you would have a "direction" 
          parameter to say whether a specific message is input or output.
(discussion on sanjiva's proposal)
Youenn:   In both proposal, if you remove input/output operation you would 
          need to put this info in a different way.
Don:      I agree with jeffsch that we need a way to figure out 
          directionalitly. not sure what the best way to do that is. But 
          we can't take this info out.
Youenn:   You could have 3 different MEPs that match output-input pattern 
          but don't have the same scemantic.  Esier to have 2 specs in one.
          The soap request-reponse MEP identifies 2 messages. If you 
          receive multiple responses it is a different MEP.
JeffSch:  Request-response and solicit-reponse are 2 different MEPs because 
          different number of messages exchanged. Do you want a client to 
          be able to use a wsdl to describe itself?
Youenn:   Yes, a client can say I am node A or I am node B.  You can't 
          specify your role at the portType level because you might want to 
          take different roles in different operations in the same portType.
Jonathan: Let's break this discussion down in smaller items.
JeffSch:  Maybe we can see whether we can come to an agreement on what 
          properties of the component model is needed to be able to tell that 
          you are using the same MEP on both sides of the wire.
Don:      Do we want to go down the road of defining what an abstract MEP is?
Jonathan: Youenn's suggestion can work with that fine.
Youenn:   Our proposals are very similar. The only difference is whether the 
          specification of which node is in the spec or in the wsdl.
Jonathan: The abstract MEP template would define a URI for the MEP. It might 
          expose a role property with Youenn's proposal. In Youenn's proposal 
          we get fewer URIs.
Tom:      Advantages to not doing MEPs in an abstract way?  Does wsdl 1.1 
          have implicit MEPs or no MEPs?
Gudge:    You can think of 1.1 as having implicit MEPs.
Tom:      A "good" wsdl processor will have a lot of work to support lots of 
          MEPs.  Is this worth it?  The people who use WSDL to describe 
          arbitrary things, will abstract MEPs help them?
JeffSch:  Question of extensibility. We will define 4 MEPs. People can 
          create more. Usual challenge of interop with extensibility.
Jonathan: It is a given that we need to solve the pb of reconciling with 
          SOAP. The second question is whether we need to define 
          extensibility.
Tom:      Extensibility is ok as long as the basc ones are clearly defined.
          We can't just say "somebody will figure it out", we are going to 
          have to spec it.
Jonathan: Not clear to me while people would use MEPs to do choreography 
          kind of things.
JeffSch:  "Abstract" means you are not saying whether it is soap, what 
          transport?
Amy:      Yes, abstract says how many messages, but not the transport used.
JeffSch:  We need to clearly define abstract. Will the abstract MEP define 
          how long you should wait for the response?
Amy:      I don't think the abstract MEP would define that. But not at the 
          protocol level either maybe. In the concrete MEP.
JeffSch:  Would abstract include sequence and cardinality of messages?
Amy:      Yes.
JeffSch:  Just trying to clarify.
Michael:  Would like to see what is fixed and what is variable in an 
          abstract MEP.
Tom:      How many URIs do I have to hard code in my WSDL processor? Not a 
          lot I hope
[<alewis> One of the problems with MEPs is that *no one* wants to consider 
          them in scope for their working group.  So we get minimal 
          definitions.  If Arch takes it up, we'll be in better shape.]
Tom:      What if the arch group does something we don't like?
Jonathan: We comment.  SOAP has already specified it well, and the people 
          are the same. I am not too worried.
Tom:      Everyone agrees that the four implicit MEPs in wsdl 1.1 are useful.
Jonathan: We got into this discussion because we considered removing some 
          MEPs.
Tom:      A lot of people now expect notifications.
JeffSch:  We should move on to the next topic in this conversation.
Jonathan: Don, is a real pub/sub one of the 6 you propose?  Did we drop 
          the action item on pub/sub from Paris?  Should there be a 
          different pub/sub group?
Dale:     A lot of people discussed the MEP type but there is more to 
          pub/sub.
Jonathan: There might be a "standard" pub/sub portType.
Amy:      We are looking for the description of a MEP so that we can bind 
          them to pub/sub protocols.  In many cases it won't expose things 
          like subscribe to the app level.
Jonathan: Pub/sub discussion seems orthogonal to the MEP discussion.
          People can build pub/sub on top of the MEPs we are discussing now.
JeffSch:  is the question whether don's abstract works for the way people 
          want to do pub/sub?
Gudge:    MEPs are for message patterns, not programming models.  At the 
          portType level, not at the binding level.
Tom:      MEP would live at the portType.  If we commit to output/input 
          MEP, we need a binding to implement that. TCP binding for instance?
Gudge, jeffsch: For instance.
[<alewis> Other possibilities for solicit-response examples: JMS, IP 
          multicast, net-news, arguably email.]
Tom:      Yes we want the abstract model. operations will now have a new 
          attribute, a URI pointing to a MEP. and will have at least one 
          binding that implements each MEP.
Gudge:    +1 to giving more work to part 2 editors...
Jonathan: TCP binding is just one example. should not go through the work 
          of doing binding just to show that it works.
Don:      +1, we should not do a toy binding. Non-toy bindings would be 
          JMS or email.
Tom:      If we don't spec the binding for output/input, we are going back 
          to the same situation as wsdl 1.1.  As an implementer, what do I 
          do if I get a binding I don't understand?  If it's 
          request/reponse, we have SOAP/HTTP as the lowest common 
          denominator scenario. what is it for output oeprations?
WilliamV: +1 to tom
(Discussion on whether Axis implements SMTP)
JeffSch:  Need to clarify things. we can't just say input/output. one 
          message each way? what wait time?
Jonathan: In youenn's proposal, what does the binding look like on the 
          "other" side of request-reponse (other than the server side that 
          we understand because it's like wsdl 1.1)?
JeffSch:  In the past, you don't describe clients, just services

--------------------------------------------------------
10:30 Break
10:50 Message Exchange Patterns (cont.)
--------------------------------------------------------


Jonathan repeats his previous question (before the break): "In youenn's 
          proposal, what does the binding look like on the "other" side 
          of request-reponse (other than the server side that we 
          understand because it's like wsdl 1.1_).  We assume here that 
          we want a wsdl file for both.
Don:      What is the use case for the client publishing a wsdl?
Tom:      I don't want to bring the SOAP concepts of nodes and stuff into 
          WSDL. WSDL must keep a server-centric view.
Youenn:   We are service-centric, not server-centric. a service can act 
          as a client.
Tom:      WSDL describes the service from the point of view of the provider.
Youenn:   My proposal describes services, not clients. it is based on what 
          node you act
JeffM:    There is still a client and a service role. Traditionaly, the 
          client role is the one that initiates the message.  But for 
          output messages it gets reversed
Gudge:    Whether the provider or something else sends the first message is 
          orthogonal to the question we are trying to anwser.  The question 
          is : "what is wsdl written from the point of view of"?  Looking 
          at the wsdl you can tell who is the initiator. I don't think both 
          ends should have the same MEP so that I can describe things from 
          the point of view of the service.
Jonathan: So gudge you're taking issue with Youenn's proposal.  There are 
          lots of ways to describe output operations, and doing it as a 
          reversed view of the same MEP is not the way to do it 
          (jonathan is trying to rephrase what gudge said).
Igor:     It's just a syntactic difference.
Gudge:    The portType has no notion of SOAP.
[alewis:  I don't agree at all that solicit-response is a mirror of 
          request-resposne, and I don't think it's a useful conceptual 
          model.]
Youenn:   Don defines MEPs at portType level, as a bunch of nodes. There is 
          no notion in this definition of MEP of what is the service.
JeffSch:  Let's not speculate on what the orchestration WG will do.
Youenn:   If you define MEPs as sequences of input and output you don't 
          define them the way it is done is SOAP.
Gudge:    That's fine, no SOAP at the portType level.
[dbooth:  My previous analysis of Output-Input, etc., which analyzes 
          different viewpoints: 
          http://www.w3.org/2002/09/11-wsa-dbooth/output-input_clean.htm]
Youenn:   If we are going to reuse SOAP's notion of what is a MEP, we need 
          to define what node is a service.
{kevinL:  +1 to amy and others that solicit-response is NOT a mirror of 
          request-response.]
Gudge:    If WSDL is always written from the point of view of a service, 
          why do we need to specify which node is a service?
[dbooth:  (One viewpoint being service-centric, the other being 
          non-service-centric.)]
[alewis:  I agree with Gudge.]
JeffM:    If we take gudge's viewpoint that wsdl just describes the service. 
          For output-input, is there a wsdl that describes the one that you 
          are sending the message to?
Gudge:    As a service it doesn't matter to me whether the other end has 
          a WSDL or not.  If you have input-output and I want to send you a 
          message, do I need a wsdl?
JeffM:    No, you're right.
Gudge:    It's much easier for both parties if the wsdl is written from one 
          person's perspective.
Dbooth:   You need to know what role you are playing. The url in the service 
          element says who is what. Having wsdl described from the point of 
          view of the service, there are still 2 parties described, one 
          implicitely (the client) and one explicitly (the service). So it's 
          just a question of prefered style.
Gudge:    We had this discussion at a previous f2f (paris) and we agreed 
          that wsdl would be described from the point of view of the service
[alewis:  +1 to Gudge.  WSDL == webSERVICEdescriptionlanguage]
JeffSch:  Does this have an impact on Youenn's proposal?
Youenn:   It doesn't.
JeffSch:  We agree that there are (at least) 2 roles. Can be implicit (status 
          quo) or explicit (Youenn's proposal).
Youenn:   No, only the role of the service is explicit.
JeffSch:  The wsdl would say there are 2 parties.
Youenn:   No, just one.
Gudge:    wsdl is already described from the point of view of the service, 
          Why then would we need to add anything?  Mapping with SOAP MEPs is 
          a binding issue, it has nothing to do at the portType level
JeffSch:  If there are more than 2 parties, it feels like orchestration to 
          me and we should not focus on this until we hear from the 
          orchestration working group.
Jonathan: Do people disagree with the way jeffsch draws the line with the 
          orchestration work?
Dbooth:   Does this mean we could not use wsdl to describe an intermediary 
          (because this would mean 3 parties)?
All:      Yes
JeffM:    The implication is that I cannot describe a proxy using a MEP?
[Steve:   Is orchestration the same as choreography?]
JeffSch:  The proxy would be transparent (that's one way).
JeffM:    But then you're not describing it.
[dbooth:  steve, yes, for the purposes of this discussion.]
JeffSch:  The other way is to have 2 wsdl documents, one from the inside 
          and one form the outside.  In any case you need 2 ports since 
          there will be 2 endpoint URLs anyway. So maybe this is a use case 
          for why a service needs more than one portType.
Dbooth:   This would be the workaround if you cannot describe the 3 parties 
          in one wsdl doc. Youenn's proposal is trying to improve by: 1) 
          factoring a little bit more in the case where they are direct 
          mirors and 2) allow to describe a service that interacts with 
          more than one other party at very low cost.
Youenn agrees with dbooth.
[dbooth: (dbooth was not indicating a position, but merely confirming his 
          understanding of Youenn's proposal.)]
Youenn:   Another benefit is to directly abstract SOAP MEPs to WSDL, makes 
          it easy to abstract SOAP MEPs to abstract WSDL meps.
Gudge:    My proposal also does that (by saying that the WSDL always 
          describes node A).
Jonathan: Our abstract request-reponse URI would be different from the 
          SOAP request-reponse proposal?
Youenn:   At the portType level, we should abstract from the SOAP MEP and 
          give it a new URI.
Strawpoll: Do we want to describe more than 2 node roles in our message 
          exchange patterns?
Strawpoll: Do we want to support the creation of MEPs that have more than 
          2 node roles? (this overrides the previous strawpoll sentence)
Gudge:    Let's limit to 2 and if we find out something is critical let's 
          expand later.
Igor:     People can create any kind of MEP they want. are we trying to 
          limit them to 2 nodes or just limit the MEPs that we create?
Youenn:   If a SOAP MEP can have more than 2 roles, I would expect WSDL to 
          use this.
JeffM:    If we were to define a 3 way mep, we wouldn't necessarily have 
          to define all the possible combinations, just what people find 
          useful.  If someone came up with a well-defined n-way MEP, we 
          shouldn't dismiss it.  It's not really about number of roles, 
          it's that we are doing things from the service point of view 
          and the other roles are implicit.
JeffM, dbooth: Saying that the other role is implicit implies that there 
          is only one other node.
JeffM:    What if I have a notification service (output only)?
Gudge:    There is only one other role. there could be 3000 subscribers, 
          but they share one role.
JeffM:    And that role would be implicit.
Gudge:    If there are 2 differnt roles that the person receiving the 
          notification might play, then you define 2 MEPs
[<alewis> +1 to Gudge's analysis: let's start with 2-role MEPs, see if 
          someone produces a use case that clearly requires more.]
JeffM:    The important thing is that the roles are implicit, not how 
          many there are.
Igor:     Semantically there is no difference.
Jonathan: Back to strawpoll, do we need to change the wording?
Strawpoll: Should we permit MEPs with more than 2 roles
youenn:   What if the SOAP group defines a MEP with 3 roles? we should 
          support it.
Gudge:    There isn't one currently and XMLP is not going to define one now.
Strawpoll: in favor 3, against 11, abstain 6

Potential strwapoll: Do we want to expose the role as a separate component
          model property in the portType?
Igor:     MEP can be define as a feature.
[<dbooth> I think the essence of this issue is that we are sitting on a 
          slippery slope.  If we allow *some* MEPs to be defined, it's 
          hard to draw the line about where we should limit them.]
Jonathan: Our component model today does not contain a URI-type property 
          at the portType level.
Gudge:    Part of Don's proposal is to name MEPs with URIs.
Dbooth:   I like the idea of flexible MEPs but it becomes difficult to draw 
          the line on what we should allow, and how what we allow would 
          overlap with what the choreography WG would define. So do we 
          want such flexible MEPs?
Strawpoll: Do we want to expose the role as a separate component model 
          property in the portType?
Strawpoll results: in favor 1, opposed 11 abstain 8

Jonathan: Should we change the variety property to be a URI? (in wsdl 
          1.1 it is implied by the order of the elements)
Gudge:    Alternative is to define extra values for the enumeration for 
          any extra MEP we define. 3 possbilities: 1) don't change 2) add 
          more values to the potential list of values 3) make it a URI.
          Should it be a closed set or an open set?
Tom:      If we don't make it open, there won't be a MEP to support 
          publish/subscribe (unless we define it in the spec)
Gudge:    Pub/sub is a programming level concept

-------------------------------------------------------
12:00 Lunch
-------------------------------------------------------


[Igor scribes]

Topic: Publication issues
Jonathan: Part 1 and part 2 are ready for review.  When to call on 
          objections to publication?
Arthur:   What about portType and interface terminology. that was agreed 
          to fix in the doc.
Gudge:    Does not remember anything on the mail about it.
Arthur:   Agreed long time ago, before VA meeting.
Gudge:    Will look for that.
Jonathan: For this publication, terminology change was not on the list.
[<dbooth> http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/0084.html :
 <dbooth> [[
 <dbooth> Keith : should we use portType instead of interface?
 <dbooth> Minor disagreements
 <dbooth> ]]
 <dbooth> That's the only mention I find of terminology change to 
          "interface" in the minutes.
]
Arthur:   Need to batch up all other proposed changes to the doc as well.
Jonathan: Let's put the terminology on the agenda and this one (portType)
          too
Gudge:    Can't find any decision on termonology of portType going back to 
          April
Jonathan: Let's get the issues closed.
Tom:      It may be too late if someone uses portType
Steve G:  e.g. UDDI.
JeffSch:  Look at the requirements for WSDL, it was changed there...
Arthur:   Was it not decided for AM
[<plh-az> http://www.w3.org/2002/Talks/www2002-ws-desc/slide6-0.html 
          (WSDL example using interface/interfaceBinding)]
[<dbooth> Gudge, regarding "interface", see also: 
 http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/0073.html, which mentions:
 <dbooth> [[
 <dbooth> Here is a new list of definitions that were agreed today in our 
 <dbooth> teleconference call.
 <dbooth> . . .
 <dbooth> Interface (a/k/a "Port Type")
 <dbooth> A logical grouping of operations.   An Interface represents an 
 <dbooth> abstract  Web Service type, independent of transmission protocol and data 
 <dbooth> format.
 <dbooth> ]]
]
[Chair's summary: We should not wait until the bitter end for this, but 
neither should we take it up immediately.]

Steve G:  Since GGF suggested in interim draft, they would like a day or so
          to review it.  This is independent of the Grid proposals being
          made.
[Chair's summary: Agreed to move publication approval to Wed morning's 
agenda.]


-------------------------------------------------------
Topic: More on MEPs

Continuing on from morning session.
Jonathan: Poll proposal from gudge: variety property to be closed or open set
Gudge:    Just open or closed. Do we define the boundary here or not?
Roberto:  The property values are not limited.
Gudge:    Extensibility is about adding new properties.
Roberto:  Keep variety prop values closed set and let extensibility take care 
          of the rest.  Limiting variety prop does not actually limit anything.
          Therefore it is not the right question.
Jonathan: We can't disallow any ext, but we can discourage it in certain 
          places. This is the case here.  Variety is a set of predefined 
          values (closed) or just a URI (open).
Gudge:    Is there a different Q to ask here?
Tom:      MEPs is the place for mess, WSDL just points to that mess.  Should 
          we even bother limiting that mess or not?
Jonathan: Issue to solve is syncing up SOAP MEPs and "abstract" MEPs. Came 
          down to how to specify it better.
Tom:      Changing WSDL is the interesting part. If we stick URI of a MEP it 
          has to be open in WSDL sense.
Gudge:    Why?
Tom:      Darwinian IT :)
Gudge:    Abstract is directly translating to syntax so far, but variery prop 
          is bothering me.
Jonathan: Closed or open?
Prasad:   Makes sense to keep it extensible. use existing framework to do so. 
          Closed is bad.
Gudge:    Explicit extensibility point that we specify as opposed to general 
          "do anything" extensibility.
Prasad:   Yes. Instead of extending the language, just use the provided 
          extension point for good.
Jonathan: Don's abstract MEPs framework is it ...  Open or closed at last...
Strawpoll: Open or Closed
17 for open, 1 for closed, 5 abstains

Jonathan: Is the enumeration is the best form or a URI?  Is there a better 
          name than variety (after roberto)
(no one opposed to use URI)
Gudge:    Component model as MEP and serialize it as something later
JeffSch:  let the editors decide on the name of the serialization (attribute)
(nobody objected - will probably be named "message exchange pattern").

Jonathan: next Q: URI that points to smething and indicates MEP. how to 
          formalize this
[<alewis> <operation mep="uri" />]
Gudge:    URI is just an ID
Jonathan: What the Q to move Don's proposal forward...
Don:      Do we define the MEPs that we care about and list them out in our 
          spec?
Jonathan: i.e. the list of MEPs that we want to standardize
JeffSch:  Ordering: decide what MEPs we want, then use that to generalize the
          framework, then how they look.
Jonathan: Isn't there still some ambiguity still
[<Gudge> (I), (O), (I,O), (O,I), (I,O+), (O, I+)
 <alewis> Gudge: s/+/*/
 <alewis> Gudge: I think that it's true, though.  Most multiple-response MEPs 
          are likely to response*, not response+
 <Gudge>  Right, it's fine, you're right
]
JeffSch:  ... 7 MEPs...
(discussion on IO OI IO OI...)
[<scribe> [I lost it here...] :)]
JeffSch:  Writing down those MEPs on the wall :)
Don:      Factor in the faults
Tom:      Faults are and have to be in the interface def
[<Gudge> A. IN
 <Gudge> B. IN, (OUT | FAULT )
 <Gudge> C. IN, OUT*, (OUT | FAULT)
 <Gudge> D. OUT
 <Gudge> E. OUT, IN
 <Gudge> F. OUT, IN*
 <Gudge> C1. IN, (OUT* | FAULT)
 <alewis> D == OUT, FAULT*
 <Gudge> Not on the board it doesn't!
 <alewis> Oh, no.  Wait.
 <alewis> D == OUT, FAULT?
 <alewis> E = OUT, (IN|FAULT)
 <alewis> F == OUT, (IN*|FAULT*)
 <Gudge> C. (IN, OUT*) | (IN, FAULT)
 <Gudge> I'm having trouble keeping up
 <Gudge> C1. IN, (OUT* | FAULT)
 <Gudge> C2. IN, (OUT2+ | FAULT)
]
JeffSch:  Anyone can define their own MEPs. Just what will cover 90% cases 
          that we have to worry about here.
[ c3. in, (out 2+ | fault)
  c4. in, out*, (out | fault)
  e. out, (in | fault)
  a1. in
  a2. in, fault?
  e. out, (in | Ifault)
  g. out, in, Ofault
]
JeffSch:  [talking about] ordinary msg or a fault and then direction
Gudge:    Distinction of ordinary and fault does not change MEP, does it?
JeffM:    Can one say you always get a fault then?
DBooth:    Agrees with gudge.
JeffSch:  There could be fire-and-forget MEPs at the level we're modeling.
Tom:      We'll have to clarify what to do with the faults and where did 
          they come from.  Wants clear spec, but agrees with gudge...
Amy:      Anywhere where is response there could be a fault.
JeffSch:  e.g. a sequence of faults...
[* plh-az (in, out, ofault, ifault)*
 * plh-az (in| out| ofault| ifault)* actually
]
JeffSch:  Proposal on the table: get rid of faults in the MEPs specs.
JeffM:    What about just only fault in return?
JeffSch:  State diagrams would define that, grammar we're at is not 
          preventing it.
[<alewis> I think that the argument is that *any* message can provoke a 
          fault.  Which doesn't mean that the fault is deliverable, of 
          course (the current input-only pattern is an example of 
          undeliverable faults).]
JeffSch:  Only last one could be a fault.
Gudge:    Faults are out.
JeffSch:  We need to agree where the faults could appear [to help WSDL 
          processor developers, I guess].
DBooth:   We should not be specific where and when fault can occur in 
          the MEPs.
JeffSch:  The convention would be then: any IN or any OUT could be a 
          fault in a MEP.
Amy:      Faults travel in the direction opposite to IN or OUT.
MikeM:    Any subsequent msg can be a fault.
Amy:      There could be undeliverable faults.
JeffSch:  In SOAP model one has to generate a fault, but does not have 
          to send it :)
[tom & amy discussing delivery of faults]
JeffSch:  Prioritize our "care about" MEP list and let others do more.
Prasad:   Wants to model faults in MEPs.
MikeM:    Contrain MEPs to 2 msgs for the prioritization that we do.
[<alewis> Is that constraint on the MEPs that we are willing, as a 
          working group, to consider defining?  Or a hard limit on 
          what is to be considered a MEP?]
JeffSch:  Then "MEPs are a seq of 1 or 2 msgs".
[<TomJ>   I think we are defining the scope of our work, not a limit 
          on what a MEP is.]
[<DonM> Hopefully the former.]
[* plh-az H. IN, OUT, IFAULT ]
DBooth:   Treat faults as completely async, out-of-band msgs. Fault can 
          be triggered by a power outage, not an IN msg, for instance.
          Model faults separately from MEPs.
JeffSch:  We need to say all about req-response.
Gudge:    Msg in, msg out, why not it be a choice of messages, some 
          are faults? Just alternative out msgs.
[Whiteboard at this point: (see http://www.w3.org/2003/01/meps.txt)
A.
 +A1.   IN
 A2.    IN, OFAULT? "NACK"
 A3.    (IN | IFAULT)
B. (REQ-REPLY)
 B1.    (IN | IFAULT), (OUT | OFAULT)
 +B2.   IN, (OUT | OFAULT)
 B3.    (IN, OUT, IFAULT?) | (IN, OFAULT)
C. (REQ-REPLIES)
 C1.    IN, (OUT* | OFAULT)
 +C2.   IN, OUT*   (+ FAULTS TBD)
 C4.    IN, OUT*, (OUT | OFAULT)?
 C5.    IN, (OUT | OFAULT)*
D.
 +D1.   OUT
 D2.    OUT, IFAULT? "NACK"
+E.     OUT, (IN | IFAULT)
+F.     OUT, IN* (+ FAULTS TBD)
G.      OUT, IN, OFAULT
H.      IN, OUT, IFAULT
]
DBooth:why call them faults then?
[<alewis> Gudge: the problem with that is that the second message in 
          the sequence then *cannot provoke a fault*.
 <Gudge>  Amy: I think that for a given MEP that might be just fine.
 <alewis> Gudge: But for others (OUT, IN*), it really isn't okay.  
          All of the respondents should be able to receive a fault 
          message as a response to their response messages.
 <Gudge>  So that MEP is actually OUT, IN*, OUT?  ? So that MEP is 
          actually OUT, IN*, OUT? or OUT, (IN, OUT?)*
 <alewis> Gudge: It would have to be more like OUT, IN*, OUT*, if you 
          really want to be able to say something quite so silly.
 <Gudge>  Sorry, didn't realise it was silly :-(
 <alewis> Gudge: I think it works far better to say that it's OUT, IN*, 
          and to say that every message in a pattern can trigger a fault 
          which travels in the opposite direction.
 <Gudge>  So, is that a general statement that applies to ALL MEPs? Or just 
          specific MEPs?
 <alewis> Gudge: Saying that each message can trigger a fault (which will 
          travel in the opposite direction) is not the same as guaranteeing 
          delivery, though.  That will depend upon the binding.
 <Gudge>  Oh, I agree, I'm just wondering if your statement applies to all 
          MEPs at the operation level or just certain MEPs
 <alewis> Gudge: I would say it applies to ALL MEPs, but that the *binding* 
          may restrict the faults that can be *delivered*.
 <Gudge>  Ah, I would go the other way. I would say that for 
          http://www.w3.org/MEPs/FireAndForget there is no option for a 
          fault to be generated.  But for http://www.w3.org/MEPs/OneWayMsg 
          this is an option for a fault to be generated.
 <alewis> Gudge: Because then, one can model HTTP's implementation of 
          IN, OUT as able to fault for either message, noting that a fault 
          generated by the output message cannot be delivered.
 <Gudge>  Amy: But why is that useful?
 <alewis> Gudge: But implementing the same MEP, asynchronously, in email, 
          one would say that that fault which is undeliverable in HTTP is 
          perfectly deliverable.
 <Gudge>  I really, really want to keep this discussion at the port type 
          level. I don't want to be forced to allow faults for every MEP.
          I SHOULD be able to define a MEP that does not admit to faults.
 <alewis> Gudge: So do *I*!  In terms of the MEPs defined at the portType 
          level, I think we say that every message defined can generate a 
          fault. Gudge: Why?  Can you write code that doesn't fault, 
          guaranteed?
 <Gudge>  It's not about whether the code will actually work.
 <alewis> *sigh*
 <Gudge>  Sorry to be so dense.
 <alewis> Gudge: It eases the definition of MEPs if one can exclude 
          consideration of faults from them, correct?  If so, it helps a 
          great deal to be able to say, blanket, that faults can be 
          generated in response to *any* message.
 <Gudge>  Yes. But I can see saying for one MEP 'there are never any 
          faults' and for another MEP any message can result in a fault 
          transmitted in the opposite direction'.
 <DonM>   Gudge: So if that is the case, should we capture that in the 
          definition of a MEP -- never fault or may always fault?
 <alewis> Gudge: Okay.  But now faults are back in MEPs, because we are 
          distinguishing between IN, OUT [no faults result from OUT] and 
          IN, OUT [fault may result from either message].
 <DonM>   Amy: Right, which would result in N*2 MEPs, possibly....
 <alewis> Gudge: Because what you're defining, I think, is a list of 
          messages in the pattern for which fault responses are legal, 
          not just faults: yes/no.
 <DonM>   Amy: Which is not necessarily the right direction re: reducing 
          scope of work.
 <Gudge>  Amy/Don:  OK, in the interests of reducing scope, for now lets 
          make the simplifying assumption that every message might result 
          in a fault being sent in the opposite direction.
 <alewis> Gudge: It seems to me conceptually cleaner to say that any 
          message can produce a fault, but that in certain MEP bindings, 
          some fault messages may be undeliverable.  This covers, for 
          instance, the difference between HTTP IN, OUT versus email IN, 
          OUT.
]
DBooth:   Not a glorified out, model faults separately.
JeffSch:  In SOAP case the out and fault messages do look differently.
MikeM:    What does out-of-band mean, not part of WSDL?
DBooth:   Not part of MEP, which defines what's expected and what's 
          not expected is modeled with something else.
Prasad:   Wants to model negative responses in the interface itself 
          (e.g. a login error).
MikeM:    Out-of-band is different from not expected. Still wants faults 
          visible.
DBooth:   Yes, visible
JeffSch:  Presenting operation MEP table
[ see http://www.w3.org/2003/01/meps.txt
<operation meep="rr">
 DIR     MSG   FAULT?
 ---------------------
 IN     MY:X     N
 OUT    MY:Y     N
 OUT    MY:Z1    Y
 OUT    MY:Z2    Y
 OUT    MY:Z3    Y
</operation>

JeffSch:  It's possible to write a grammar that defines a MEP quite 
          formally. How does the grammar and the presented table map. 
          It is not deterministic.
JeffM:    Is it possible to add binding-specific faults?
JeffSch:  Faults in ops += faults in bindings.
Tom:      There isn't anything extra in the MEP that pertains to 
          faults, didn't we decide already?
DBooth:   Suggested that faults are not part of expected sequence of 
          messages in MEP, but faults are still part of the operation 
          def in the WSDL though.
Tom:      Any out could be a fault.
Roberto:  Every msg but the first can be a fault.
Amy:      If any msg can be a fault, then last one can't be the fault.
          Because one cannot receive it... ???  E-mail case, faults 
          run in either dir and in place of the messages.
JeffSch:  Need to say where faults are allowed.  We're not stating it 
          about all possible MEPs, though.
DBooth:   What the fault can be? Is it in response to something, or 
          it just happens?
[<alewis> Who are you going to send *that* fault *to*?]
Tom:      The message that comes back instead of response. I don't 
          need to worry about delivery [???]
Gudge:    Describing MEPs does not affect the number of MEPs we have 
          to care about.
[<dbooth> alewis, the recipient may be known from previous interactions
 <alewis> I agree, we should postpone this issue and move on to discuss
          other issues.]
Gudge:    Choose any design approach for faults and move on.
Tom:      I don't need to worry about checking for faults when the MEP 
          I am using doesn't say I have to listen for anything.
Jonathan: Too arbitrary.
[<alewis> dbooth: The idea of sending a fault as the initial message of 
          a pattern (when fault, to me, implies application-level error, 
          not system error, which may even be modelled as messages in 
          exchange patterns) is just surreal to me.
 <dbooth> alewis, the assumption is that it is part of a larger 
          interaction sequence.
 <alewis> dbooth: That's an assumption that strikes me as less 
          justifiable than the assumption that every message can 
          generate a fault.  And I still don't see why application 
          faults would be generated to describe system errors. Or else 
          is an issue to be left to choreography.  But it's prolly time 
          to stop arguing.
]
JeffSch:  MEP will have to state something about the faults: when and 
          where they could appear.
Gudge:    Forget about faults and make decision about MEPs, then tackle 
          the faults.
Tom:      We already have made some progress on faults...
Amy:      Whatever we do is not going to change SOAP MEPs... We can't 
          exclude the faults.
JeffSch:  E-mail case: send a message and who cares. There is no 
          response no fault required at the application level.
[* dbooth also thinks we should address the issue of faults separately.]
JeffSch:  Circles a1, a2, d1, d2.
 A1.   IN
 A2.   IN, OFAULT?
 D1.   OUT
 D2.   OUT, IFAULT?
 B2.   IN, (OUT | OFAULT)
 E.    OUT, (IN | IFAULT)

<plh-az> use '+' in front of [A-H] to represent the red circles: http://www.w3.org/2003/01/meps.txt]

Tom & jeffsch: what binding to cover e,f... let's have e-mail binding...
Jonathan: In and out only are useful for orchestration, out-in... where...
Tom:      An example is needed
Jonathan: Who will implement TCP/IP binding even if we define one?
Tom:      How useful out-in is then?
Jonathan: [consistency...]
Tom:      If those ops are non-interop we need to remove them.
Jonathan: Abstract fwk covers MEPs consistently, but we don't have to 
          create all the possible binding that make use of that fwk.
Don:      Fwk covers binding too.
Jonathan: Enable other people use this std properly.
JeffSch:  For the symmetry argument, e. is necessary (circled)
Tom:      a2 is a case of in-out
[<Gudge>  So, there are roughly 12 MEPs on the whiteboard and 24 people 
          in the room....
 <TomJ> 2 people per MEP!
]
Tom:      Where the only out allowed is a fault message.
Prasad:   A2 was already voted out.
[<alewis> I disagree violently with that characterization; it appears 
          to be based on using nothing but synchronous, connection-
          oriented protocols.
 <TomJ>   But MEPs are about messages, and the fault message returning 
          from a input-only op is an output message.
 <alewis> No, it's a fault message.  If we agree that faults are 
          orthogonal to the exchange pattern, this multiplication of 
          the rabb^W patterns becomes unnecessary.]

Jonathan: Which MEPs we'll spec.
JeffSch:  Proposed to exclude 1-N cases to constrain the work that 
          needs to be done.
Amy:      Enormous nb of MEPs because of the faults.
Amy:      arguing for F
[<dbooth> f = OUT, IN*
 <dbooth> f2 = OUT, (IN | FAULT)*]
DBooth:   needs some general rule about faults
New list:
 a1. in
 b2. in, (out | Ofault)
 c2. in, out* (+faults TBD)
 d1. out
 e.  out, (in | IFault)
 f.  out, in* (+faults TBD)

Jonathan: Is this list a consensus?  Is it a working proposal?
DBooth:   Still need to state where in general faults appear.
Gudge:    They were explicitly included in the list of MEPs above.
DBooth:   General rule is preferable. this is key.
Gudge:    Tom's generalization: any msg but first can be a fault.

Will take up David's question and fill in the TBD faults later on.


15:00 Break
15:20 Properties and Features
    - Amy's summary [6], and suggested agenda
    1. Scope
      a. Should WSDL support only description of SOAP features and
         properties, or features and properties more generally?
      b. If only SOAP features and properties, should the namespace be
         the WSDL SOAP namespace, or the WSDL namespace?
      c. If features and properties generally, should WSDL propose a
         universal syntax, or let each feature definition mandate its
         own?
    2. Concrete Binding
      a. Should the current <binding> tree be separated into
         <messageBinding> and <protocolBinding> trees?
      b. Should the concrete binding syntax live in <binding>,
         <messageBinding>, <protocolBinding>, or <service>?
      c. Where, exactly, in the preferred subtree may the new
         syntactic elements appear?
      d. What are the new syntactic elements?
    3. Abstract Binding
      a. Should it be possible to specify required features and/or
         properties in the <portType> tree?
      b. If so, where in the tree may these requirements appear?
         (portType, operation, individual messages)
      c. If so, should consistency checks be performed to ensure that
         a binding that claims to implement a portType contains
         concrete bindings for required features/properties?
      d. What are the new syntactic elements?

  [6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0033.html

Topic: properties and features
1.a should WSDL support SOAP f/p or more generally?
[<DonM> See also: http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/att-0083/01-terse-features.html]
Gudge:    SOAP features @ portType level
Roberto:  Concerned about testability. Abtract features are very 
          difficult to test.  Message signing, for instance. at the 
          abtract level it is easy to say, but making it concrete is 
          very tedious and lots of variations.
Glen:     Not to describe every possible interaction, just give an idea 
          what is required. Fwk for doing it, but not known how far one 
          can go with it.
Don:      Adding first class features that can be reused by other specs.
Roberto:  One can use abstract portion of WSDL and that complicates it.
          When connecting to svc binding are enough, why is it necessary 
          to repeat it at the abtract level?
Don:      Fuzzy on abstract, but solid on concrete...
Jonathan: Does this mean yes or no for 1.a?
Tom:      Example features besides SOAP?
Gudge:    We just support any.
Glen:     Features are applicable to a wide range of things, and this 
          is what do discuss.
Tom:      Are these generic switches for SOAP props/features?
Glen:     Yes, similar.
Jonathan: Is security such example generic feature?
Glen:     Tagging things with URIs is really important and it makes it 
          clear what's involved.
Roberto:  In paris it was decided to go with QName extensibility. Why is 
          QName not useful for doing exactly that?
Umit:     URIs are more robust.
DBooth:   URIs are more likely to be dereferencable.
Roberto:  URIs are just strings and QNames can hold structured data.
Jonathan: What we get from doing this at the abstract level?
Gudge:    Tom will have to remember all those URIs :)
Glen:     Originally properties were QNames. This is not important now. 
          QNames have a problem with RDF mappings. Need a common way 
          to talk about common things extending WSDL. Requirements and 
          restrictions.
Jonathan: Spec writers writing a clean spec.. with QName we don't 
          provide a good way....
Gudge:    We have substitution groups...
Jonathan: f/p proposal is easier, but lacks the flexibility in comparison
Glen:     The semantic that affects the "wire" is what's important.
Jonathan: How is it different from the existing language ext model
Glen:     When writing exts, f/p shows the way. best practices...  It is 
          also SOAP 1.2 compliant and therefore it is "architecturally" 
          natural.
Jonathan: Opinions?
Jonathan: Examples are needed
Umit:     Have not seen compelling arguments for the change
JeffSch:  Need more discussions.
Glen:     Can start with SOAP and we have to capture that. we could do 
          it other way, but more natural is to follow the same approach 
          as in SOAP. Narrowing ext model with f/p is not making it 
          worse than it already is.
JeffSch:  Table this discussion and deal with it later.
Glen:     ok
d??:      decided to identify MEPs as URIs and it sounds a lot like 
          feature. it seems 1.a. we've already done it at the abstract 
          level and just say that we have it.
Gudge:    You could already do this given what we have, glen just wants 
          to make it more specific.
d??:      Just document it then and that is it.
Jonathan: Suggestion to table 1.a for a while until we see the value of 
          SOAP f/p in the binding (next F2F, possibly)... anyone?
JeffSch:  So 1.a is answered SOAP 1.2 way?
Jonathan: Just saying table 1.a
Don:      Wanted to define message correlation as an abtract feature...
Glen:     Yes, but there is no other binding except SOAP that needs this
Don:      for out-in and all
Glen:     Can say 1.a postponed and let's deal with SOAP 1.2 f/p
Gudge:    Sanjiva also has input here...
Jonathan: No objections to postponing 1.a.
Jonathan: Skip the whole f/p topic as key people are missing.
Don:      What the best resolution on f/p for the grp.  Should we just 
          form a TF.
Jonathan: There is no clear statement so far as to why is it needed.
Glen:     TF should create a few examples. syntax too,
Gudge:    Better do the examples at the component model
Jonathan: How much is syntax and how much is CM
Gudge:    What the props are and what they mean has to be understood.
Glen:     The CM is hanging off the service description and the f/p 
          are the runtime details.
Gudge:    why in WSDL?
Glen:     Because of binding details.
Glen:     Different binding can do it differently, but stick to the 
          same semantics.
Roberto:  Strip out WSDL abtract features, does it prevent talking to 
          that svc?
Glen:     no
Don:      It just says the op has to be secure and then binding would 
          map it to proper transport or do the hdr work.
Roberto:  The abtract part can be used to model svcs and this is not 
          very necessary.
Glen:     Fwk is useful, though.
Roberto:  Why make it 1st class if it does not have any implications.
Glen:     An example is SOAP mustUnderstand... it allows things to be 
          done, but not mandates any.
Jonathan: Maybe we just don't have much experience extending WSDL 
          using existing ext model. Maybe we just have to come up with 
          examples of one and the other and compare then?
Jonathan: No objections to form the TF for that.

ACTION: Glen, Amy, Yoen, Sanjiva, JJM to form a TF on comparing ext 
        mechanisms, popose f/p reasoning and examples (use cases) for that

Jonathan: (1) portType op name conflicts or (2) finish up the faults
SteveG:   Let's continue on faults because (1) is too important for [Grid?]

Topic: Continuing on MEPs/faults
<plh-az>  back to http://www.w3.org/2003/01/meps.txt
Tom:      Any msg can be a fault, the last msg can be a fault?...
Tom:      Any out msgs can be a fault? is that true?
Jonathan: in, ofault | out*
JeffSch:
  c21. in,(ofault|out*); 
  c22. in,(ofault|out)*;
  c23. in, out*, fault?
Tom:      Can there be more than one fault? c22 is not acceptable 
          impl of c2.
Roberto:  No data fault and then yes not got the data for you.
Tom:      Fault means termination.
Gudge:    Agrees
c23 now
Gudge:    Last one is the termination message, essentially
Tom:      Proposes that c21 is not acceptable
Gudge likes c23
  c21 removed
  f1. out, in*, Ifault?
  f2. out, (in | fault)*
  f3. out, (in* | Ifault)
Tom:      Need to teat each MEP instance separately
Gudge:    No, service talks to the bus and the bus talks to 50 guys.
Umit:     It is like a broadcast.
Don:      Not modeling a 1-1.
Tom:      Each instance is different though, even if same MEP.
Gudge:    It is same as b2 anyway.
Tom:      Bus is not a WS assumption.
Gudge:    Broadcast is a different case then.
Umit:     It's very general, e.g. JMS.
DBooth:   When e-mailing to a list logically it's same as e-mailing 
          to one and broadcast is transparent.
Tom:      WS communication is P2P, e-mail is a different case'
Don:      It is not always P2P...
DBooth:   Are you saying that client in MEP represents a set? It is 
          very different than treating MEPs between single nodes.
Don:      Svc gets message from all arround.
Roberto:  In f1 fault allows control on how long the communication has 
          to go on.  In f2 is like receiving a reply from multiple 
          parties.
DBooth:   Do we need to model when a client is a set. Personally he 
          does not want to go there.
JeffM:    For pub-sub multiple of these models apply. which should be 
          defined in the core...
MikeM:    Value of use case in general should drive this.
Umit:     If it is not pub-sub it is P2P. we need to make this 
          distinction and classify MEPs accordingly.
JeffSch:  Specifying channel helps make it clear which MEP is which 
          class.
DBooth:   How can we specify client as a set. How are the end-points 
          layed out?
Don:      There are no client end-points.
JeffSch:  IRC is an example.
DBooth:   Recipient is decided transparently then?  It is possible to 
          model client set with just same MEPs. Just apply it to 50 
          instances of communication.
Jonathan: Is it compelling way to solve donm's issue?
Don:      One MEP from the svc standpoint, but it gets to deal with 
          many clients transparently.
Tom:      It would not be reasonable to spec this in this grp.
Don:      We have enough representation to make a proper decision on 
          this.
Tom:      If it is a commonly used MEP, then ok.
Roberto:  Mirror WSDLs... argues symmetry of MEPs
[<Roberto> the correspondence is: 
          a1 <--> d1 ; 
          b2 <--> e ; 
          c23 <--> f1 ; 
          f2 <--> b2 (surprise!)
]
Who will write these MEPs?
- f2 Amy will write about
- a1 tom agreed to write about
DBooth:   confused by the N-ary thingy in f2
JeffSch:  If it is possible to make a good MEP there, it is actually 
          very good
DBooth:   What is the client case for f2?
Gudge:    b2
DBooth:   Client generates code from WSDL what is it going to be?
Gudge:    The cardinality of the things at the other end and 
          cardinality of the messages and both have to be captured 
          in MEP and taken into account when gen code for svc and 
          the client.
JeffSch:  Client has to underatand the MEP of the svc...
Gudge:    N-ary applies to the whole thing in f2.
Jonathan: Details of that Amy has to explain (e.g. cardinality and scope)
Jonathan: Also sycn with WS Arch WG to see where it all [MEPs] goes...
JeffSch:  Wants to write first 6

ACTION: JeffSch and Gudge take first 6 MEPs to develop
...discussion on the place for faults....
ISSUE: where faults can appear, header faults, etc.
ACTION: Amy/Don take f2 MEP to develop

Roberto:  Only first 3 have to be fully defines and the following 
          3 are merely mirrored direction
Gudge:    Still wants separate URIs for identify all 6
Jonathan: separate, but complimantary

ACTION: for the editors to close (remove) out-only and solicit-response 
issues from the list (as covered by this MEP work)

17:30 Adjourn

-------------------------------------------------------
raw IRC log: http://www.w3.org/2003/01/20-ws-desc-irc
Received on Friday, 24 January 2003 14:42:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:22 GMT