Minutes: 21 Jan 2003 WS Description FTF

-------------------------------------------------------
Tuesday 21 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:
 Amelia Lewis           TIBCO

[Jeffsch scribes]

-------------------------------------------------------
09:00 PortType operation name conflicts [5; part b].

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

Steve:    Grid expecting >> port types with >> operations.  Expect 
          these to be mixed together through port type composition.
          Believe that current design for operation naming constrains 
          this.  For example, Port Type 1 and 2 both define an 
          operation with the same name with a single message that has 
          a different XML Schema type.  Per the spec today, it would 
          be illegal for a third port type to inherit from both of 
          these.  The implication is that GRID would have to coordinate 
          operation names across all of their operations.
Gudge:    Per spec today, if you have two operations with the same name 
          property, then they must have all the same other properties.
          There is a potential (if unlikely) danger that there would be 
          two identical operations that had different semantics. Keep 
          in mind that the operations actually refer to typed messages.
Jonathan: Is this an overloading problem, or is there something more to 
          this?
Tom:      Note that operation overloading won't solve the problem of an 
          implementation having only one piece of code to process a 
          given message.  We previously decided not to do operation 
          overloading for this and related problems (though "modern" 
          languages do have overloading).
Roberto:  Not all "modern" languages have the same model for 
          overloading.  Java allows interface inheritance; if the 
          signatures of two methods are different, then the method is 
          overloaded.
Gudge:    Could make operations QNames, which is simple in the component 
          model, but there were some concerns re: syntax at the last 
          face-to-face.  At the component model, to allow overloading 
          operations, we would have collapse (as today) if all the 
          properties of the operation (name, messages, MEP) but not if 
          any were different.
Roberto:  Couldn't we leave the syntax as it is today, i.e., leave the 
          operations nested within the port type even if we decided to 
          give them top-level names? To avoid the GRID problem, they 
          would use different target namespaces.
Gudge:    The uniqueness constraints would be the same as for other 
          global names.
Arthur:   Today we allow different port types to have operations with 
          the same name, and this is useful in expressing multiple 
          classes as multiple port types in the same namespace.
Gudge:    Could never collapse operations when inheriting by defining 
          the name of each operation to be a concatenation of the port 
          type name and the operation name. In this option, think of 
          the port type name as a sub namespace, where the full name 
          of the operation would be the target namespace plus the port 
          type name plus the operation name. You could still collapse 
          at the implementation level but not at the operation level.
Arthur:   In the diamond inheritance case, where a single port type is 
          inherited > 1 time, then operations it defines would still 
          occur.
Steve:    Would this violate any encapsulation requirements?
Arthur:   Think of all the operation names as public.
Gudge:    Though the port types leak into the operation names...
Jonathan: Does this work in the face of the open content model?
Steve:    Yes. The names of the operations are different by 
          construction, and that was the point of conflict.
Tom:      How does this affect the wire representation of these 
          operations?
Gudge:    You would have to provide > 1 namespaces. We could turn the 
          port type into a URI and use that for the namespace.
Jonathan: (The TAG is considering how to do this.)
Tom:      Concern re: complex processing rules and implications for 
          how bindings and wire formats look.
Gudge:    Steve's use case requires a way to make the operation name 
          unique.  We could provide a means in the derived port type 
          to reference / rename either or both of the conflicting 
          operations? Remember that the operation name doesn't 
          necessarily appear on the wire.
Martin:   How would we distinguish between two messages which have 
          the same wire format?
Gudge:    If they look the same on the wire, then they _are_ the 
          same message, and they collapse.
Tom:      If we fix this in the WSDL component model, won't the 
          implementation of the derived port type have difficulty 
          distinguishing between the two intended operations?
Jeff:     They do have a workaround. They can come up with a naming 
          convention for operations, for example, port type name, 
          underscore, and operation name concatenated together.
Gudge:    (reiterating) The key issue is to make the operation names 
          unique.
(Scribe notes digression into RPC versus document literal...)
Steve:    Is there a requirement on the component model that 
          operation names be unique?
Gudge:    Currently, they must be unique within a port type, and 
          2.5.1 says that operation names given inheritance must also 
          be.
David:    This looks important enough to be addressed.
Jonathan: Show of hands for how many people feel we can live with 
          what we have today? (1 raised)
Gudge:    Summarizing options.
            1 Introduce operator overloading
            2 Make operation names QNames
            3 Operation names are scoped by target namespace and port 
              type names.
            4 Rename operations within derived port type
          We don't have much understanding of some of these options 
          (e.g., 3 and 4).
Steve:    Are there ongoing concerns re: syntax of 2?
Tom:      QName for operation would simplify RPC style because it is 
          the complete value to put on the wire (don't have to grub 
          about to find the namespace).
Gudge:    Arthur pointed out a use case where this would be awkward.
          Consider backward compatibility case where a Web Service is 
          running and described in WSDL 1.1. When converting to WSDL 
          1.2, the conversion would fail, yes?
Roberto:  Why not put uniqueness constraint on the port type, allowing 
          two operations to have the same QName as long as they are 
          not used within the same (potentially) derived port type?
Steve:    How would the developer of the derived type resolve the 
          latent conflict in naming of operations in inherited port 
          types?
Gudge:    This should address Arthur's concern because it would be OK 
          to have two operations with the same QName as long as they 
          are used within the same port type.
Tom:      Can we eliminate the namespace attribute given that 
          operations have QNames. The wrapper name would be the QName 
          of the operation.
Jonathan: Let's review the proposal in detail:
            2a Add namespace property to the component model of the 
               operation
            2b Modify uniqueness constraint to say that combination 
               of name and namespace must be unique within a port 
               type. Equivalence of two operations would be defined 
               based on structure (even though they have QNames) 
               because duplicates are allowed.
            2c Investigate removing namespace attribute from the SOAP 
               binding
            2d Add a best practice note to explain why giving two 
               operations (in different port types) the same name and 
               namespace is not best practice.
Gudge:    Note it might be misleading to use the term "QName" to refer 
          to operations that have a name and namespace properties 
          because they cannot be referenced (they are not globally 
          unique). May refer to these as name and namespace pair in 
          the spec.  2a += Add a namespace property to the binding 
          operation.
Steve:    How would bindings work?
Gudge:    In the current spec, one writes a binding against the 
          transitive closure of the operations inherited.

ACTION: Gudge write up proposal for operation naming by next week.

-------------------------------------------------------
10:00 Removing message.  Roberto's original proposal at [7].
      Direction suggested by Dale [8]. Roberto will provide an outline
      for the discussion [8a].  Sanjiva's proposal [8b].

  [7] http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/0035.html
  [8] http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0040.html
 [8a] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0066.html
 [8b] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/att-0042/01-remove-message-jan-18-2003.html

Roberto summarizes his post (URL [8a] above).

-------------------------------------------------------
10:30 Break
-------------------------------------------------------

Removing message, cont.

Jeffsch:  +1 to the issues Roberto is address
Dale:     +1 to Sanjiva proposal
Gudge:    Concern re: introducing cardinality within operation
Prasad:   Value of cardinality for use case like number of items in 
          a purchase order.
Arthur:   We are re-inventing because we want to treat MIME types as 
          first-class.
Roberto:  We could consider MIME as a type system with its own 
          definition of repetition of parts. Instead you're 
          proposing a third type system, of our own invention.
Umit:     Value in neutral type system, that wraps others, providing 
          a consistent "interface" across others for the rest of WSDL 
          to reference.
Roberto:  Concern about defining a third type system.
Arthur:   Can we cover the 80% of the cases.
Umit:     Sanjiva proposal allows retaining partial evaluation (?) 
          and enumerating parts to allow repetition. Eliminates message 
          construct while retaining parts.
Dale:     See value in separating the message from port type interface.
          MEP could talk about pattern of exchanging, and subsequent 
          binding could map into different packaging schemes.
Roberto:  The multiple inputs are essentially defining a type. Why don't 
          they appear in the types section? There are issues in creating 
          a new language. Why?
Arthur:   Parts are a useful concept, and it is convenient at binding 
          time. If you don't have parts, you need something like XPath 
          to pull out what goes where in a specific binding.
Roberto:  That argument plays the other way too. (Missed the clever 
          argument.)
Gudge:    Syntactically, one would refer to message/part in the same 
          way that you'd refer to children within a type (like Schema).
Dale:     Do you want complex types rolling up things like image/jpeg?
Gudge:    I strongly believe we need to get to a strong Infoset view 
          or we're going to be in serious trouble in the long term. 
          Specifically, I agree that there needs to be something in 
          the Envelope that indicates the MIME type of the content.
Jonathan: Concerned about attachments as a requirement at this point 
          because the W3C XMLP (SOAP) WG is still collecting 
          requirements for attachments.
Arthur:   Are you saying that all procedures should have one argument 
          that is a structure?
Gudge:    No.
            void Foo ( int i, int j )
            struct { int i, int j )
            void Foo ( struct A )
          These look the same on the wire (and incidentally, on the 
          stack frame).
Arthur:   (Picks nit about whether it's the same on the stack frame.)
          One could argue that we don't need multiple arguments 
          because one argument would be sufficient? (Implicitly doesn't 
          agree.)
[<Arthur> Rebutting a false assertion is not nit picking.
 * jeffsch apologizes -- the single stack thing seemed off topic. Bracing 
          myself for the trout slap...
 * TomJ slaps jeffsch around a bit with a large trout.
 <Arthur> yes, maybe Gudge can explaing the relevance of the stack 
          discussion.
 <Gudge> my real point was about the wire.  The stack observation was a 
         side point.  In C/C++ the stack is the same.  In C# it's also 
         the same. Java doesn't have structs ( AFAIR ).
 <Arthur> Java has only pass by reference, C/C++ has both pass by value 
         and pass by ref.  So even in C/C++ you can pass a struct by ref.
 <Gudge> I understand that, as I said, the stack thing was a side issue. 
         My main point was that just because you describe the wire in 
         terms of a structured type doesn't mean you have to have a 
         method that takes that structured type as its single parameter.
 <kevinL> Agree with gudge.
 <umit> If the structured type on the wire needs to be mapped to a method 
        differently, you would still need unambigous mapping which has to 
        work both ways, extracting from the message and composing from the 
        method call. 
 <Arthur> I also agree with Gudge. My point is that multiple args to a 
        method is useful, and so are multiple parts in an operation.
 <umit> See the note we sent last night. 
        http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0067.html
]
Gudge:    Drawing an analogy to multiple operations per port type, 
          we _could_ have just one operation per port type, but the MEP 
          would become unweildy.
Umit:     If you have a single part, you can already use XML Schema as 
          desired. (Implictly suggesting value for multiple parts.)
(Discussion about programming language model versus describing messages 
on the wire.)
Roberto:  Doesn't agree that because programming languages have > 1 
          parameter therefore WSDL message description (whatever it is) 
          must have multiple parts.
Tom:      Starting to doubt the wisdom of cutting wsdl:message but 
          would like to make improvements.  See value in removing 
          message construct and keeping parts.
Roberto:  At a finer-grain, would like to keep the syntax within the 
          operation for referring to direction (and maybe sequence and 
          cardinality) over messages as a whole.
Roberto:  Writes up an example based on WSDL 1.1 example.
Roberto:  Writes up an example based on XML Schema ( similar to previous 
          proposal from roberto/jeffsch/gudge )
Roberto:  Writes up an example based on SW proposal.
Roberto:  (Re)writes Sanjiva proposal

Roberto:  Reviewing criteria:
          - 1 Similarity to WSDL 1.1:
            A (WSDL 1.1) is best
            B (earlier Roberto proposal) natural for people who think 
              about types,
            C (Sanjiva proposal) natural for people who think about 
              parts.
Kevin:    If operation points directly to the type system, would it be a 
          complexType?
Roberto:  We discussed model groups (to restrict attributes, for one 
          reason)
Jonathan: Does Sanjiva's type indicator commit to complexType or Element?
Prasad:   No.

Roberto:  2 Readability
Jeff:     Does new Sanjiva proposal allow reusability of messages?
Arthur:   Not clear that messages are, in fact, reused in practice when 
          WSDL is generated from code. May see some message reusability 
          when WSDL is written by hand.  Mostly an authoring concern. 
          May be some benefit if one is trying to determine if two 
          messages are semantically equivalent.
Igor:     The Sanjiva construct doesn't work with the MEP decision 
          (from yesterday).
Jonathan: Does start to beg for a wrapper to define message boundaries.
Arthur:   Modification of the syntax is not a difficult issue.
Jeff:     There are two things in SW prop. 1. Let's not have message be 
          top-level, let's in-line it. 2. Enhancing the message 
          construct by making it more expressiveness. So that we could 
          do things like say that a part was optional. Thinks there is 
          a deep seated desire from some people to have first class 
          notion of parts.
Umit:     At the moment the parts are a sequence. I could map a 
          sequence of elements in XML Schema to parts in a message.
          But other schema constructs ( like xs:all ) create problems
Jeff:     (to umit) So your concern is that XML Schema is TOO expressive
          and it would complicate bindings
[<Arthur> message parts are atomic wrt binding]
Umit:     Not exactly, i'm saying we have the expressive power today.
Jeff:     Confused by your argument
Umit:     The mapping from complex type in the schema world, is much 
          more complicated for the binding.
[<Arthur> message parts are the things you bind]
Don:      You might have to restrict the schema bits you use if you 
          actually care about parts.
Umit:     How do you bind ( for example ) xs:all?
[<kevinL> it's more an issue of best practice. the xsd author needs to 
          take it into consideration if sequence of elements are critical.]
Umit:     Why don't we remove operation too?
Roberto:  For example, operations provide a boundary around MEPs.
          The reference within the operation points to a type in XSD, but 
          one could reference a type within a MIME type system too.
          MIME could be used as the overall type system, if you like.
Tom:      Someone would have to invent such a language...
Roberto:  There's something there in WSDL 1.1, and if people cared, we 
          could easily take the MIME multipart binding and make it into 
          a type system.
Jeff:     There already is a MIME type system, it's just not very well 
          defined. (And I don't know if anyone cares enough to do so...)
David:    Is the point of the message construct to associate messages 
          with a MEP?
Roberto:  Yes
Prasad:   Why do you prefer putting an attribute on a type definition 
          rather than on an element?
Roberto:  More correct use of Schema but could do either.
Kevin:    An attribute on a complex type would allow doing a choice over 
          image/jpeg and image/gif.

Roberto:  3 Simplicitly / consistency for advanced users
          B (type system approach) gets rid of separate operation construct
          and rference component. Component model in A (WSDL 1.1)
Don:      Does the binding component model get more or less complex with a 
          type system approach?
Gudge:    Not sure the binding can remain independent of the type system 
          description.
Umit:     Experience writing a programming language binding suggests that 
          the wire binding for the type-system approach will be difficult.
JeffM:    Can we move forward with the type-system approach if we don't 
          have confidence about the feasibility of the wire binding?
Roberto:  Some small fraction of people are using sophisticated type 
          descriptions today, and they would continue to do so. Others 
          who are doing simpler things would continue to do simple things.
Arthur:   If our specs say XML Schema then compliant implementations will 
          have to implement XML Schema.
Gudge:    That's already true.
Arthur:   Tools may be generating sophisticated XML Schema.
Jeff:     Tools may also be generating things that are more regular.
Arthur:   Are we going to have to support XPath too?  This would drag XML 
          Schema processing into the port type and binding (where it's 
          limited behind the message construct today).
Roberto:  Do not currently prevent one, sophisticated part, and the type 
          system approach doesn't change that.
Tom:      Should we take the leave it alone or change it straw poll?
Gudge:    Depends on how you'd want to change it...
Jonathan: The in-lined message proposal isn't consistent with MEPs to 
          be reviewed today.

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

[Gudge scribes]

Topic: Continued discussion on removing message
SteveW:   How does removing message affect higher level languages 
          ( like BPEL which refers to messages )
Roberto:  We don't know what their requirements are. The Choreography WG 
          may well send us requirements.
Umit:     They need to be able to add document fragments...
Arthur:   Sanjiva is involved with BPEL, he wouldn't suggest something 
          that would break BPEL.
SteveW:   Right now BPEL references message directly so it would break.
Arthur:   Sanjiva will have to answer that.
Roberto:  We need to see some concrete requirements. We can't really be 
          constrained if we don't know the requirments.  We were going 
          to look at expressiveness.  Biased as I am, I think the schema 
          based proposal has a greater expressive power. As jeff said 
          we'd already decided to avoid adding more abilities to message.
Jonathan: With schema based approach you can incrementally use features.
          You can use all of schema today.
Roberto:  Yes, but then you would only have one part.
Jonathan: So you are saying the more expressive features are simpler 
          because of the lack of a wrapper.  Moving onto multiple parts 
          in a message.
Roberto:  In status quo and SW proposal, there are constructs called 
          parts.  In schema approach the Infoset is where the 'parts' 
          appear. There are no parts at the operation level. As an 
          advocate for B, I don't think parts are interesting in the 
          non-attachment case. Common use of multiple parts today is 
          to specify attachments.
Arthur:   Parts are also useful for HTTP GET
Jeffsch:  wow. We are going to have a non-SOAP HTTP binding.
Arthur:   Parts are a good match to the HTTP binding.
Jeffsch:  There are at least two wire bindings.
Arthur:   All of these are equivalent. Which is simpler.
Jeffsch:  Some of the expressiveness may not be all that useful. Prods 
          TomJ.
TomJ:     We're already dealing with 'wrapped Doc/lit' so parts are not 
          critical for rpc. Pulling the bits out of the schema is just 
          an extra level, it's not that big a deal.  The only thing 
          I've really heard is 'Why don't we just leave it alone'.
Various:  Assertions about parts being useful for parameters as well 
          as attachments.
Arthur:   Spec is silent on how the HTTP GET binding really works WRT 
          complex types. GET binding is being pushed by the WSA.
Jeffsch:  Rathole about non-SOAP HTTP binding. Refresh group memory.
          Whole host of requirments on HTTP GET binding mainly from 
          Paul Prescod. Some of these have been written up. WG was not 
          keen on most of them. PP assumes we are NOT trying to map 
          everything to every binding. We're doing the HTTP binding 
          because we have to, not because the WG is interested.
TomJ:     So, the GET binding isn't so interesting.  Are we going to 
          change this?
Roberto:  Asks the 'who's going to lie down in the road?' question
Philippe: We'll still have to do the HTTP GET binding whatever we do.
          We already know there are problems with the HTTP binding.
Jonathan: Some stuff about what arthur said earlier...
Philippe: DOrchard sent a proposal to the TAG about serializing 
          Infosets into URIs.
Jeffsch:  The web arch guys run screaming from the ugly syntax you get.
          Paul Prescod was comfortable with having simple URIs and not 
          being able to bind all messages.
Arthur:   With GET the parameters would be part of a results. Complex 
          arguments would be in POST.  Current non-SOAP bindings 
          should be one that allows you to specify the HTTP verb.
(scribe wonders if this has any bearing on getting rid of message)
Arthur:   Should be able to specify the verb on a per op basis
Philippe: Language design decisions should not be based on bindings.

ACTION:   Issues list maintainer to check that we have an issue 
          regarding being able to specify the verb on a per operation 
          basis.

Jeffm:    Answer to roberto's question is 'It depends'.  On whether 
          the soap binding is straigtforward, unambiguous etc
Jonathan: Is fixing the rpc issues regarding being reversible/round-
          trippable, unambiguous, straightforward orthogonal to 
          getting rid of message?
Umit:     I thought we were going to look at the binding issues and 
          then make a decision.
Roberto:  We can't make up a binding on the fly.
Umit:     How the binding works is crucial to the decision to get 
          rid of message.
Jeffsch:  Statement of procedure: We have a proposal. Roberto is 
          asking for large objections. Some people are saying that 
          we can't answer until we know what the binding looks like.
          Is that the only objection. 
Dale:     Many of these proposals are similar. Major question is how 
          does it affect binding?  Seeing the bindings and a 
          comparison would help.  Then could see which one was easier 
          to implement.
Roberto:  I think the expressiveness argument is compelling.
Dale:     Don't agree. Thinks SW proposal is just as expressive. Or 
          status quo is just as expressive.  ecause you can have 
          single part messages that reference a type.
Jeffsch:  You can't say that status quo/SW is as expressive as 
          schema approach and then also say that status quo/SW is 
          simpler in terms of binding.
Arthur:   So we can describe equally complex messages with all 
          approaches.
Jeffsch:  Then I reject the argument that the binding will be more 
          complex in any case. In all cases the binding has to deal 
          with arbitrary complexity. So you (Dale) are thinking about 
          how mime-types are addressed in a proposal that is based 
          around XML Schema ( or other type system ) based approach
Dale:     Yes, that's one of my concerns. Jumping into defining data 
          types other than XML in the XML type system is not 
          motivating to me.  I think that the complexity of doing 
          ( for example ) multi-part mime is XML Schema is not good.
Jonathan: Don't see the complexity.
Dale:     Characterize input as a xs:base64binary, but in multipart 
          mime it's not base64, it's binary.
Roberto:  We pick a type in the schema type system that represents 
          binary. The BINDING tells you how it gets serialized.
Jeffsch:  In the past we've been concerned with differences in the 
          way the message is described and the binding that is used. 
          In the type system proposal the coupling between the 
          message structure and the binding is slightly lower.  Could 
          bind it to SOAP ( binary would get serialized as base64 
          text ) or SwA ( binary would get serialized as binary mime 
          part )
Dale:     So seeing the bindings would be really useful.
Jeffsch:  Need to identify all the issues ( like, need to see the 
          bindings ) before we invest in the work.
Prasad:   So if I use this base64 ...
Roberto:  Binary array in programming language, binary attachment at 
          the serialization level. It takes an integrated infoset 
          approach.
Jeffsch:  You could validate it at the infoset level.
Igor:     What would it look like at the Infoset level?
Gudge:    It would have base64 children at the infoset level ( but 
          NOT at the serialization level ).
MartinD:  I can imagine an image, and a digsig. can you have both 
          binary attachments and inline binary?
Roberto:  At the binding level you would say which things are done as 
          'attachments' and which are done 'in-line'.
Jeffsch:  Seems like apps might want to influence whether stuff gets 
          inlined or serialized as an 'attachment'.
MartinD:  Could the binding make default assumptions?
Roberto:  Yes.
Martind:  Can I restrict it to image/gif, image/jpeg?  Some mime 
          types have other parameters.
Jeffsch:  If you wanted to serialize an infoset with multiple character 
          encoding...
Jonathan: May be some issues WRT exactly what goes in the 'media-type' 
          attribute?
TomJ:     Let's see a binding.
Jeffsch:  Not convinced that producing such a binding would help the 
          group.
TomJ:     I want to see what the SOAP-HTTP binding looks like.
Jonathan: Current binding has 'issues'. It will be hard to compare a 
          new proposal with the existing binding.
[<alewis> What do we mean by "binding" at this point?  The syntax 
          proposed?  Or something else?
(how the binding would actually work?)
Tomj:     I want to see how the syntax works with one or two 
          interesting examples.
Umit:     I would want to see an example of a complex type that has 
          'xs:all'
Alewis:   Would it be useful to ask the folks to use the same set of 
          examples?
Jonathan: Want to decide either - leave it alone, or we are going to 
          change it.
[<alewis> It's not going to happen today, I think.  And it sounds as 
          though there is a very *specific* requirement from some 
          people that's needed to move forward.]
Jonathan: One thing roberto is concerned about is what the level of 
          interest/opposition is.  It would be nice to know whether 
          there is interest in continuing to pursue this.
TomJ:     My thinking is just leave it alone.
Dale:     Agrees with TomJ.
[<alewis> I'd rather see message removed.  But it's not a *critical* 
          issue, as far as TIBCO is concerned.]
Jeffm:    Preference not to pursue it.  But if we do pursue it we'd 
          prefer SW approach.

A is status quo
B is referencing type systems directly from operations
C is SW proposal from Jan 2003
Preference poll:
  A:  3
  B: 11
  C:  5
Live with poll (not counting preferences):
  A: 14
  B:  5
  C:  3
Total Live with number
  A: 3  + 14 = 17
  B: 11 +  5 = 16
  C: 5  +  3 =  8
[Chair's summary: No clear direction, but clearly interest in pursing
this further.]

SteveG:   There is an example in SW proposal.
TomJ:     There is an example in the WSDL spec
ACTION:   Umit to send Gudge and Roberto a knarly XML Schema type example 
ACTION:   Roberto and gudge to create a branch and work up a binding 
          proposal based on referencing type systems directly from 
          operation components.

Tomj:     Channels Jacek. Does b support multiple type systems?
Roberto:  Yes, B supports multiple type systems.

-------------------------------------------------------
13:00 Property-dependent issues.  Goal is to at least have a plan of
      attack for those we cannot swiftly resolve.
    - BindingType proposal from Kevin [9].
    - HTTP Binding Issues (6a, 41) [10, 11].
    - Issue 28: transport='uri' [12]
    - Issue 2: SOAPAction has been deprecated, as of SOAP 1.2
      [13, 14, 15].
   
  [9] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html
 [10] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0102.html
 [11] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0067.html
 [12] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
 [13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2
 [14] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html
 [15] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html


Postponed all these issues, given that no foundation was laid in the
Properties/Features item yesterday.

-------------------------------------------------------
15:20 Issue 25: Interaction between W3C XML Schema and SOAP Data Model
      Gudge's explains at [16], Roberto's options at [17].
      How do we revive this issue?

 [16] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0186.html
 [17] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0071.html

Gudge: It's obsolete. We should drop it.


-------------------------------------------------------
15:00 Break
-------------------------------------------------------
16:00 WS-I Basic Profile [18] status, and walkthrough of the profile as
      it relates to WSDL (Prasad).

 [18] http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm


Prasad:   Wanted to show the latest draft but due to process issues we 
          cannot. Will try to do the best we can.
Jonathan: Document has a section on Description. Each section is a set 
          of requirements.  Some requirements match changes we have made 
          ( e.g. wsdl:import )
Prasad:   One key deliverable is a Basic Profile, profile of SOAP 1.1, 
          WSDL 1.1 and UDDI 2.0. Profile provides requirements based on 
          interop issues with those specs. Orofile defines conformance 
          targets, e.g SOAP Processors, WSDL documents, SOAP messages,
          and then applies requirements on those targets.  E.g. you must 
          define your WSDL document in this particular way.  Profile is 
          divided into sections, one for each spec.  Going to look at 
          the requirements on WSDL 1.1. Divided into sub-sections based 
          on the sections of the WSDL 1.1 spec. Each requirement or 
          group of requirements has associated rationale text that gives 
          reasoning for what the interop issue was and why the 
          requirements were needed.  Often correct and incorrect 
          examples are also provided. Requirements use MUST, MAY, 
          OPTIONAL, SHOULD etc.  Each requirement is based on one 
          conformance target ( e.g. SOAP message or WSDL description ).
          Profile in general restricts rather than relaxes the base spec.
          Profile defines a subset.  Sometimes offers clarifications.
          WS-I BP is trying to align it's decisions on SOAP 1.1 and 
          WSDL 1.1 with the work being done at W3C on SOAP 1.2 and 
          WSDL 1.2 where possible. Requirements based on WSDL 1.2 
          decisions ( or SOAP 1.2 decisions ) are flagged in the document.
          Example requirement: WSDL not very clear about importing WSDL 
          and Schemas. BP clarifies the use of wsdl:import and xs:import
          (R2001 - 2004).
Jonathan: So if WS-I were to profile WSDL 1.2 would they need these 
          requirements?  Ideally such a profile would not have any 
          'clarifications'. So a WSDL 1.2 profile would be subsetting 
          the WSDL 1.2 spec based on places we had provided optionality.
Don:      Should we make notes of feedback we want to send to WS-I?
Various:  Some discussion about whether schema types in an imported WSDL 
          are visible to the importing WSDL.
Prasad:   R2005 says that targetNamespace of imported WSDL must match 
          namespace attribute on wsdl:import.  R2007 is an example of 
          a mismatch between the schema for WSDL and the text of the 
          spec. 
Jonathan: So for our spec is the schema normative or the spec?
Philippe: We can fix the schema anytime we like. Make the schema 
          non-normative (it's not in TR space).
Prasad:   R2008 is another clarification. You don't need to follow the 
          location attr.
Arthur:   What about same namespace imports, are they legal?

ACTION:   Prasad to raise issue of same namespace imports with WS-I BP.

Prasad:   R2022 another clarification of schema vs spec. R2101 is 
          saying you must import things before you can reference them.
          R2110 - BP prohibits use of encoding, including SOAP encoding, 
          hence soapenc:arrayType is disallowed.  Message section: 
          Profile makes clear statement as to when to use type vs 
          element in message parts. Also covers number of message parts.
          Newer versions of BP doc have cleaner language in this section.
          Further clarifications of messages. Port types section.
          Addresses description of parts that form headers. BP allows 
          parameterorder.
TomJ:     It is useful for codegenerators.
Jonathan: Should we define a set of code-gen hints? In another namespace?
TomJ:     Would be nice to have more hints. Hints could include funtion 
          names, signature etc. Would help people to map into other 
          programming languages
Jonathan: What other hints are there?
Jeffsch:  Rpc style is one kind of hint. Was wild speculation but we 
          could publish a note along the lines that the definitive 
          'thing' is the messages but hints in the WSDL could help people
Jonathan: Would be nice to have adequate set of hints.
Jeffsch:  Might help with layering.
TomJ:     Parameterorder was more of a pain to deal with than a helpful 
          hint ;-)
Prasad:   Profile mandates SOAP-HTTP binding so Notification and 
          Solicit-Response are disallowed as that binding does not 
          define mapping for those operation types.  Binding section:
          Can only use the SOAP-HTTP binding, can't use MIME bindings 
          or HTTP GET/POST bindings. Might change due to recent 
          decision to incorporate attachments ( means fixing the WSDL 
          MIME bindings )
Tomj:     Is WS-I going to do SwA or DIME?
Gudge:    SwA
Various:  Discussion of what our scope is and which attachment 
          technology WSDL 1.2 should support.
Jonathan: We need to think about it further. Will be gated somewhat 
          by the work done by XMLP.
Prasad:   BP intends to fix-up the WSDL 1.1 MIME binding so that it 
          works with SOAP with Attachments ( SwA ).
TomJ:     Does MS emit WSDL for DIME?
Jeffsch:  WSE ( Web Services Enhancements ) supports DIME via 
          WS-Attachments.
Prasad:   Ports section: empty. SOAP Binding section: Only supports 
          SOAP 1.1. More schema clarifications. Can't mix and match 
          style in a binding. All ops must be either rpc or doc.
          Services can expose compliant and non-compliant ports.
          Can mark WSDL descriptions as being WS-I compliant. A 
          <wsi:Claim/> element can appear in the wsdl:documentation 
          element.
[<wsi:Claim conformsTo='uri-for-basicprofile' />]
Prasad:   BP says one-way messages do not have SOAP-level responses; 
          this is consistent with WG decision about one-way MEP 
          yesterday. Looks as if BP needed to clarify wording re: 
          when namespace is needed. More clarifications regarding 
          inconsistency between schema and spec. Descriptions MUST 
          use XML schema 1.0 and MAy use any schema construct
Jonathan: What's the rate of new issues being brought up?
Prasad:   It had stabilized but with the decision to address 
          attachments new issues are being generated against the 
          WSDL MIME bindings.
Jonathan: Is the BP draft due in 2 weeks going to be a 'Last Call' 
          draft?
JeffM:    More likely to be LC - 1. Plan is to get what we have out 
          and then have a 'last call' later. Let's use WS-I terms.
          BP WG says 'we think we are done' and publishes a draft.
          Minimum 30 day review period, change proposals can be made 
          and voted on up to 7 days before the end of the 30 day 
          period.
Philippe: Does the WG plan to respond to comments?
Jeffm:    Yes.  WG members can make concrete change proposals. If the 
          WG says, yes we approve the draft then it goes to the board.
          Board reviews and votes then it goes to WS-I membership. WS-I 
          membership votes and spec is published. At any stage may get 
          sent back to WG for changes. Are trying to do a public 
          release to get public comment.


-------------------------------------------------------
17:30 Adjourn

raw IRC log: http://www.w3.org/2003/01/21-ws-desc-irc

Received on Friday, 24 January 2003 14:43:18 UTC