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

Minutes, 4 March 2003 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 5 Mar 2003 12:31:40 -0800
Message-ID: <330564469BFEC046B84E591EB3D4D59C099D3FDB@red-msg-08.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Tuesday 4 March
09:00 7 MEP review (cont)

[scribe: Philippe]

(slides not available yet)
(Gudge does his presentation "An Interesting MEP")
  "A data item service"
  with HTTP binding, req-resp, single channel.
  n clients, one service.

  consider multicast binding
  n clients, one doing an input, the service doing n outputs.
  one input, one output (for n clients)

  from the client view, the http client sees a req-resp
  (I have 2 bindings, one for http, one for output only)

Marc:     the output is delivered through http?
Gudge:    no, no http involved.  I have a binding that says you 
          can send input and I'll broadcast it. Like IM or IRC.
          From the server propspective, it's an input/output.
Gudge:    both bindings refer to the same portType
Martin:   I assume that one binding is used for the input/output 
          but in your case, they could be different?
Gudge:    they are completely different bindings.
Umit:     adding multicast is a different MEP
Gudge:    that's more a binding issue than portType.
[sanjiva: I am temporarily on another call, but I note that 
          dealing with multicast responses require different 
          programming models - hence it must be represented at 
          the portType level.]
Marc:     what problem are you pointing?
Gudge:    How abstract are portTypes?  Is it reasonnable to 
          describe such a portType and bind it the way I did?
Glen:     The implications here that we have application semantic 
          on top of it. How do I express that I'm going to use one 
          binding on the input and an other on the output?
Jacek:    Gudge's case seems an optimization, we don't have to 
          care about it.
Gudge:    for me, it was interesting to have the abstract using 
          one MEP and have it completely different from the 
          consumer point of view.
Jonathan: wanted to make sure that this potential issue wasn't a 
          real one.
Glen:     still thinks that they are hidden issue in it, using 
          two differents bindings from the same service, but 
          that's ok for now.

Jonathan: can we collect any issue against the MEP stuff?
Jacek:    I don't see the motivation for MEP 7 as it stands, but 
          given the others don't have either, I'm fine.
Jonathan: ... beauty contest in the desert ... :)
jacek:    our MEPs won't allow more than 2 roles? or we won't 
          define some? if the latter, we should demonstrate that 
          it is possible.
Jeff:     use extensiblility
Amy:      where does an additional role stand? for the moment, 
          you have the service and everybody else. how do you 
          describe alternative among eveybody else?
Glen:     if you stick on each input/output a uri, you can 
          describe the message if you want.
Gudge:    you can do that, today but nothing in the syntax. The 
          MEP has an uri and describes what those NCName means, 
          so why does you need uris?
Glen:     it would be convenient. if there is ncname, it will be 
          harder to define scheme.
Gudge:    it's a pair ... a qname :)
Jonathan: anything else? Do we want to add the MEps in part 1, 
          part 2, other?
Amy:      numeric are somewhat opaque. We need a motivation for 
          each MEP. If somebody can't come up with a nickname and 
          a use case, it might not be a every common idiom.
[editorial discussion to have use cases]
Amy:      we need a sample for the MEPs.
TomJ:     what's the difference between MEP2 and MEP3?  MEP3 is 
          req and possible resp?
[alewis:  IN, OUT*, oFault?]
Jeff:     req and multiple resp. I can come up with names like 
          "one-way", "multiple-output" ...
Gudge:    what's the point?
Amy:      let's collect the justifications.
Jonathan: can we deal with it at CR time?
Tom:      collecting use cases is easy, but we are raising the bar 
Gudge:    if I had to pick 2, I'll pick MEP1 and MEP4 :)
[discussion about a beauty contest for MEPs]
Tom:      wants to reduce the list. 
Gudge:    argues it is not worth going there for the moment.
Amy:      we have costumers for some of the MEPs.
[GlenD:   +1 to Gudge's MEP1 + MEP4. Let's do it.]

Tom:      this group may not be able to satisfy all your custumers.
[sanjiva: Yeah and what about simple request/response stuff like 
Jonathan: union rather than intersection for our MEPs?
[Tom keeps arguing about satisfying his customers over others' :) ]
Tom:      I'd like to reduce the scope of the spec.  I'd like to 
          be done with it;.
Gudge:    having 7 MEPs make the spec more useful for more people.
[Jonathan plays his straw poll/vote card]
[sanjiva: are all 7 meps required to be supported? ]
[sanjiva: That is, is a compliant proceessor required to handle all of them]
sanjiva:  compliance for the 7 meps?
Jonathan: not all bindings need to support the meps.
jeff:     do we have a mep normatively but not a normative binding 
          that supports them?
Amy:      the soap processor does not require you to do http which 
          is the only binding provided there.
[TomJ:    To make my position on the 7 MEPs clear, I think that we 
          have too many, inparticular MEP 3, 6 and 7. These MEPs 
          don't have common use cases and we should really set the 
          bar high on this and take them out of the normative spec.]
[sanjiva: +1 for reducing the # of MEPs]
[TomJ:    I understand that others *have* use cases, but I haven't 
          heard enough demand from multiple companies to make me 
          believe there will be critical mass for them.]
Amy:      if you support the soap binding, the soap req-resp and 
          the webmethod get. there are 2 meps required, if you 
          support the binding, you have to support those 2 meps 
          and not others.
Glen:     the soap resp MEP is not MEP 2. the binding is different.
Amy:      from WSDL point of view, I should be able to describe 
          messages others than XML messages.
Sanjiava: are we going to document 7 MEPs, with use cases, etc. 
          What are our criteria?
Jonathan: that's a political process. we'll have champion for each 
          MEP. if no champion, they will be less likely to go in 
          the spec.
Jonathan: suggestion on how to move forward?
[community feedback, champion, use cases, ...]
MChapman: there is a document (usage scenarios) in the WSA with 36 
jonathan: we're trying to have balance with atomic ones and add a 
          few really common ones.
Gudge:    I still like original formulation of fault from Amy: any 
          message can be a fault.
[MChapman: correction: the usage scenario doc i referenced is a wsd 
           doc, wsa has its own! http://www.w3.org/TR/ws-desc-usecases/]
[alewis:  My formulation was actually that any message can *trigger* 
          a fault. And that if there's no available return path, then 
          it is discarded.]
Amy:      do we want a set of requirements for MEP?
Philippe: we can throw some out at the CR phase
Jonathan: we can ask people to show examples of usage of those MEPs.
Amy:      following QA recommendations, we might add performance 
          requirements, two working and interoperable example the use 
          a MEP in order to have it in the draft.
Jonathan: reasonnable requirement to set for the CR phase.
Martin:   we can all parse the documents that use those MEPs.
[sanjiva: are we going to define MEPs that we won't use at all??? I 
          don't think we should do that.]
Joanthan: some of these MEPs won't be usuable with our bindings. 
          people we need to come up with some during the CR phase.
Martin:   this is the wsdl group, not the soap interoperable group.
Amy:      at some point, we need to find if each MEP is useful or not.
JeffM:    easier to mvoe to CR with less MEPs...
Jonathan: if no one implements a MEP with a binding, we pull it out at 
          the end of the CR phase.  2 interoperable implementations 
          would be required.
Sanjiva:  is the tcp binding going to be documented? I thought we will 
          provide one binding for each MEP...
Jonathan: I thought the group agreed the reverse actually. To make it 
          clear, if Amy wants to keep MEP 7, she'll need to convince 
          someone else to implement it as well with the same binding.
Amy:      such effort are going on as we speak.
Sanjiva:  are you going to recommending the binding after the CR phase?
Gudge:    no, we'll just keep the MEP in the spec.
Amy:      "2 independent implementations".
Philippe: how do we record that?
Jonathan: as an issue in the MEP spec seems reasonnable.
Sanjiva:  we cannot prove that we have 2 implemetnations, unless we 
          have the bindings.
Jonathan: that's correct.
JeffS:    interoperability of WSDL is not the same as interoperable 
          of SOAP. how did we get there? how do you think this 
          criteria will be met?
Amy:      "we have supplied you with MEPs, go thou and bind them"
Jonathan: the failure mode is to move the MEP into the darkness of your 
          own namespace. :)
ACTION:   editors of the MEPs to record this CR requirement in the 
Jonathan: name issue resolved?
Gudge:    I like numbers.
[sanjiva: I like names .. :)]
Gudge:    lots of troubles we ran into were due to conotations with 

10:50 Break
11:20 7 MEP review (cont)

[MEP names continued)
[7 sins? 7 dwarves?]
[related to their description]
[arbitrary name or names of some sense?]
[MEP name is pushed on the stack]

DBooth:   [catching up] I'm concerned with the way we are defining 
the MEPs. When is the appropriate time to raise this issue?
Jonathan: ... CR ... evidence of utility of the MEPs ...
DBooth:   not concerned about the choice of MEPs but about the way 
          we are defining them. I believe it conflicts with WSA 
          understanding of MEP.  Looking at the glossary definition
          from Gudge's presentation, was concerned with his 
          definition of MEP. incomplete definition of MEPs, ignore 
          the parties that are involve.
Gudge:    that's up to the binding.  We agreed in Arizona that we 
          would describe them from the server point of view.
DBooth:   that's orthogonal. 
Jonathan: our definition of MEP is in the MEP lists. Are you 
          arguing against it?
DBooth:   yes, the parties are ommitted.
Gudge:    we established this morning to have a MEP and map to two 
          different bindings.
DBooth:   I'm concerned about that. Doesn't seem the understanding 
          of MEPs.
Gudge:    MEP in WSDL are not the same as SOAP MEPs and maybe 
          different in WSA as well. The MEP describe messages in 
          and out at the portType level.
JeffM:    for me, portType means the transport level
DBooth:   a WSDL is for use between parties, it's a shared thing. 
          at least two. the point is to get interoperability. Both 
          parties must agree.  WSDL as is defined today is written, 
          for convenience, is written from the point of the service. 
          That does not change the fact that the document is 
          intended to be used by both parties. We could have done 
          the opposite way: Web Client Definition Language. The 
          purpose would have been the same.
JeffM:    I disagree that we would be the same thing.
DBooth:   it would be the exact complement.
Gudge:    there is an assumption that flipping WSDL would be the 
          mirror. This assumption is not true.
Martin:   you can setup expectations from the client point of view 
DBooth:   the point of view is independent of the purpose of the 
Gudge:    how does the service use it?
Glen:     you build skeletons on the service with it. that's a 
DBooth:   then, if the contract has all information between the two 
          parties, it would be nice to have it shared by more.
Amy:      the client cannot see the agreegated service.
DBooth:   each interaction has a WSDL. different portTypes.
[JacekK:  this image might be helpful: http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/att-0069/01-meps.png]
DBooth:   different service address. WSD representts Agreement 
          (or contract between 2 parties)
Martin:   not a contract in terms of negotiation. it's defined from 
          the service.
DBooth:   take it or leave it contract. Definition of MEP 1 template 
          for the exchange of messages between nodes. it's a 
          message _exchange_ pattern.
          Levels of Abstraction / Reusability
          - No abstraction/reusability
          - Variable service address
          - Variable transport
[GlenD:   Node Emission and Reception Description (NERD)]
[Gudge:   Message Emmision and Reception Pattern - MERP ( rhymes 
          with burp )]
DBooth:   you can reuse the abstract even with different protocols.
Glen:     if Gudge's example valid, we lost that already.
DBooth:   possible level of abstraction here. each level gives you 
          more reusability.
JeffS:    we want to make standard here. I need you to be very specific 
          of the piece of abstraction that we lost.
DBooth:   the symbolic identity of the parties must not be abstracted.
JeffS:    doesn't exist in WSDL 1.1
DBooth:   my understanding of WSDL 1.1 is that the operations that 
          are described are between two parties.
JeffS:    you're arguing that was implicit in WSDL 1.1 then. you want 
          to make explicit?
DBooth:   we shouldn't push it in the binding.
Jacek:    in David's world, WSDL is a contract.  SOAP MEP can cover 
          any kind of complex MEP. What is a WSDL MEP? Is it the part 
          that concerns one node and involved two parties? You can an 
          MEP as me as a service and the world, or me, you, and the 
          interactions, or me, you and a set of nodes. We should decide 
          what way we go.
Glen:     there should no way to confuse at the abstract level me and 
          you (or other nodes). Web Services is about the wire and what 
          goes on the wire. need to think about the connections between 
JeffS:    I'm trying to describe the messages from a network with a service
Umit:     the problem with JeffS' level of abstraction, you loose the 
          initial intention. multicast is not the same intention than 
          simple req-resp.
JeffS:    a possible move is to accept both views.
Gudge:    given that binding can do the way like anyway, how do we go?
Glen:     it's going to be challenging for people to deal with that.
DBooth:   agree that 2 levels of abstraction is ok. People will want to 
          reuse the same pattern of interactions.
Gudge:    from the service, it is always the same pattern.
Glen:     the semantic of the service is different. don't multicast my 
          bank information.
Gudge:    how can you prevent that anyway? You stated that it is possible 
          to build unsecure binding, which is fine.
DBooth:   if you define things at the binding level, you may not be able 
          to reuse them
Igor:     can you 2 bindings concretizing one MEP?
[input/output, one binding for input, one binding for output.]
JeffS:    you have to define constraint in the same binding.  Our 
          construction today implies that you'll need one binding 
          construct to represent email input / soap output for example.
Martin:   so, in Gudge's example, who describe the multicast?
Gudge:    we have simple MEPs that can be bound to more sophisticated 
DBooth:   [trying to summarize] if you define an operation with MEP 2, 
          it is ambiguous if the output is supposed to go back to the 
          same party that sent it.
Gudge:    it always goes back to the party, it may go to others as well.
[MChapman: i'll try and explain my issue: if at the abstart level one 
          uses a mutlicast mep and in you binding over tcp (for example) 
          how does that work - who defines all the extra mecanism, or 
          should that mapping be invalid]
Gudge:    if it's going to take us too long, let's have MEP 1 (input 
          only) and MEP 4 (output only).
Glen:     actually, no one explained how to do input/output over one 
          way protocol
Martin:   then let's adopt CCPA. it only describes input, output 
[sanjiva: CCPA?]
[Gudge:   CCPA - Canadian Chemical Producers' Association, 
          Canadian Centre for Policy Alternatives, 
          Cumberland County, PA, 
          Canadian Concrete Pipe Association, 
          Connecticut Community Providers Association, 
          Centre for Creative and Performing Arts]
[MChapman: ebxml Collaboration Profiles and Protocol Agreements]
DBooth:   I don't think we should the ambiguity between the input goes 
          to the server and the output goes to somewhere we don't know.
Amy:      it doesn't seem that you're suggesting that we need multiple 
          roles. you want to ensure that the output goes to the sender 
          of the input message.
JeffS:    we can reuse properties and features to describe David's 
          concern. Soap identifies the parties except the current one.
tom:      I believe that David want the input/output involved the same 
          parties for the MEP 2.
Amy:      the agreement in Scottsdale was MEP 2, not request-response. 
          there may be a use for a request-response, but that's not 
          the agreement.
Tom:      I don't think that's true.
DBooth:   I'm okay with Amy's statement but let's distinguish it 
          clearly then.
Jonathan: I propose to add this issue in the spec.
DBooth:   can we take a straw poll on this issue?
Jonathan: do we want to be able to express a request-response at the 
          portType level?
JeffS:    I note that in the current spec, you can make any arbitrary 
          statement about an MEP. you rewrite MEP2 to include David's 
Glen:     does our concept of MEPs can be linked to a more general 
          concept of MEPs that includes roles?
[dbooth: q1: Should we have an MEP at the PortType level that is 
          request/response (i.e., the response is known to go back 
          to the requester)?]
[dbooth: q2: Should we have an MEP at the PortType level that is 
          input/output without implying that the output goes to the 
          same party as the input came from?]
[jeffsch: jeffsch notes that q2 is the current MEP2]
Tom:      I always had the view that MEP2 was in fact q1
[dbooth:  These two questions are not mutually exclusive. We can 
          certainly say yes to both.]
Martin:   I don't really care as long as you can annotate the MEPs 
          at the abstract level.
Sanjiva:  why is important to annotate the difference between those 2 
DBooth:   it might not be important. I think it is important to know 
          that interaction pattern and reuse it.
Glen:     WSIF have said it is important.
Mark:     with a request-response, you can assume the recipient of 
          the output based on the sender of the input.
[straw poll
  q1: 14 yes, 8 no
  q2: 15 yes, 5 no]
Gudge:    so we now have 14 MEPs...
[sanjiva: I vote for not distinguishing]
[sanjiva: (soon we'll be up to 140!)]

ACTION: Editors MEP to add an issue to address request-response MEP.

[JacekK: we have 8 MEPs, maybe 9 if MEP3 is also concerned]

[going back to MEP name]
[arbitrary name? meaningful name?]
Jonathan: do we want to change the current names (MEP1, MEP2, ...) to 
          something more meaningful?  Having arbitrary names 
          won't mislead people. do we want to change the current 
          names (MEP1, MEP2, ...) to something more meaningful?
[17 yes, 1 abstain]
arbitrary names?
[2 yes]
ACTION: Editors MEP to suggest meaningful names for our MEPs

[sanjiva: integrate to part1 draft]
[do we want to include the MEP spec into part 1 or part 2?
or separate?]
[Allen:   Part 1]
Glen:     soap describes the concept of MEP in part 1 and defined 
          some in part 2
[sanjiva: specific MEPs are not binding specific .. they are not 
          bindings either. They are abstract. So IMO either its 
          in part 1 or in part 1.5.]
[part 1? part 2? part 3?]
part 3: 12 for
part 1/part 2 in some fashion: 3 for
Resolution: let's keep as separate spec for the moment.

part 2 is for MEPs
part 3 is for bindings
ACTION: Editors to come up with a part for MEPs

Jonathan: any objection to roll in the changes of part 1 into 
          the main branch?
[jjm-rns: no]
[Gudge: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml?rev=]
[Gudge: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html?rev=]

12:50 Lunch
14:00 issue clarify type and element
    - Arthur's proposal [11]

 [11] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0055.html

Agenda item (clarify type and element)
Arthur:   problem is coupling between port type and binding. Caused by 
          incompleteness in the binding rules
[Arthur presents presentation: URL to follow......]
[dbooth: Arthur's slides are now available as PowerPoint at http://www.w3.org/2003/ws/desc/3/05/arthur/RemovingElementAttribute.ppt or as HTML at http://www.w3.org/2003/ws/desc/3/05/arthur/RemovingElementAttribute_clean.htm]

Tomj:     concern that introducing more options on the binding 
          that effect the wire 
Arthur:   currently there's a diff port type per binding
Tomj:     did we already look at type and element (getting rid 
          of one or both)?
Gudge:    in VA... Main motivation to create abstract messages ??
Arthur:   yes
Gudge:    Agrees to get rid on one.....
Arthur:   if we keep both the bindings need to be a lot more rigorous
Marsh:    Is one of the reasons we've delayed this is that we can't 
          decide which one to remove?
Umit:     Maybe we should really work on the bindings before we 
          remove either one.
[Now at Example SOAP Doc Binding slide]
Gudge:    It isn't possible to guarantee all messages in WSDL be 
          bindable to SOAP/Doc, SOAP/RPC or ...... Still don't get 
          the "wrap" use 
Glend:    pitches for keeping element and removing type
[sanjiva: Glen, if you keep only element, how do you define a 
          string part?]
[GlenD:   Sanjiva, Just as you need to wrap an element in a type 
          for the other direction, you can wrap a type in an 
          element this way.
            name="foo" type="xsd:string"
          I could either put <part> around that, or <element> 
          around it. Same fing.
[sanjiva: spse you have a function foo that takes two strings s1 
          and s2. You would need to define two elements right? 
          Beacuse the name is part of the definition]
[GlenD:   there are two elements, yep.
          name="s1" type="xsd:string"]
[sanjiva: Right so its not the same thing- the other way you 
          don't have that problem
          name="s2" type="xsd:string"]
[GlenD:   ?]
[sanjiva: I mean wrapping an element in a type approach (i.e., 
          the drop @element case)]
[GlenD:   what's the "problem" you refer to]
[sanjiva: That you have to define a new element for each use of 
          a simple type]
[GlenD:   oic
          well this gets into the next discussion... :)
          it's only redundant if you have both part and element.
          If "message" is just an element containing elements....
          they're only defined once.....]
[sanjiva: And what about a mime:image/jpeg "part"?]
[GlenD:   aye there's the rub, matey.
[sanjiva: yep]
[GlenD:   But that's the tricky part]
[jeffm:   Here is the url to the current "approval draft" for the 
          WS-I 1.0 Basic profile: 
[sanjiva: that's utter crap ;-)]
[GlenD:   we'll get there
          yeah yeah. :)]
[Now on HTTP Post Binding slide]
[Gudge and Arthur discuss HTTP Post/Get bindings ]
Arthur:   The net of the talk is to achieve abstractness at the 
          port type.... Is there agreement that a worthy goal that 
          port types are abstract??
[Group agrees (nobody decented)]
Arthur:   This implies that the binding specification need to be 
          fixed (ie.not broken)
Marsh:    The question is do we want to remove either type or 
Umit:     should look at removing message before addressing the 
          type/element decision...
Marsh:    Should we still keep the type vs element issue open??
group:    yes

15:15 Break
15:20 Renaming
    - Template [12]
    - Phillipe's proposal [13]
        portType -> interface;
        port -> endpoint; 
        binding -> interfaceBinding
    - Jacek's proposal [14]
        binding/@type -> binding/@interface
    - DavidO's proposal [15]
        port -> Service
        portType -> Interface
        service -> ServiceCollection

 [12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0120.html
 [13] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0103.html
 [14] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0108.html
 [15] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0112.html

Agenda item: Renaming 

TomJ:    Prefers smaller changes to the naming than DaveO's changes.
SJ:      Should save this for WSDLv2.0
GlenD:   doesn't see name changing any more than changing a namespace 
         as far as the language
Amy:     Name change is also desirable for naming conflicts between 
         WSDL and other environements (ex defn. of service)
Dbooth:  Friendly ammendment (change port to webservice) to dave's 
GlenD:   s/web service/endpoint
Marsh:   Let's take one at a time

Straw Poll: change portType to interface 
[results of straw poll (uc)]
port:    endpoint? endPoint? service? webservice?
[Allen:  I vote for endpoint]

Issue:   Re-open One interface per service issue
[Gudge:  I think we should choose some unicode code points outside 
         the ASCII range and use those. Then we could get down to 
         single character element names ;-)]
TomJ:    Call for straw poll: endpoint yes or no
Yes = 16
No = 0

Marsh:   Any objections to endpoint ? (none)

Amy:     should re-visit the service renaming until the (one 
         interface per service issue) is solved....
[sanjiva: -1 for changing to interfaceBinding]
Marsh:   Changing "binding" to "interfaceBinding" Yes or No?
Yes = O

[TomJ:   Proposal: binding/@type -> binding/@interface]
[sanjiva: +1 to Jack's proposal to make binding use @interface]
[Allen:  yes]
Marsh:   All in favor of changing type attribute of binding to 
         interface?? Yes or No
Yes = all

Marsh:   change mep attribute on operation to "pattern" Y/N
Yes = 13
No = 0

16:50 issue fault name uniqueness
    - Paco's proposal [10].

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

New fault elements and names proposed to replace the generic fault
[sanjiva: +1 TomJ's proposal]
[Marsh:   <inputFault name="...">
          = what Jon thought Tom wanted]
[Gudge:   That works]
[Marsh:   <inputFault name="..." message="..."/>*
          = what Tom actually wanted.]
[Gudge:   I don't think that works. Because we can't enforce the 
          uniqueness constraint]
[sanjiva: I don't understand - do you mean from XSD?]
[Gudge:   that the groups need to have different names ( and those 
          names need to be unique WRT input and output too )]
[sanjiva: We can express that in English; are you saying it cannot be 
          expressed in XSD?]
[GlenD:   good q]

Amy:      given the impending change in syntax for faults/fault 
          groups, fault name uniqueness may be a non-issue
Marsh:    fault name uniqueness now a non-issue

Marsh:    eliminating message agenda item deferred
Marsh:    Future F2F info updated on the web site, please check.
Marsh:    message (eliminate) issue will be moved back to telecon 

17:00 Adjourn

Topics for future meetings:

1) issue eliminate message
    - [Relevant materials from Roberto, Gudge, etc.]

2) If we have no other outstanding Part 1 issues, we will try to
      tackle some  properties/features dependent issues.

    - BindingType proposal from Kevin [.1].  Updated proposal at [.2].
    - Issue 28: transport='uri' [.3]
    - Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [.4].
               Jean-Jacques proposal at [.5]. Jacek's addendum at [.6].
 [.1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html
 [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0068.html
 [.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
 [.4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2
 [.5] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html
 [.6] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html

3) HTTP Binding Issues (6a, 41, etc.)
    Big question: how much do we want to work on this [.1].
    Jeffrey's summary and recommendations (no change) [.2].

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0025.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0102.html
Received on Wednesday, 5 March 2003 15:31:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:28 UTC