- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: 2004年6月18日 17:00:10 -0700
- To: <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA203FBC56C@RED-MSG-30.redmond.corp.microsoft.com>
Minutes, 17 June 2004 WS Description telcon Present: David Booth W3C Allen Brookes Rogue Wave Software Helen Chen Agfa-Gevaert N. V. Roberto Chinnici Sun Microsystems Ugo Corda SeeBeyond Glen Daniels Sonic Software Paul Downey British Telecommunications Youenn Fablet Canon Tom Jordahl Macromedia Jacek Kopecky DERI Amelia Lewis TIBCO Kevin Canyang Liu SAP Peter Madziak Agfa-Gevaert N. V. Jonathan Marsh Chair (Microsoft) Mark Nottingham BEA Systems David Orchard BEA Systems Bijan Parsia University of Maryland MIND Lab Jerry Thrasher Lexmark William Vambenepe Hewlett-Packard Asir Vedamuthu webMethods Sanjiva Weerawarana IBM Umit Yalcinalp Oracle Prasad Yendluri webMethods, Inc. Regrets: Hugo Haas W3C Josephine Micallef Telcordia/SAIC Jean-Jacques Moreau Canon Arthur Ryman IBM -------------------------------------------------------------------- Agenda 1. Assign scribe. Lucky minute taker for this week is one of: Erik Ackerman, Adi Sakala, William Vambenepe, Prasad Yendluri, Jean-Jacques Moreau, Umit Yalcinalp, Igor Sedukhin, Dale Moberg, Paul Downey, Hugo Haas William for first hour, Prasad after that -------------------------------------------------------------------- 2. Approval of minutes: - June 10 [.1] (corrected) [.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0128.html Approved as corrected. -------------------------------------------------------------------- 3. Review of Action items [.1]. PENIDNG 2004年04月01日: Marsh will get schema tf going. ?ED 2004年04月29日: Part 1 editors to adopt Jacek's "purpose of the binding" text, without "interchangeable" endpoints, and using "confidentiality" (or similar) instead of TLS. ?ED 2004年05月19日: Editors to include in the primer an example that uses MTOM. (Issue 72) ?ED 2004年05月19日: Editors to make propogation of modules and f&p use the nearing enclosing scope. (Issue 180) ?ED 2004年05月19日: Editors to fix component model to remove default* properties, use mapping from syntax instead. (Issue 182) ?ED 2004年05月20日: Editors to incorporate Hugo's full potato proposal. (Issue 54) ?ED 2004年05月20日: David Orchard to update HTTP binding to include discussion of how to generate an accepts header from schema annotations conformant to the media types extension document, and to use outputSerialization based on that information. ?ED 2004年05月20日: Editors to incorporate http:{properties} into binding. ?ED 2004年05月21日: Sanjiva to implement the resolution that @soapaction not there means no soapaction. (Issue 1) DONE [.3] 2004年05月21日: Part 2 Editors to add such a statement. (Issue 191) ?ED 2004年05月21日: Part 3 Editors to add a statement to relate each of the two soap meps to wsdl meps. (Issue 191) ?ED 2004年05月21日: Editors to add ednotes to the spec to indicate areas that had contention. (Issue 190) ?ED 2004年05月21日: Editors to remove @separator from HTTP binding. (Issue 190) PENIDNG 2004年05月21日: DaveO to write up a scenario to motivate path creation on a per-operation basis. (Issue 190) DaveO would like people to comment on his example of HTTP binding usage ?ED 2004年05月21日: Editors to write up that we allow http:version etc. in the soap binding when the protocol is http. (Issue 190) ?ED 2004年05月21日: Editors to update part 3 to say that for SOAP Response MEPs the URI will be generated following the HTTP binding rules for generating a URI (for GET). (Issue 61) ?ED 2004年05月21日: Editors to update soap binding default rules to allow use of MTOM. (Issue 184) DONE [.2] 2004年05月21日: Amy to provide wording to go into spec to say that our bindings only support the identified MEPs but others can be handled if appropriate rules are defined elsewhere. (Issue 155) ?ED 2004年05月27日: Editors to add http:faultSerialization attribute. PENDING 2004年05月27日: DaveO will write up better description of this issue (189). PENDING 2004年06月10日: Jacek to review XMLP specs. ?ED 2004年06月10日: Editors should correct issues 208, 213, 215, come back to WG if there are any questions. [.1] http://www.w3.org/2002/ws/desc/#actions [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0079.html [.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0150.html --------------------------------------------------------------------- 4. Administrivia a. - August 2-4 (London) Logistics [.1], registration [.2]. - September 14-16 (Toronto) [.3] - November (West Coast) volunteers needed Volunteers to host nov F2F please make yourself known. b. WSDL 2.0 Last Call game plan [.5] - 2 hour telcons for next two weeks. Sorry about Canada Day... DBooth: If we slip more than 3 months we need to go to the AC to get reapproval. DBooth and jmarsh: we can't slip. [.1] http://www.w3.org/2002/ws/desc/4/04-08-f2f.htm [.2] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0064.html [.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004May/0000.html [.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html [.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0108.html ------------------------------------------------------------------ 5. Task Force Status. a. Media type description - 1st Working Draft Published [.1] b. MTOM/XOP - Last Call Published [.2] c. QA & Testing - Suggested QA plan [.3] - More details from Arthur [.4] - Interop bake-off d. Schema versioning - Waiting to hear back from Schema on my draft "charter." - Henry's validate-twice write-up [.5] [.1] http://www.w3.org/TR/2004/WD-xml-media-types-20040608/ [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0052.html [.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0029/QA_Oper ational_Checklist.htm [.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html [.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html ------------------------------------------------------------------ 6. New Issues. Issues list [.1]. - Cross-binding HTTP features (Asir) [.2] Asir raised issue on cross-binding of HTTP features. Discussion of whether this is editorial as daveO suggested. Marsh will add this as an editorial issue, for tracking it's quick dispatch. - Mark N's comments [.3] [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0080.html [.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0138.html ------------------------------------------------------------------ 7. Issues management [.1]. The following issues [.2] need a champion to put forward a proposal: 158 ? Part 3 Design Setting HTTP headers in the HTTP binding issue 158 - Setting HTTP headers in the HTTP binding <pauld> http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html markN: i'll look into 158 change: glen and daveO to cover 158 168 ? Part 1 Design Which operation issue 168 - dbooth to champion dbooth: 168 as it stands can be closed quickly but there is a follow-up issue 197 ? Part 1 Design Don't override interface feature requiredness in binding issue 197 - Don't override interface feature requiredness in binding glen: i am interested in the issue but i need to re-read it alewis: i was part of this discussion and i can champion it jmarsh: alewis gets an AI to propose write-up language to resolve 197 ACTION: alewis to champion 197 210 ? Part 1 Design Refine equivalence algorithm issue 210 - Refine equivalence algorithm markN: i could come up with a proposal but i don't know what the intent of the WG is ACTION: markN to put together strawman for 210 211 ? Part 1 Design Omit interface message in binding? issue 211 - Omit interface message in binding? jmarsh: this sounds like an editorial issue ACTION: markN to identify where clarification is needed for 211 218 Paul? Part 1 Design Justify interface faults. issue 218 - Justify interface faults ACTION: PaulD to propose text for part 1 to cover 218 [.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0109.html [.2] http://www.w3.org/2002/ws/desc/2/06/issues.html ------------------------------------------------------------------ 8. XML 1.1 issues - Issue 174: Tie WSDL conformance to XML conformance? [.1] - Issue 175: Is it valid for a XML 1.1 document to import or include a XML 1.0 document (and vice versa)? [.2] - Issue 176: Can a WSDL 2.0 XML 1.1 document contain (or reference), a XML Schema 1.0 type description? [.3] - Issue 177: Normative dependence on XML Schema 1.0 precludes XML 1.1 [.4] - Proposed resolutions [.5] [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x174 [.2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x175 [.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x176 [.4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x177 [.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0049.html issue 174 - jmarsh sent a proposal and got +1s jmarsh: <summary of proposal> dbooth: schema wg looked at it, there were people in favor and some objections. in terms of schedule we can't depend on their resolution. dbooth: michael (from schema) did a write-up with several approaches, one of which we could use as an alternative to defining our own type <dbooth> MSM's proposal: http://lists.w3.org/Archives/Member/w3c-ws-cg/2004Jun/0005.html [Plan B: forward motion only on XML (B 1) Add the following note after the normative reference to XML 1.0: At the time of publication, the version of XML named above was current. All standards and technical specifications, however, are subject to revision, and conforming processors are allowed to support more recent versions of XML in addition to the version mentioned here. In implementing this version of XML Schema, all conforming processors[*] MUST support XML 1.0. They MAY also support XML 1.1 and/or other later versions of the XML specification. If a conforming processor supports a later version of XML as well as XML 1.0, then it SHOULD normally allow the user to control which version is actually used; in particular, it is desirable that a user be able to request that a document be required to conform to XML 1.0, or to XML 1.1 or a later version, or to specify that any version of XML is acceptable. asir: why not wait for resolution in schema jmarsh: we don't have much time... jmarsh: we could do something for our last call but note that it is subject to revision based on what happens in schema asir: we can ask schema WG to solve this as fast as possible jmarsh: would rather not have a dependency for our last call on this jacek: to speed things up we could accept jmarsh's resolution and say something like "this is not very important from process point of view and this can change later in the process. we chose to move forward without resolving this fully" clarification - jacek meant any proposal really jmarsh: i can write up a more detailed proposal to have our string and name point to xml 1.1 rather than xml 1.0 dbooth: would this include datatype definition? jmarsh: yes ACTION: jmarsh to draft proposal to make wsdl strings refere to xml 1.1 and clarifying note umit: i am afraid that we are requiring people to be xml 1.1 compliant while people use xml 1.0 processors jmarsh: there is no dependency on parsing xml, we are based on the infoset (in conformance section) jamrsh: i don't believe my proposal requires an xml 1.1 compliant processor umit: ok, i'll make sure this is the case when you send your proposal asir: jmarsh will you define QName and other related types? jmarsh: yes. the types that we used that changed are NCName, QName, anyURI and token issue 174, 175 and 176: jmarsh proposed to close them w/ no action jmarsh: any objection to closing these 3? (clarification) action 5 above (for jmarsh) relates to 177, not 174 <Marsh> RESOLUTION: Issues 174, 175, 176 closed ------------------------------------------------------------------ 9. Issue 212: Explain using bindings across all operations [.1] - Mark's proposal [.2] [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x212 [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0062.html markN: (explaining issue 212) noticed there is no easy way to apply same info to all operations in a binding markN: the propoasl is that if there is no ref attribute the binding info applies to all operations tomj: i like the spirit but i am wondering what we have per operation that we did not roll up to the binding Glen: e.g. you might have operation specific binding features that you can turn on and off roberto: this proposal only covers operations. why not have a similar mechanism for faults? jmarsh: let's send this proposal back to mailing list to augment it with faults support dbooth: can we have a single consistent mechanism for doing this kind of things <Prasad scribes} ACTION: Mark to make a proposal for issue 212 on the list ACTION: Editor action to check that multiple style values are allowed. ------------------------------------------------------------------ 10. Issue 216: RPC and XML Schema not orthogonal [.1] - Mark's proposal [.2] [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x216 [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0064.html Mark: provides a recap of the issue. Definition of the RPC style implies that it can only be used on messages described by XML Schema. That seems to be an unnecessary constraint. The proposal is a modification of the language to allow any language that results in the same structure can be used with the RPC style. Umit: Your proposal remove the MUST adhere to the constraints below and made it "follow the rules". If that is the case I will be objecting to the proposal. I would be happy to take it to the list. Mark: Sure. Jonathan: If the wording is editorial, I would be happy to resolve issue here. Mark: Umit wants RFC 2119 level MUST added back Jonathan: Any objection to closing the issue with the normative MUST adhere to the constraints added (back), as a friendly amendment? <none> Jonathan: Consensus to close issue 216 accepting Mark's proposal with a normative MUST added. RESOLUTION: Issue 216 closed. ACTION: Editors to adopt Mark's proposal for 216, but reword using MUST. ------------------------------------------------------------------ 11. Issue 217: Syntax for multiple styles [.1] - Mark's plea at [.2] - No new information presented, issue will be closed by chair. Allow for minority objection write-ups if necessary. [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x217 [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0059.html Jonathan: Asked for new info why an attribute based extensibility is better? We have gone through this before (issue 98). I propose we Close this issue with no action. We don't have any new information. Mark: No negative comments on the issue on the list. Jonathan: There was support for this proposal before but, majority felt they prefer the style attribute in WSDL namespace. That was the consensus we reached. Mark: Ok Jonathan: Issue 217 closed. Jonathan: Checks with Sanjiva if this got reflected in the spec. ACTION: Editor action to check that multiple style values are allowed. ------------------------------------------------------------------ 12. Issue 221: Identify components by URI [.1] - Jonathan's proposes closing with no action. [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x221 Mark: I am willing to withdraw the issue Jonathan: I am also proposing we close with no action Jonathan: Quick summary of the issue. Why are components identified by a QName instead of a URI. TomJ: Are you talking of Operation, Port, Interface that kinda stuff? Jonathan: Yes, each component has an NCName and a namespace associated with it. When you refer to them from other components, you use the QName. Changing all QName refs to URI refs that is implied by this proposal is a major change at this point. TomJ: Also impacts the usability in a negative way. Jonathan: Any last comments before this issue gets closed? DaveO: We also do have the fact that these components can be identified by URIs. Jonathan: Yes, we provide a mapping. Sanjiva: We provide that mechanism. Jonathan: We don't use the mechanism internally but someone else can. RESOLUTION: Issue 221 is closed. ------------------------------------------------------------------ 13. Issue 222: Name[space] for the intended semantics [.1] - Mark's proposal is in the issues list [.1] [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x222 Mark: Proposal change in section 2.1.1: "an unambiguous name for the intended semantics of the components." -> "an unambiguous name *space* for the ..." DBooth: I wrote that sentence. I did mean *name* rather than namespace. The intent is that, the targetNamespace URI acts as an unambiguous name for intended semantics of the components as a whole, rather than individual things. Mark: If added 'as a whole' I would have understood it. DBooth: O.k. Lets add that or collection of components Jonathan: So resolutions to change it from "an unambiguous name for the intended semantics of the components." to "an unambiguous name for the intended semantics of the *collection of * components."? DBooth: Yes. Jonathan: Editorial. Any objections? <none> RESOLUTION: Issue 222 resolved as above ACTION: Editors to incorporate editorial fix addressing issue 222. ------------------------------------------------------------------ 14. Component model issues - Issue 223: Import/include processing model [.1] - Issue 224: Formalize component model [.2] - Mark's proposal [.3, .4] [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x223 [.2] http://www.w3.org/2002/ws/desc/2/06/issues.html#x224 [.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0085.html [.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0094.html Jonathan: Considering these together as the proposals came together. Mark: This is just an expansion of the introductory text to section 2 to talk about what the component model is and how it is structured. Also add a small note regarding the notation of the {} syntax. It would be nice to talk about how new properties can be introduced to the spec. Jonathan: Basically changes that improve the readability of the spec rather than any features of the WSDL language. Mark: There is no guidance on how the properties can be namespaced for extensibility. Jonathan: The infoset does not namespace properties. Those names are namespaced to the specification Mark: If we add stuff to Infoset, we can not call the resulting structure an Infoset. We have to call it something else. Jonathan: For instance XInclude adds a language property to the infoset Mark: May be this is a separate issue for XML Core then Jonathan: Is it not sufficient to identify a property uniquely, by the name of the property and the spec that defines the property? The names of the properties don't appear in the syntax. They are referred to by other specifications. Kind of like a QName reference. Is it not sufficient? Mark: It is a good specification to be precise about it. Jonathan: So, what should the other specifications do? Mark: I can come up with a proposal for consideration separately ACTION: Mark come up with a proposal for extension property namespacing. Roberto: Schema itself does not do this for the PSVI. Also for the schema components it does not introduce namespaces for the property names. Jonathan: Going back to the original issues. Any objections to accepting Mark's proposals for 223 and 224 Roberto: In the proposed text do you mean components are "collections of named properties" rather than "named collection of properties"? Mark: Components have names Roberto: You mean named as in the kind of the component Mark: Would you prefer "type' there? Roberto: Yeah, it can be editorial though Jonathan: Lets get this in the resolution so that editors have it. So, friendly amendment to use "typed components" rather than "named components". Any other comments? <none> Jonathan: Consensus to close 223 and 224 with editorial change proposed. ACTION: Editors to incorporate proposed resolution for 223 and 224. ------------------------------------------------------------------ 15. Issue 207: How to mark which elements to optimize [.1] - See thread starting at [.2] - Jonathan's proposal based on last week's straw polls [.3] - Related issue on F&P? [.4] [.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x207 [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0020.html [.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html [.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0042.html Jonathan: Proposal at: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0139.html. Proposal was to ask to XMLP WG to add text to the description in MTOM that talks of how to choose things to be optimized. Essentially to have the word MAY in there and a reference to expected media-types schema annotation. Say something like, implementations may rely on information in a description such as presence of a value xmlmime:expectedMediaType schema annotation and reference to the specification. Jonathan: Umit, are you ok with this proposal? Umit: Yes, the more declarative power we give the better Jonathan: You prefer a SHOULD than a MAY or a MUST? Umit: Even if we do have a MUST, we have to describe how to do it. Somebody has to provide details on how to utilize that information. If XMLP is going to do further work on MTOM that is better but, I am not sure. Umit: If there is are options to serialize oneway or other, some kind kind of capability to specify that I am expecting to serialize this kind of mediatypes as attachments all the time. Jonathan: Question is, whether that policy needs to be in WSDL Umit: As a feature or extension properties that specify expecting to serialize this kind of mediatypes as attachments all the time. Jacek: From XOP/MTOM point of view a SOAP node does not know that something was serialized as an attachment. Before the SOAP node processes a message, all attachments are virtually in the envelope. So, wondering if we can allow parties requiring stuff to be in attachments? From SOAP POV this is not wanted. So I agree this is really an optimization and once we start using MUST it stops being that. Jonathan: Lets see if we can go back and see if my proposal is acceptable enough for us to move on here. DBooth: If I understood Umit's concern, it can be accomplished with properties of a feature outside of the WSDL. Jonathan: XMLP WG would be a better place for defining that feature or properties. Umit: That was the question I had. If the XMLP WG is going to take something like on? Mark: Probably not. Umit: Somebody is going to solve this problem oneway or other. The problem is not going to go away. My concern is who is going to resolve it. Jonathan: Can we try and move the agenda fwd. Are there objections to asking XMLP WG to handle this? I proposed some words and a place in the spec where they might do that. <no objections> Jonathan: Proposal is accepted and Issue 207 is closed. ACTION: Marsh to forward Issue 207 proposal to XMLP WG. Jonathan: A Q about what required means on MTOM feature. If we need to put something in our spec to make it clear. DBooth: I wrote up an explanation on this. Some text could be put in the processor conformance section. Section 8.3 .... Jonathan: Is this non-controversial or need to raise a separate issue? DBooth: Only Ugo had a push back: Ugo: The push back was on which pov is the interface described from client or service. Jonathan: We discussed this extensively in the past. Ugo: I don't want to revisit the decision Jonathan: Ack'ing we can't do anything about that, is the proposed change acceptable to all? <no objections> ACTION: Editors to incorporate David Booth's clarification in section 8.3 This is also closed. Reached end of proposed Agenda. Anything else? Meeting Adjourned. ---------------------------------------------------------------- Summary of New Action Items: ACTION: alewis to champion 197 ACTION: markN to put together strawman for 210 ACTION: markN to identify where clarification is needed for 211 ACTION: PaulD to propose text for part 1 to cover 218 ACTION: jmarsh to draft proposal to make wsdl strings refere to xml 1.1 and clarifying note ACTION: Editor action to check that multiple style values are allowed. ACTION: Mark to make a proposal for issue 212 on the list ACTION: Editors to adopt Mark's proposal for 216, but reword using MUST. ACTION: Editors to incorporate editorial fix addressing issue 222. ACTION: Mark come up with a proposal for extension property namespacing. ACTION: Editors to incorporate proposed resolution for 223 and 224. ACTION: Marsh to forward Issue 207 proposal to XMLP WG. ACTION: Editors to incorporate David Booth's clarification in section 8.3
Received on Friday, 18 June 2004 20:01:08 UTC