W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2004

Minutes: 30 Jan 2004 WS Description FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 4 Feb 2004 09:49:56 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2027A6BCD@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 30 Jan 2004
Bedford, hosted by Sonic.

irc: http://www.w3.org/2004/01/30-ws-desc-irc

 David Booth            W3C
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Tom Jordahl            Macromedia
 Philippe Le Hégaret    W3C
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Adi Sakala             IONA Technologies
 Jerry Thrasher         Lexmark
 William Vambenepe      Hewlett-Packard
 Umit Yalcinalp         Oracle

 Allen Brookes          Rogue Wave Software
 Amelia Lewis           TIBCO
 Jean-Jacques Moreau    Canon
 Sanjiva Weerawarana    IBM
 Prasad Yendluri        webMethods, Inc.

 Youenn Fablet          Canon
 Jacek Kopecky          Systinet
 Ingo Melzer            DaimlerChrysler
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates

scribe: William

Friday 30 January
09:00 Binding issues:
    - Issue 80: Inappropriate binding component name [30]
        a) Yes: come up with an alternative name.
        b) No: close issue
    - Issue 82: Relax binding syntax [31]
      Need proposal to understand the scope of this issue.
    - Issue 83: Interaction between binding extensions [32]
        a) In scope: come up with a proposal.
        b) Out of scope: close issue.

 [30] http://tinyurl.com/ysgl#x80
 [31] http://tinyurl.com/ysgl#x82
 [32] http://tinyurl.com/ysgl#x83


09:15 Issue 109: Versioning [33]
    - Required reading (DavidO) [34]
    - Use Cases (DavidO) [35]
    - Requirements (PaulD) [36]X

 [33] http://tinyurl.com/ysgl#x109
 [34] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0098.html
 [35] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0070.html
 [36] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0076.html

Paul:     2 tactics possible.  You use 2 different descriptions but 
          then you get stuck with 2 documents and 2 pieces of code
jeffm:    what kind of changes are you talking about?
paul:     eg "getCustomerDetails" can grow in a backwad compatible 
          way: we get and send more info. An existing client may 
          ignore it, or dynamically accept it (like display it) 
          without understanding it
glen:     that's an xml pb
paul:     Schema is trying to define the whole doc.  You have to know 
          from the fact where you'll want to add element, using usually 
          xsd:any.  This causes all kinds of pb. if you ignore things 
          that were not in the schema that leads you into pb.  
          Basically all I am asking for is the ability to add 
          something to a service and not break clients. And if schema 
          is not good enough, maybe we can do something in wsdl.
jon:      There is a schema/message question. but also changing the 
          description (like adding operations in the wsdl)
paul:     backward compatibility is ignoring info. Forward 
          compatibility is defaulting
jeffm:    You are talking about adding something that "doesn't beak 
          the semantic". what does "break the semantics" mean? it's 
          ap-specific.  When i assert that the service i deploy is 
          version B of version A, what am i saying? sometimes saying 
          that something is the new version of something else is 
          just a marketing statement
daveo:    Why not give a tool to the app developer so that whatever 
          they mean by "next version" they can express that
jon:      Let's start at the bottom. paul provided a specific example 
          of need. what can we do to help?
jeffm:    We have to be very precise about what we are defining
daveo:    Are you looking for a definition of compatibility?
jeffm:    Yes
roberto:  A wsdl is exposing a service with a particuar endpoint. 
          That doc is a contract between client and server. A newer 
          version of a contract would be such that if the client or 
          server is updated the same assertions (that were in the 
          old wsdl) are still valid.  These are the wsdl assertions. 
          Other asertions are part of the app but like jef i don't 
          think we should go there.
arthur:   One of the uses is to add more info but not add the client. 
          There is a technique in ADO.Net where the first part of 
          the message is the schema and the second is "any" so the 
          schema is determined at runtime.  So you can design a 
          client that takes runtime type info in you want.
paul:     Sounds a bit like xsi:type.
[umit:    This method implies that there is no document contract 
          between the client and the service. ]
arthur:   Or you can use name/value pairs in the message. Like 
paul:     This is crucial to us users of web services. if we can't 
          change our web services it's going to be a reason for not 
          using it
arthur:   COM took the attitude that itnerfaces were immutable. if 
          you want to add something you add a newer interface. so 
          existing clients didn't break
[DaveO: http://www.w3.org/2001/tag/doc/versioning-20031003#terminology]
Arthur:   That enables 3rd party component markets.  Web services 
          could take this attitude and this would permit a more 
          orderly evolution, and not force everyone to update at the 
          same time.
roberto:  But interfaces were defined by the framework provider
arthur:   No, you can buy bags of widgets (like calendars) and the 
          interface is written by the component provider
roberto:  The majority was things like iDispatch that used late 
arthur:   w/ wsdl the implementation is completly opaque, you only 
          see the interface. so there is no such thing as minor/major 
tom:      +1 to arthur. when you are changing the interface it's a 
          new service. i don't see what we can do. is there a 
          proposal on the table? i think the only thing we can do 
          is to add something showing the "version" of the interface, 
          that's all
jeffm:    trying to understand what the requirements are.  You have 
          to define "A is a version of B if and only if...(what?)"
umit:     paul is after data evolution, not just adding a new 
          operation to an interface. schema hasn't correctly 
          addressed this pb. we need to separate the wsdl pb from 
          the schema pb
paul:     I am asking for 3 things: the data on the wire to be 
          versionable, to be able to change the interface (add 
          binding, operation) and finally to be able to communicate 
          about the changes (are they backward compatible, are they 
          major or minor changes...)
kevin:    How about changes in the WSDL file that don't impact the 
          interface? for example change in the copyright statement? 
          How do you do that? same targetnamespace but differnt text?
arthur:   There is some work in OASIS on this
jeffm:    Many of the things paul are asking for are not possible. 
          The only way to progress is to define constraints on what 
          you want to do here
jon:      We need a concrete list of pb we want/can solve so we can 
          go out and see if we can have proposals on these specific 
          things. make the discussion more concrete.  The 3 things 
          we might want to support are:
          1- change (evolve) xml on the wire
          2- adding to the interface
          3- communicating changes
daveo:    This stuff is in the web arch doc.  (how to use namespaces 
          for such things). If you use a mutable namespace name, 
          you might want to specify what changes are possible
williamv: The WSDM working group is working on providing support for 
          relationships between resources. that can include 
          interfaces. and relationships in the "change" category, 
          such as compatibility
arthur:   Another approach is to use interface inheritence

[Recapitulation we've listed 3 ways to address the 3rd requirement 
(communicating changes):
  WSDM relationships,
arthur:   When you are adding a new operation, the clean way is to 
          create a new interface that extends the old one
daveo:    the "namesapce" approach is really namespace plus version 
arthur:   Generating a new interface is not going to break the 
          client. otherwise you are going to break the client.
[arthur/roberto discussion on what in JAX-RPC would or would not 
break the client (in terms of changes to the interface)]
arthur:   If new interface is binary compatible with the old (because 
          you only added a new operation) then the old client would 
          still work. the trouble would be for the server side. From 
          the server point of view, if some organization is creating 
          an interface and later wants to add a feature, the client 
          needs to keep both implementation. a server built to the 
          old interface will no longer work
roberto:  Yes, the case of the server is different
arthur:   It's cleaner to use inheritence to add new operations
paul:     This is not just "BT's pb". it's something we have a lot of 
          experience on, but it's a platform pb
daveo:    You can work on the schema itself that controls the content 
          of message and then there's the schema language. and the 
          there's the interpretation of the schema results. e.g. you 
          can have a validation mode that doesn't stop when you see 
          =something you were not expecting.  And then there are 
          wsdl-specific things. all the constraints defined by wsdl.
          The part about changing wire stuff is getting more 
          understood. Maybe there is something the wsdl group could 
          do in terms of how it uses schema.
paul:     Wsdl 1.1 has support for array, taking schema and annotating 
          it. We can do a similar thing.
daveo:    a common model is to use xsd:any with another namespace. But 
          this forces you to predict where the extensibility is going 
          to go.
jon:      Is there a way to specify in wsdl how to validate the schema?
          additional rules?
daveo:    You can mark the new type and say how it is part of the old 
          type. Or you can do "validation by projection". Where you 
          only validate what you understand. Schema does not have a 
          way to constrain what a wildcard can be used for. All it 
          has is namespace constraints.
jon:      We might be able to get schema to add another attribute to 
umit:     Not sure you can do this by extending xsd:any
glen:     This is good discussion, but this portion of the discussion 
          is endemic to schema and xml at large and we might better 
          use our time talking about how we can deal with wsdl object 
          model changes
daveo:    wsdl uses schema. you can varry the way it uses it. You 
          can't ignore a new operation invocation, but you can ignore 
          a new element in the xml on the wire (response to a 
          suggestion from glen to focus on changes to the wsdl doc)
jon:      The psvi annotations everything. doesn't get a pass/fail 
          to the whole doc. we could look at the psvi and say "if 
          you failed validation, here are other steps you can take"
paul:     So validation is not pass/fail, it is something you have 
          to process to turn into a global pass/fail. Opens the door 
          for us to tell wsdl processors how they interpret results 
          from the schema processor
umit:     you usually don't have access to this info in the tools i use
daveo:    That's the kind of thing i am thinking about. In late binding 
          kind of system you're more able to deal with these changes 
          of wire format.
jeffm:    if you use statically generated code you can't adapt. unless 
          you build extensibility into the processor. One way is to 
          say "if you use the following guidelines and uses to design 
          your schema you can expect these extensions to be possible".
          We could provide such guidance
daveo:    What is the farthest you can go with default validation and 
          schema as it is today? this takes us somewhere but it is 
          not that great a place. this group, within the group, has 
          the ability to take us further. it could also exert 
          pressure on the schema group
arthur:   The crux of the matter seems to be that you want to add 
          something to the message (like frequent flyer number) and 
          not have the client do. what do you want the client to do 
          with it?
paul:     ignore it?
arthur:   ok, what else? if all you need is to add data so that 
          people can ignore it, what's the point?
paul:     Some client will ignore it. but the whole point is that 
          some might know how to make use of it. Schema has led to 
          a mindset about how to use web services. Another view is 
          to use query languages, where the code queries the XML for 
          the info it wants. additional information would not break 
          this kind of implementation
arthur:   In certain apps where the client doesn't really understand 
          the data (like it only displays it) you can design a very 
          lax message standard. In the cases where you really expect 
          someone to process the info, a more tight message format 
          is appropriate to allow the app developer to look at the 
          message format ahead of time
paul:     When you have a large community of clients, versioning is 
          critical otherwise you can never change anything
jeffm:    We need to write a description of a language and processing 
          system that has to work for everybody. what you have in 
          mind (talking to Paul) is a specific set of usage. assuming 
          this kind of usage is important enough that we need to 
          worry about it, we need to clearly define this set of 
          applications so we know what we're talking about. Also, 
          certain pbs where solved in Corba even if there was no 
          market uptake and we need to look at how these were solved 
          there. Also, there is a way today to do what Paul asks for.
          use getXML/setXMl operations if you don't want to use a 
          schema that tells you what the format will be. In order to 
          put "backward compatible" in a spec it needs to be defined.
daveo:    Schema and the way we use it (and wsdl) has guided people 
          to think about how they use web services in a certain that 
          has led to more brittle systems than needed. Language A is 
          compatible with language B if all the things valid in B are 
          valid in A
daveB:    And have the same meaning
daveo:    From a set theory perspective, you have a known set of 
          things and an allowable set of things. when you go to the 
          next version, things are moving from allowable to known and 
          known is getting smaller. these two sets are converging 
          through the successive versioning. Can't think as server 
          and client. need to think as server and receiver
jon:      we'll take a break and then we need to look at concrete 
          proposals to pursue. 20 minutes break.
10:50 Break:

11:15 Versioning (cont.)

jon:      Need to become specific.
arthur:   There's nothing about WS that forces brittle systems. you 
          can have very weakly type interface declaration. Having a 
          contract gives implementation freedom
daveo:    If you give the interface writer the ability to say how 
          to handle things you don't know (as part of the contract) 
          then you don't loose the benefits of providing interfaces.
          Schema 1.1 is not going to be a usable option for maybe 5 
          years. maybe there is something we can do in wsdl. in the 
          way we use schema, that would enable this operation
arthur:   awaiting proposal from daveO
roberto:  1 approach (heavy weight) uses subintefaces, version 
          identifiers, multiple parallel endpoints, etc takes a 
          large amount of work and discipline but it works. this is 
          doable and we don't need to say anything. people who know 
          how to do this don't need our help. The lightweight 
          approach for the ordinary guy with simple needs. we can 
          give advice for this. e.g. "you can add operations but 
          not remove them", "you can extend schema in a compatible 
          way"... etc. only to preserve on the wire compatibility. 
          this is tractable. For the larger pb as addressed in 
          dave's paper, there are lots of pbs that need more time 
          to be addressed.  Not opposed to having this in an 
          appendix rather than the spec itself.
daveO:    I think we should tell things to wsdl authors about what 
          they can do with schema. i want to make a proposal about 
          that. How "validation by projection fits into the wsdl 
          model. I'd like to make a more concrete proposal in terms 
          of what wsdl 2.0 can do to use an augmented form of 
          validtion. Short of that all we can do is give advice but 
          even then the WSDL authors are not in a very good place
roberto:  Where would the proposal go in terms of our deliverables?
daveO:    Allowing people to express how they want to use the 
          schemas they import or include
jon:      Would there be an affect of schema components?
daveO:    Maybe we'd make fuller use of what schema provides
jon:      You would put soemthing in the spec that says "the way 
          the schema describes a message doesn't describe all the 
          structure of the message, there might be other stuff"?
          Would it involved respecifying schema?
daveo:    Hope not. if it involves a huge amount of effort just 
          forget about it. Permission to proceed?
bijan:    How modular is this proposal or issue? does it require for 
          technical reasons text in the core spec or could it be 
jon:      sounds core to me
daveO:    right now we are not really using all the data that's 
          provided to us by schema validation
jeffm:    seems like there's going to be 2 issues to deal with: 
          the technical soundness of this approach and the level 
          of work it is going to impose and how that fits into 
daveO:    Why don't i write up a bit more and we can take a look at 
          it after it hits the mailing list
umit:     what you are talking about is a new extensibility model for 
jon:      Does this pb manifest itself in relaxNG
daveO:    relax has an open contact model
DaveB:    pb goes away if you use RDF
daveO:    we could punt on it, listing things you can't do because 
          of schema and point people to other schema languages than 
          XML schema that do not have this limitation. A differnt 
          interpretation of schema validation result allows us to 
          do the kind of things people are trying to do.
jon:      Another approach is to say "these are our requirements 
          for schema 1.1"
daveO:    This is a separate track. Schema group is interested, but 
          that's years down the road. In other groups with possible 
          dependencies the model has been to do the work in house, 
          not wait for external dependency
jon:      Is the best solution for schema to provide us with an 
          open content model?
daveO:    We need to explore this. too early to say there is one 
          path forward.
phillipe: Now would be the right time to give reuirements to the 
          schema group as they are going to have a new charter 
          written soon.
jon:      DavidO will write a statemetn describing what we'd like 
          from schema. Some aspects are more important than others. 
          being limited on location of extensions is not a big 
          deal. being limited on how many times you can extend is 
          a much larger pb
daveO:    We want to be able to do multiple revisions. that would 
          require changes to schema 1.1 which has a certain time 
          frame. a certain interpretation of schema gives you that 
          feature in a shorter timeframe and under our control.
jon:      not sure that's possible, we need to see that in more 
daveO:    multi-direction approach: talk to schema folks, give 
          advice to people and things we can do in terms of our 
jon:      how do people feel about the proposal to interpret schema 
          differently? if we are not interested we should let daveO 
          know before he does all the work
arthur:   what are the implication of us reinterpreting schema? 
          wouldn't the complete rewrite of al XML tools sink wsdl 2.0?
daveO:    Premature to answer this question
arthur:   Part of being a good solution is wokring with existing 
          technology, so i will be looking for this is daveO's 
jeffm:    We'd have a hard time accepting this if it means we can't 
          use off the shelf schema processors
daveO:    I'd be interested if you asked customers what they would 
          trade off. if it required a change to takes X amount of 
          time, wold they accept the trade-off
jon:      The question is, if we can't do this without affecting 
          schema should we do it anyway or give it to the schema group?
          People want to move a schema between WSDL processors and 
          other processors. We're not hearing people it's a bad 
          thing to explore this proposal, but there is resistance 
          to do something that can't be layered on top of an 
          existing schema processor. We also want to write up a 
          request to the schema group to see whether they can 
          address this functionality. maybe talk with them at 
          the plenary

ACTION: DaveO to write up a proposal for augmenting schema 
        information to enable versioned data.

[umit:    the problem is having different schema processors. A 
          document which is valid differently when validated 
          using WSDL and some other tool will confuse customers.]
jon:      Finally, the last part is a set of remarks and 
          recommendations for our users
roberto:  Where would this go? appendix?

ACTION: DavidO to write request to schema group

jon:      Adding binding and additional optional extensions (or 
          schema) should not make them incompatible
glen:     The pb is that you can no longer think about things 
          based on the metadata you understand. Add guidance as 
          best practice to use extension to add an operation to 
          an interface.
arthur:   What about addition of an outbound operation? won't 
          this break the client?
roberto:  in this case, this is not a client on the wire.
daveO:    Need to talk in terms of senders and receivers
glen:     Maybe we should introduce a well-known "the xml you sent 
          me did not match what i think i am supposed to expect to 
          receive" as a fault, a subcode of sender fault.
WilliamV: From a mgmt perspective you want to be able to create 
          relationships between different things, you don't want 
          them to appear as the same thing otherwise you can't 
          express "A is compatible with B"
jon:      Big question is do we want to say things about how you 
          do versioning
daveO:    We might need a way to express a WSDL version attribute 
          to distinguish different versions of a wsdl
tom:      Sometimes you need to tell customers "schema makes it 
          hard to version data, so as a result in wsdl you create 
          a new itnerface to version"
[KevinL:  +1 to paul about versioning is critical for services with 
          LARGE user base]
glen:     "if you want to add an operation, you need to define a 
          new interface, unless you are doing this at dvpt time at 
          which case anything goes" (proposed best practice)
jon:      Evolving towards a section in the primer. Can someone 
          write it up for david to include in the primer?  Last 
          question, do we want to add "version" metadata to the WSDL?
tom:      Makes proposal to add a version attribute to the interface 
          component with a "major" and "minor" component, where major 
          means incompatible change and minor means compatible change
daveO:    I'll lie in the road before we use minor and major versions. 
          URIs are there for that. I agree with minor version 
          identifier but major version is a change in URI
bijan:    Why are 2 URIS where version and namespace are tied are 
          better to 3 URIs, which links to Tom's proposal. Is the pb 
          with Tom's proposal that he didn't use URIs for versions 
          or that he separated version from namespace?
jon:      Need someone to wrie a counter proposal to Tom?
daveO:    if adding a version attribute would help and we need 
          someone to write it i can do this
tom:      I can write up some syntax on the proposal to add a 
          "version" attribute. If people feel strongly that we need 
          URI rather than integer then we can discuss it
umit:     We should not limit this to the interface
kevin:    Move it to the "description" element
roberto:  What if i computed a hash instead of looking for the version 
tom:      Willing to change the proposal to move this to the definition 
umit:     Schema defines a version attribute
roberto:  We need to see some writing so we know what this attribute 
          is to be used for exactly

ACTION: Tom to write proposal on version attribute

12:30 Lunch
13:30 Issue 96: Support for SOAP intermediaries [37]
      Need an analysis on whether there are issues here.

																															 [37] http://tinyurl.com/ysgl#x96


13:30 Inheritance issues:
    - Issue 76: Pointing at derived interfaces [22]
        a) Yes: need volunteer to write up a proposal.
        b) No: close issue
 [22] http://tinyurl.com/ysgl#x76

Is it ok for an endpoint to point to an interface derived from what 
is expected? 2 cases in which this happen is when endpoint in a 
service element and endpoint reference also gives you expected 

Glen & Jonathan: looks ok...
Glen:     In both cases, you can send the messages, so I think it's 
Arthur:   The question: can you allowed the endpoint to point to a 
          more derived interface than the one referenced from the 
          binding? (or the other way around)
Glen:     You can have a binding without an interface, with 
          operations inside. (reusable binding)
[TomJ:    I think the status quo in the spec 
          (endpoint->binding->interface must match service->interface)
          is the right thing.]
Arthur:   I think that the interfaces can be subtitute
Roberto:  Don't think we should do it. they are around. no need to 
          complicate the spec.
Glen:     what about the case of dynamic reference? If I don't have 
          a binding for the derived interface but just have one for 
          a derived one....
Tom:      I'll have to do a lot more work now. traversing the 
          hierarchy interface, ...
Arthur:   I think the case as a meaning and would be a simplification 
          for authors (you don't have to create one binding per 
          interface in the hierarchy)
Umit:     We never discussed the idea of having @wsdlLocation. I can 
          write a proposal along those lines

ACTION: Umit to write a proposal on @wsdlLocation

Arthur:   We had a proposal and it got shot down. wsdlLocation would 
          be a global attribute, just like schemaLocation
          on the service references. You would use it anywhere.
(clarification on the use of xsi:schemaLocation)
(wsdl:descriptionLocation? )
Proposal to close the issue 76 without action
Jonathan: no compeling scenario to allow this

RESOLUTION: issue 76 closed.

13:45 Issue 81: Account for interface inheritance [23]
        a) Yes: come up with an alternative.
        b) No: close issue      

 [23] http://tinyurl.com/ysgl#x81

same as 76?
[Marsh: Resolution: issue 76 closed as dup of 81]
[Marsh: Resolution 81 closed without action, no compelling 
        scenario and workaround exists.]

14:00 Issue 95: service/@name required? [20]
        a) No: remove service/@name
        b) Yes: close issue.

 [20] http://tinyurl.com/ysgl#x95

Glen:     We want people to use when they believe they will refer 
          it outside the context of the wsdl. It makes sense to have 
          anonymous service. service is top-level. it does not 
          necessarely need a name.
Roberto:  Didn't we say that every component must have name?
Umit:     If we don't require a name, we will have troubles with 
          equivalence of components. you only compare components with 
Roberto:  No, you would fallback to the default definition of 
          equivalence. all properties must be equivalent.
Tom:      In a wsdl documentn, a service element must have a name, but 
          it's the schema, it must be marked as optional.
Joanthan: If it's NOT a child of definitions, it's optional. otherwise 
          it's required. but we cna't express that in the schema.
Glen:     what about a base type of service serviceBase, then an 
          extended one with a required name?
Umit:     For a service reference, the proposal is to use a service 
          type, not a service element. (minutes were incorrect. there 
          is a typo in it)
Arthur:   You can make the attribute optional in the base type. and 
          then required in the element declaration.
Tom:      A service reference can then contain a random string in 
          the required name...
Umit:     it's not an issue
Bijan:    So, make it optional or use a schema trick? (as Arthur's 
Glen:     We don't prescribe THE way to make service references. other 
          solutions are not precluded.
Umit:     You're forcing people to derive from the base type.
Tom:      We had a compromise to have it optional in the xml schema 
          and make it required in the wsdl spec
Umit:     I don't want to revisit the ServiceType
Adi:      I don't see why we should different ways between the wsdl 
          schema and the wsdl spec
Bijan:    If the constraint can't be expressed in schema, I would 
          favor the approach of having it optional in schema and 
          required in the spec. oterhwise, let's make it required.
Umit:     You have 2 choices and 2 differents types top derive from.
          One with a name, one without.
Jonathan: How can you derived from the anonymous type? Can we do 
          editorial changes without modifying the previous decision?

RESOLUTION: @name optional for the standalone service type use. it 
            will be required inside the context of a wsdl document.
            we may be able to describe in the schema as well as in 
            the spec but we should check for side effect.
Umit:       There is a derivation issue we should look into
ACTION: Jonathan to correct type in last f2f meeting on _S_erviceType
RESOLUTION: issue 95 is closed

14:30 Media type TF report (preliminary) [41]


Umit:     No interest into the media types TF and shame on us :)
          There is a document that needs to be reviewed!
Jonathan: The proposal should be taken to the group and gets 
          reviewed there. Or we can delay a bit until we look into 
(a bit of history on media types in WSDL)
ACTION: Umit to forward a link/proposal on media types to the WG list

16:30 Issue 104: Appendix E cleanup [43]
 [43] http://tinyurl.com/ysgl#x104

Bijan:    clarifies that his issue 104 is about message and 
          messageReference. it's a consequence of appendix E, but 
          not about the appendix itself.  You can 
          input/@messageReference as well as @input/@message.
          The qname that points to a message type has to be an 
          element. If you're using a non-XML type system, you're 
          screwed. The spec says that a message has to be an 
          element declaration.
Roberto:  No, a schema element declaration, or something else.
Bijan:    So any alternative type system has to use an extension?
Jonathan: Yes. You need to define an other element that would 
          describe schema specific way to point to the schema 

(Roberto quotes 2.4.3)
  [[ The element declaration resolved to by the value of the 
     message attribute information item if present, otherwise 
     a similar construct in some type system as referred to by 
     some other attribute information item if present, 
     otherwise empty. ]]
Tom:      Message points to a GED
[@message vs @element ?]
Tom:      Let's say we picked one to follow WSDL 1.1
[TomJ:    Changing the name of the input/output message attribute to 
          element is consistant with WSDL 1.1. In WSDL 1.1 there was 
          a problem with type vs. Element in <parts>. If we pick 
          element, we can say to users, we picked one - element.]

RESOLUTION: General acclaim to rename @message to @element
ACTION: Jonathan to add s/@message/@element/ on a teleconference agenda

Bijan:    What about messageReference then?
          @messagePosition, @mepPosition, @position?
          messageReference doesn't reference a message. so it's 
          not a message reference. it refers to a position in the MEP.
Amy:      It points at the name of the message, not to a position.
Tom:      In the request-response MEP, you can call the messages "in" 
          and "out"
Glen:     or "request" and "responses"
Roberto:  how about @label?
Glen:     @messageLabel?
David:    @mepLabel?
Glen:     <input element="?" label="?" />

RESOLUTION: General acclaim to rename @messageReference to @label
ACTION: Jonathan to add s/@messageReference/@label/ on a teleconference agenda

15:00 Break

15:30 Binding issues:
    - Issue 80: Inappropriate binding component name [30]
        a) Yes: come up with an alternative name.
        b) No: close issue

 [30] http://tinyurl.com/ysgl#x80

David:    A bind does no longer bind, so the name is inappropriate.
Bijan:    Grounding?
Tom:      Binding is well established.
David:    But misleading
Tom:      Only to people who really thinks about it :)
David:    The binding tells the encoding (message format), and the 
          protocol. How about serialization?
Jonathan: The binding binds the abstract to the protocol level
Adi:      You still do the binding in any case
David:    But the binding can happen at the service level. The piece 
          of information which is adding is the protocol
Glen:     You can bind the same interface to 5 differents SOAP 
          bindings. So it's not a protocol.
[alewis:  I think "binding" is a term of art in WSDL, and changing it 
          is not going to help.]
[KevinL:  +1. I don't see the benefit worthes side effects on, for 
          example, backward compatibility with wsdl1.1]
Glen:     The association is made with a place holder. the real 
          interface might be given at the service level, but you 
          still have a place holder.

RESOLUTION: let's keep "binding", close issue 80 with no action

15:45 Issue 82: Relax binding syntax [31]
      Need proposal to understand the scope of this issue.

 [31] http://tinyurl.com/ysgl#x82

"When all is said and done, the semantics for a combination of binding
info pieces must be consistent and reasonable. We should consider not 
using so many syntactic constraints to make that happen."
Glen:     Claims that he didn't write this :). Maybe related to 
          defaults in the binding?

RESOLUTION: given the changes to the syntax, we close issue 82 with no

15:50 Issue 83: Interaction between binding extensions [32]
        a) In scope: come up with a proposal.
        b) Out of scope: close issue.

 [32] http://tinyurl.com/ysgl#x83

"What is the interaction between binding extensions? Is it out of 
scope of Part 1, which appears to be the status quo? We should be 
explicit, especially if we define any sort of composition 
mechanism across bindings."
Glen:     Still claims he didn't write this :) Extensions must make 
          sense when they're composed.
Joanthan: we don't have inheritance. so no composition

RESOLUTION: Issue 83 is closed with no action.

(Jonathan reviewing the issues list for open ones)

Issue 92?

Issue 113 is mistitled
ACTION: Issues list editor to retitle Issue 113.

Issue 91:

(title is misleading)
Part 2 is now talking about Message Exchange patterns, instead of 
Message Patterns

DavidB:   our MP are now aligned with WSA, so let's change the 

RESOLUTION: Issue 91 is closed, editors will use the term "Message
            Exchange Pattern" rather than "Message Pattern".

Philippe raises an old issue which he doesn't see on the issues list:
"Flagging an operation as 'safe'"

Philippe: two parts:
          - indicating that the operation is safe as defined by HTTP 
            so the operation is considered as-is independently of 
            the underlying protocol.
          - changing the default POST binding of SOAP 1.2 to a GET if 
Tom:      I don't remember liking this idea...
Bijan:    If you didn't mark an operation safe and it uses GET, what 
Philippe: [...]
Tom:      complexity, harder, etc....
(some clarification on SOAP 1.2 binding and the webMethod property)
Glen:     You can use the webMethod GET at the interface level to 
          express that.
David:    But you can have other safe operations that are not GET.
Tom:      When you say something is safe in WSDL, it doesn't mean 
Philippe: If the operation is safe, you can do more assertions about 
          the reliability (repeat the messages, ...)
Glen:     You can use a property for that?
Bijan:    It will make a large class of web people happier. it's 
          possible it will improve efficiency, ... on the side, if 
          we make into an extension, and it is popular, it will be 
          used. My preference is to make an extension.
Bijan:    Make your extension a note and see if it's use.
Jonathan: Is there anything else we want to put into that note?
Philippe: Not as far as I know

ACTION:  Philippe to draft a note for the group around safe operations

New (old) issue: "renaming the label of MEPs"

in/in-out: A can be request, B can be response.

Amy:      we have several in-out MEP: in-out, robust-in-out, and 
          maybe in-optional-out
in HTTP, if no out, you get a 200 code.
Amy:      Suggest to change A and B to IN and OUT and we open an issue 
          asking if we should be more colloquial for the labels
RESOLUTION: Change MEP labels from A and B to IN and OUT

17:00 Adjourn
Received on Wednesday, 4 February 2004 12:51:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:46 UTC