Minutes, 28 Oct 2004 WS Description WG

Web Services Description Working Group;
2004-10-28 conference call minutes

 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Ugo Corda	             SeeBeyond
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Hugo Haas              W3C
 Anish Karmarkar        Oracle
 Jacek Kopecky          DERI
 Amy Lewis	             TIBCO
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky	Oracle
 Dale Moberg            Cyclone Commerce
 Jean-Jacques Moreau    Canon
 Bijan Parsia           University of Maryland MIND Lab 
 Arthur Ryman           IBM 
 Jerry Thrasher         Lexmark 
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Prasad Yendluri        webMethods, Inc.

 Helen Chen             Agfa-Gevaert N. V.
 Tom Jordahl            Macromedia
 David Orchard          BEA Systems
 William Vambenepe      Hewlett-Packard
Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0067.html
Scribe: Prasad Yendluri
2.  Approval of minutes:
  - Oct 21 [.1] 

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0066.html

Marsh: Any comments or questions?
Minutes Approved.

3.  Review of Action items [.1].  Editorial actions [.2].

PENDING   2004-04-01: Marsh will get schema tf going.
PENDING   2004-09-02: Bijan to create stylesheet to generate a
                      table of components and properties.
PENDING   2004-09-16: Editors to move App C to RDF Mapping spec, 
                      except the frag-id which will move 
                      within media-type reg appendix.
PENDING   2004-09-16: Editors to fix paragraph 6-9 of section 
                      2.1.1 moved into 2.1.2
                      which talks about the syntax.
PENDING   2004-09-16: Hugo to get a URI to use for DTD example 
                      in Appendix E.1 (LC38)
PENDING   2004-09-30: Arthur to add Z notation to Part 1.
PENDING   2004-10-07: Paul to set up test suite directory 
                      structure (Hugo assist)
PENDING   2004-10-07: Primer editors to use the new 
                      terms "Web service" and "consumer|client".
dbooth: Kevin and I are working to produce a full draft by Friday.
        We have enough got done and I would like to get feedback from the WG
Marsh:  Plan for a Working Draft?
dbooth: Hoping get done by tomorrow. But I like people to take a quick look today 
        and give feedback on how the approach is working out.
Marsh: Everybody try and do that.

PENDING   2004-10-14: Arthur to prototype a javascript 
                      implementation and decide on the two doc's 
                      vs javascript method later.
PENDING   2004-10-14: Editors to add a statement like: 
                      The Style property may constrain both 
                      input and output, however a particular 
                      style may constrain in only one 
                      direction. In Section of Part 1.
                      (subsumed by LC21 resolution?)
PENDING   2004-10-21: Glen to respond to Tim Ewald re: LC9. 
PENDING   2004-10-21: Hugo to generate a summary of pub options. 
PENDING   2004-10-21: Roberto to list some non-fatal errors 
                      for consideration if that's useful.

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/actions.html

4.  Administrivia
  a. November 9-11 (Sunnyvale, CA) registration [.1], logistics [.2]
  b. Jan FTF?
  c. Tech plenary?

[.1] http://www.w3.org/2002/09/wbs/34041/WSD0411/
[.2] http://www.w3.org/2002/ws/desc/4/04-11-f2f.htm

Marsh: Working with WS-Addressing group to have a joint meeting in Jan,
       possibly in Australia
Sanjiva: Is Srilanka out again?
Marsh: No. There is a chance of getting critical mass if we co-host with 
Sanjiva: I will be happy to do it
Marsh: O.k. I will put that in
dbooth: I prefer not the week of Jan 12th
Marsh: We are talking the week after that

5.  New (non-LC) Issues.  Issues list [.1].
  - none.


6.  Last Call Issues [.1].  Comments list [.2]
  - LC70 Pluggability of Schema Languages in WSDL [.3]

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/
[.2] http://lists.w3.org/Archives/Public/public-ws-desc-comments/
[.3] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC70

Marsh: New LC issue from Asir on pluggability of schema languages

7.  Media Type Description [.1] Last Call status
  - publication update


Marsh: We wanted input from the Schema WG on when they would like the 
       LC period to end. Just got the Nov 24th date from them. We can 
       fit that in and get that docs out today as the LC.
Marsh: Thanks to Anish and Hugo for the hard work on this

8.  Issue LC5f: QA Review on WSDL 2.0 Part 1, intro and conformance
                issues (f) [.1]
  - Roberto's proposal [.2]
  - Awaiting list of "errors" from Roberto.

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5f
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0027.html

Marsh: Skipping over. Waiting on mail from Roberto.

9.  Issue LC29b: Review of WSDL 2.0 Pt 3 Last Call WD (b) [.1]
    Issue LC18: Relationship between Features and SOAP Modules ?? [.2]
  - Awaiting Glen's action

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC29b
[.2] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC18

Marsh: Both issues are reg. lack of explicit relationship between 
       Features and Modules. Glen responded why. MarcH was satisfied 
       but Prasad had a further question.
Asir: Glen promised to do another write up, that talks about relation 
      bet. features and modules. Its in the last para. of his email. 
      He wants a new action item.

NEW ACTION: Glen to write up the relation between features and modules
Marsh: Prasad is your concern same?
Prasad: Same. Glen says we don't need to identify the Features in 
        the module. I was asking how you can deduce the features a 
        module supports if they are not identified.
Marsh: We will formalize Glen's write-up to formalize text that goes 
       into the spec

10. Issue LC29d: Review of WSDL 2.0 Pt 3 Last Call WD (d) [.1]
  - DaveO's proposal [.2]

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC29bd
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0061.html

Marsh: Skipping, DaveO not present.

11. Issue LC19: Fault Component Re-usable Across Interfaces [.1]
  - Awaiting Asir's action to detail binding changes

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC19

Asir: I did my action
Asir: There are 4 changes:
      1. Adding a new definition component faults
      2. How operation fault reference ties to a fault in Definitions 
         faults property
      3. How Binding Fault Component describes the concrete binding of 
         a fault to a concrete message format. How it points back to a 
         fault component in the Definitions faults property
      4. Fault URI reference will change from x/y to x. x is the name 
         property of the fault.
Arthur: I like it as it treats them like exceptions in Java
Sanjiva: I have one concern about the binding. Two interfaces that use 
         the same fault would have to bind it twice. Which is redundant. 
         The bindings for the same fault in both would have to be same.
         Otherwise code generation would break.
Asir: I don't understand the last part
Sanjiva: What if you define different fault codes and sub-codes for the 
         same fault in both bindings.
Asir: I think you are not allowed to do it.
Sanjiva: Today the problem does not exists as we keep faults as top level 
         children of the interface and binding
Asir: We have an explicit constraint in part 1.
      Section 2.10.1: For each Binding Fault component in the {faults} 
      property of a Binding component, the {fault reference} property 
      MUST be unique. That is, one cannot define multiple bindings for 
      the same fault within a given Binding component.
Sanjiva: It is saying a different thing. You can not binding the same fault 
         to two different things in the same Binding component.
Sanjiva: What your proposal allows is to define two different fault-codes 
         for the same fault.
Asir: No it is not possible. That is why I mentioned the last para. in 
      section 2.10.1
Sanjiva: It is different. It is like section 2.11.1 for binding operation.
Asir: I am not getting the point.
Arthur: If a fault is reusable across interfaces, wouldn't you want to 
        bind the fault same way independent of an interface? If is 
        reusable, why would I bind it differently? Within a binding you 
        would also have to promote binding fault.
Asir: Fault is a property on the binding component
Sanjiva: But, in order to support first class top level faults, you need 
         to be able to say binding.fault is a QName. Otherwise you will 
         run into the issue of two different fault-codes
         for the same fault.
Asir: I think you can raise this new issue
Sanjiva: Not a separate issue. I am not going to vote for it unless 
         this issue is resolved.
Arthur: If you really want to promote faults, you need to promote 
        bindings too.
Roberto: Did we already decide we are not going share fault by extending 
         fault interfaces? If someone is defining a system with multiple 
         interfaces that share faults, ...  I don't see much value in 
         giving faults independent existence. This proposal is technically
         correct with Sanjiva's amendment but, ..
Asir: Binding fault contains soap.fault code, subcode etc. If we promote 
      binding to definitions what is the meaning of what will be its 
      meaning outside the binding?
Sanjiva: It is not promoting biding fault component to top level. You 
         still have the notion binding.  Except you are not binding an 
         interface but, you are binding a fault.

         <binding interface="qname"> .. </binding>
         <binding fault="qname"> ... </binding>

Sanjiva: Then we have a different problem. We will have to allow 
         composition of binding which we do not have now. To say, I 
         am binding this interface along with that fault-binding.
Asir: I understand what you are saying based on what you pasted in 
      IRC. Today interface has a subset of all possible faults. Binding 
      has subset (or all) of those faults and binding.operations ref. 
      a subset of those. So you have a subset of subset of subset. Based 
      on this I don't see a stronger relationship to put all the 
      fault-names in the binding mark-up. Regardless of how many
      we have in the interface it does not fully describe them in the

Sanjiva: I don't think anything changes with regards to the faults being 
         an open set. The faults that service author feels important to 
         the clients are what are described. That is not complete list 
         of all the faults.
Asir: That is why I am saying the relation between interface and binding 
      is week. It is ok to be out side the interface.
Prasad: Don't we have the same issue that Sanjiva raises currently? 
        Two different bindings for the same interface could bind the 
        faults differently (different codes).
Sanjiva: Sure you can have SOAP 1.1 and SOAP 1.2 binding.
Prasad: You can also have two different SOAP 1.2 bindings for the same 
        interface. But, don't we currently have the same issue of binding 
        the faults in the same interface differently in two different 
Sanjiva: That is fine but, the whole point of this is to enable 
         reusability of bindings
Asir: The way the issue was raised is, reusability of fault component 
      across interfaces. We did not talk about bindings.
Sanjiva: To make faults top level. If you do that, the analogous thing 
         to do is, the ability to bind faults top level.
Prasad: I think there is difference in reuse of faults at the interface
        level, different interfaces and operations and reuse at the 
        binding level. I think we want to be able to bind the same 
        fault differently based on the binding.
Arthur: The issue is how should the fault be modeled. In the programming 
        example case, interfaces and faults are modeled as classes. So 
        they are the same kind of things. That enables re-use.
        However we are saying Fault is not like an interface. It is like 
        an operation. However as Roberto said, you can still achieve reuse 
        by define an interface with a set of faults and re-use them. 
        You can do that and keep the current component model or if you
        change the component model to elevate the faults to top level, 
        our component model should be consistent. That means 
        changing the structure of the binding component. At binding 
        operation and fault are different.
        I will object to this unless we change the binding structure.
Roberto: Arthur said what I wanted to say. The proposal should be amended 
         to cover the binding.
Asir: I would like to understand what exact changes to binding are needed.
Arthur: As sanjiva showed in IRC, just as we have interface=QName in 
        binding, we also need fault=QName. In the binding for the 
        interface you need to be able to refer to the binding for the fault.
Asir: It is ok with me if you want to add this.
Marsh: So, the proposal needs to be amended before we can move forward
Sanjiva: I think so
Arthur: How about the suggestion Roberto made to define faults in 
        interface and reuse
Asir: We don't like it as we need to extend the interface to to it
Marsh: Is there an interest in developing an augmented proposal? Or 
       should we go for a straw-poll?
Sanjiva: The proposal as it stands is incomplete. 
Arthur: Why is the idea to extend interface with faults not good enough?
Asir: I explained in my email
Marsh: It seems people are looking for amendment at the binding level 
       also to be able to support this proposal. 
Sanjiva: I can not vote for this proposal without knowing how the other 
         (binding) part is going to work. This is a major change. We need 
         to see the full picture before we vote.

Sanjiva: Can we defer this until the F2F
Marsh: Sure. We will just postpone until then.

12. Issue LC20: Feature Composition Edge Cases [.1]
  - Need Glen's input
  - Also see LC27

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC20

Marsh: Skipping. Need Glen's input.

13. Issue LC22: URI Style and SOAP Response Pattern [.1]

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC22

Asir: Related to LC21. In light of resolution LC21, LC22 is no longer 
      an issue.
Marsh: Closed as rendered obsolete by resolution for LC21.

14. Issue LC23: Elaborate: Cannot be Serialized as XML 1.0 [.1]

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC23

Marsh: The intent is to serialize as a different version of XML. Was 
       that the issue?
Asir: I understand it but, when some of our engineers found it puzzling until I explained issue 177
Marsh: It is our intent that you can serialize any valid set of 
       components as XML 1.1
Marsh: Can we reassign this as editorial to explain the above? 
Asir: There is no relation to schema
Marsh:  Or we can close it and say it is XML version issue only and 
        not related to schema
Marsh: Any issue to closing this with the above resolution
None. Closed.

15. Issue LC24: "ad:mustUnderstand" - ?? [.1]

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC24

Asir: I don't see a use case for this or proper binding for the HTTP module
Marsh: We need to wait for Glen or DaveO
Skipped over

16. Issue LC25: What is a feature-binding? [.1]

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC25

Asir: This is in the HTTP module that binds to the application data module. 
      They say it is a module and it is a feature-binding
Amy: That is because a module is how a feature is bound to SOAP
Marsh: Are you asking for a formal definition of feature-binding in the spec?
Asir: Yes. Also we are using both feature-binding and module term
Amy: That is because of different editors. If you can enter as editorial
     Glen or I will clean up.
Marsh: Close LC25 with resolution, we will add a formal definition of 
       feature-binding in the spec; and we will check on consistent use of 
       feature-binding and module throughout the section

17. Issue LC26: wsdlLocation on the chopping block ? [.1]

[.1] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC26

Asir: We do not have any concrete use cases for WSDLLocation. Saw one 
      for WS-MessageDelivery. It also says WSDLLocation may ref. WSDL 
      components as fragment identifiers. Do we have concrete use cases 
      for this also?
Anish: We do use WSDLLocation in our implementation to get to other WSDL 
       components.  I will provide a detailed usecase via email.

NEW ACTION: Anish to provide a use case for WSDLLOcation via email

Roberto: Is there any new information in the LC issue to reconsider this
         decision? Clearly majority of the WG thought it was useful. I do 
         not see any issue technical or otherwise for reconsideration.
Marsh: I am happy to go to vote directly. As to information, looking through
       BPEL, Chor, Addressing and not actually finding any use case for 
       WSDLLocation. If they are not the ones the decision was based on 
       we may want to defeat this quickly.

Sanjiva: BPEL clearly depends on WSDL and BPEL cannot use it now because
         WSDL 2.0 is not there yet. It will be used in the future when 
         they import WSDL stuff  to refer to the location of the WSDL. 
Roberto: WSDLLocation is meant to be used when you are passing service
         element around as a reference.
Marsh: In WS-Addressing WG we are talking about providing reference to 
       the metadata you need to access the service in a reference. I can 
       imagine WSDLLocation being used in conjunction with WS-Addressing.
Asir: There is a 2nd part in the issue. Can we reference WSDL components 
      via WSDLLocation? It is in section 7.
Marsh: If we get rid of that part we need not answer the 2nd part.
Marsh: Lets take a straw-poll on whether we need WSDLLocation. Let us do
Marsh: Question for poll: Should we remove WSDLLocation?
Straw-poll results: Yes - 1; No - 10 ; Abs - 1
Marsh: Asir, Ok with that?
Asir: Sure
Marsh: 2nd part. Should we allow fragment identifiers in WSDLLocation?
Marsh: Is WSDLLocation referring to a WSDL file? or a Definitions component 
       in WSDL?
Arthur: I don't think we should allow frag-ids in WSDLLocation. If you 
        want to refer to a WSDL component use frag URIs as described 
        in Appendix C. Namespace in combination with frag id.
Marsh: If I use WSDLLocation including frag-ids to something that is not a
       Definitions component then it is an error.
Bijan: That is my understanding too.
Roberto: We should preclude use of frag-ids in WSDLLocation.
Marsh: The first sentence in section 7 is confusing. We should reword that.
       Nothing wrong in using QNames to refer to WSDL components somewhere 
       else. WSDLLocation helps find the document that those WSDL 
       components are contained in.
Marsh: WSDLLocation identifies a Definitions component, not an arbitrary 
Bijan: Excluding frag-ids won't be sufficient. The regular URI may 
       dereference an arbitrary component. Not the Definitions component 
       only. That is what we want to preclude.
Prasad: Section 7.1 seems appropriate for that clarification.
Marsh: The first sentence in section 7.0 is confusing. It seems to imply 
       a URI can refer to an arbitrary WSDL component where as it is 
       actually talking about QNames as references.
Marsh: Proposed Resolution: Modify section 7 to remove any implication 
       that you can point to arbitrary WSDL component using WSDLLocation. 
Marsh: I assume that is sufficiently precise resolution for the editors. 
Marsh: Any objections to closing with the above resolution?
No objections. LC26 is close.

End of call


Received on Friday, 29 October 2004 21:35:09 UTC