Minutes: 13 Nov 2003 WS Description Teleconference

Web Service Description Group
Minutes, teleconference 13 November 2003

 

Present:

 Erik Ackerman          Lexmark

 David Booth            W3C

 Allen Brookes          Rogue Wave Software

 Roberto Chinnici       Sun Microsystems

 Glen Daniels           Sonic Software

 Paul Downey            British Telecommunications

 Youenn Fablet          Canon

 Dietmar Gaertner       Software AG

 Tom Jordahl            Macromedia

 Jacek Kopecky          Systinet

 Amelia Lewis           TIBCO

 Kevin Canyang Liu      SAP

 Lily Liu               webMethods

 Jonathan Marsh         Chair (Microsoft)

 Ingo Melzer            DaimlerChrysler

 Jean-Jacques Moreau    Canon

 Bijan Parsia           University of Maryland MIND Lab

 Arthur Ryman           IBM

 Jeffrey Schlimmer      Microsoft

 Igor Sedukhin          Computer Associates

 William Vambenepe      Hewlett-Packard

 Sanjiva Weerawarana    IBM

 Umit Yalcinalp         Oracle

 Prasad Yendluri        webMethods, Inc.

 

Regrets:

 Philippe Le Hégaret    W3C

 Adi Sakala             IONA Technologies

 Jerry Thrasher         Lexmark

 

 Scribe: JeffSch

 Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0091.html

 

 Topic: Approval of Minutes

 Minutes of 30 Oct telecon approved

 Postponing approval of 3-5 Nov face-to-face meeting minutes

 

 Topic: Review of Action Items

 Sonic\Glen may post clarifications

 Bijan action item re: message extensibility pending

 Amy action item re: cyclical includes pending

 Part 2 editors action item to clarify wording re: generated vs. sent pending

 Glen action item re: removing headers and/or proposal for generic header-adding property/feature pending

 

 Topic: Administrivia

 Noted that 27 Nov, 25 Dec, and 1 Jan are holidays

 Substitute chair for 20 Nov pending

 Logistic information for 28-30 Jan face-to-face meeting pending

 Drafts for Part 1 and Part 2 published

 

 Topic: New issues

 

 Intermediaries:

 http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0331.html

 Canon\JJM notes that WSDL does not support SOAP intermediaries.

 Do we want to enable this in WSDL 2.0?

 If yes, then there are a number of additional questions to address.

 To be marked as a new issue [Done. Issue 96.]

 

 Merge FRM with MTF:

 No objection to dropping.

 Correction, W3C\David may need to follow up on the issue, but will close this issue and re-open if needed.

<alewis> FRM and MTF provide different semantics with regard to the target for delivery of a fault (at least potentially).

 

 Short scenarios for MEP:

 http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0064.html

 ACTION: Tibco\Amy to draft sample scenarios for MEPs

 

 Schema for each MEP:

 http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0070.html

 (Note: 0064 is Schema for each MEP; 0070 is scenarios for MEP)

 Canon\Youenn notes that current syntax precludes writing a schema that will validate the MEP.

 For example, if there was a schema for a MEP, it might say that you need an input with @messageReference equal to some value. But this isn't possible today given the target namespace of wsdl:input isn't the same as the target namespace of the MEP.

 To use existing XML Schema technology, you'd need to put the MEP and the WSDL constructs in the same namespace.

* dbooth following up on the previous topic, doesn't see a need to change re-open the fault rules issue.

 Macromedia\Tom willing to forgo fine-grained validation.

 Tibco\Amy agrees that the potential complexity is a bad trade for the additional fine-grained validation it affords.

 ... and notes that the complexity of substitution groups was untenable in previous designs for extensibility.

 Canon\Youenn clarifies that the current value of the message references would become element names (per earlier Canon\JJM proposal).

 Tibco\Amy notes that each element name would be different (rather than optional @messageReference values).

 ... Concerned how the overall validation of children of interface/operation would be validate.

 Microsoft\Jonathan wondering if you would lose recognition of direction with this proposal?

<Marsh> s/Microsoft\Jonathan/Jonathan/

 Canon\Youenn proposed adding an attribute to indicate direction but would need to ensure that each intermediary would have the schema for the pattern.

 Sonic\Glen interested in exploring this direction.

 Macromedia\Tom willing to forgo fine-grained validation.

 Sonic\Glen does not believe it will be a burden on the processor and sees value in using XML Schema to validate interface/operation/*

 Straw poll: interest in pursuing this?

 IBM\Arthur recommends shutting down at this stage in the process.

 7 yes; 6 no.

 (No action item recorded.)

 

 @messageReference AII in binding/operation{infault,outfault}:

 ACTION: jeffsch to start thread re: whether this AII is optional

 

 Topic: Pattern inference

 Drop {direction} from component model:

 Sanjiva notes that since @messageReference is optional, the property is not.

 

 Topic: HTTP binding options

 http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0048.html

 Jonathan notes significant interest in Option 5: HTTP binding with URL replacement.

 Glen believes URL construction is a wonderful thing but does not believe it should be done by ripping apart the message.

 ... Has not seen use case where the same abstract interface/operation/{input,output} goes into /Envelope/Body/* in one case and into a URL in some other case.

 David notes Philippe's concern that we adequately support HTTP.

 Glen notes that there are many other options but does not like conflating definition of the message payload with the destination that it is eventually going to.

 ... where the destination is the URL.

<Roberto> +1 to what Glen said

 ... There is a bunch of stuff (address, payload, transport information) that needs to be conveyed. It is our job to cleave this correctly, and while it should be possible to blur the distinctions, we should not be encouraging that.

 ... Wants to support all of HTTP -- a great thing; what are requirements? Need to be able to parameterize URLs? OK. But it is odd to put some of the body into a URL.

 Sanjiva notes that constructing a URL is not (technically) part of HTTP.

 When asked, Glen noted that he would be in favor of even Option 1, dropping the HTTP binding because it brings in hairy issues. Sees value in focusing WSDL on defining SOAP processing model-equivalent services.

 ... Shoehorning all the SOAP concepts into other frameworks is painful.

 Jonathan notes that HTTP is in our charter.

 (No decision. Expect discussion to continue in e-mail.)

 

 Topic: TAG feedback on WSDL component designators

 http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030

 Jonathan proposal based on that feedback.

 http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0090.html

 Umit asked for clarification of (4), recommending that WSDL documents be available at target namespace.

 ... Does that relate to a prior proposal for a @wsdlLocation (ala @schemaLocation)?

 Jonathan notes another TAG conversation re: what target namespaces should resolve to, e.g., an XHTML document with RDDL tags.

 Umit concerned about implications of recommending entire WSDL available at that namespace.

<umit> I am not concerned, I am stating that the statement is incomplete at its best. 

<umit> (4) in http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0090.html

 Jonathan proposed dropping (4) from the proposal, but notes that making WSDL resolvable by target namespace gives fragment identifier typical meaning.

 Arthur notes that consensus is going toward making target namespaces resolvable and putting RDDL-like documents there, should the WG do that for the XML Schema for WSDL 2.0?

 Jonathan notes that the W3C Web master has a policy that controls that.

 Arthur interested in helping out with this administrative function, if needed.

 Sanjiva and Umit in favor of changing (4) to aligning with XHTML/RDDL finding.

 

 Topic: Ambiguous interface semantics

 http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0150.html

* jeffsch is personally confused about the issue and any potential action

 Jonathan, Sanjiva, and Roberto are confused / do not understand the issue.

* umit I agree with you :-)

 Proposed closing this issue for lack of a concrete proposal.

 David notes that we ought to understand what the issue is before closing it.

 David also notes that he doesn't understand the issue.

 Jeffrey wondered if it would be productive to invite Mark Baker to participate in a teleconference and/or face-to-face meeting

 ACTION: Jonathan to identify the issues and invite Mark Baker to participate in a teleconference.

 

 Topic: Appendix E cleanup

 http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0136.html

 Pending discussion with Jacek and Bijan.

 

 Topic: Other topics

 

 In-line schemas referring to each other:

 Arthur asking for status on this issue.

 Summary at http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0062.html

 Jonathan summarizes we won't constrain presence of @schemaLocation and rely on the magic of the xs:import mechanism to get XML Schema components wherever it can.

 Arthur, to refer to another, in-line schema?

 Jonathan, notes that you can refer to another _target namespace_, and the schema processor gets those components wherever it needs to, including the other, in-line schema.

 Sanjiva suggest that we put something in the primer to cover the two, in-line schema case.

 Tom notes that if you put @schemaLocation, and the schema processor tries to resolve it, it may fail. Should recommend against using @schemaLocation in that case in the primer.

 Amy wonders if you can use the component designator as the value of @schemaLocation...

 ... and warns against digging into changing how embedded schema works.

 ... but does not object to putting something into the primer about best practice.

 Sanjiva notes this might also be a good entry for a FAQ.

 Umit notes that this not significantly different than the case where some other document includes two, embedded schemas, and thus is not specific to wsdl:definitions/wsdl:types, but there is no FAQ from the XML Schema WG.

 Jonathan reiterates that we decided we would not do anything special.

<psd> given how long we've been discussing this, we need a strong pattern of use of how to reference between inline schemas for the sake of interoperability!

 Proposed adding an example to the primer so people will be able to infer acceptable practice.

 David soliciting help constructing an appropriate example.

 ACTION: David to add discussion / example(s) re: @schemaLocation for embedded schemas to the primer.

 Amy notes the value of producing positive and negative examples of embedded schemas.

 Jonathan notes that we do have a QA responsibility to produce valid and invalid WSDL documents, and could include this as a dimension of that.

 David asked if we have an editor for the test suite?

 Jonathan notes that we have a QA Task Force with no members.

 Arthur interested in collecting valid and invalid examples as part of the WSDL validator effort.

 David asked if we need to track expected tests?

 Jonathan related his experience that tests often come from vendors, sometimes conflicting, and often without a guarantee that the set of tests provide systematic coverage.

 Bijan noted a quality of the RDML (?) test suite.

 Call for volunteers for the QA Task Force

 Amy volunteers

 Convey to the task force that we want to include test cases re: in-lined schemas

 Umit asking for clarification re: BP rationale for constraining in-line schemas and whether that would affect our decision.

 ... Notes that BP 1.0 compliant processors may not be able to process in-lined schemas that are explicitly allowed by this WG through test cases, primer, FAQ, etc.

 Sanjiva notes that BP 1.0 is scoped over WSDL 1.1 whereas we're working WSDL 2.0.

* psd may volunteer for QA Task Force .. will need to talk to TPTB

 Jonathan recommends the WG review existing issues as the basis for future telecons.

 Meeting adjourns.

 

EOF

Received on Thursday, 13 November 2003 20:24:44 UTC