- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: 2004年9月17日 17:42:12 -0700
- To: <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA204E9AB6B@RED-MSG-30.redmond.corp.microsoft.com>
Web Services Description F2F Tuesday 14 Sep 2004 See also: IRC log [http://www.w3.org/2004/09/14-ws-desc-irc] Attendees: David Booth W3C Helen Chen Agfa-Gevaert N. V. Roberto Chinnici Sun Microsystems Glen Daniels Sonic Software Paul Downey British Telecommunications Hugo Haas W3C Hao He Thomsona Tom Jordahl Macromedia Anish Karmarkar Oracle Kevin Canyang Liu SAP Jonathan Marsh Chair (Microsoft) David Orchard BEA Systems Bijan Parsia University of Maryland MIND Lab Arthur Ryman IBM Sanjiva Weerawarana IBM Phone: Allen Brookes Rogue Wave Software Youenn Fablet Canon Jean-Jacques Moreau Canon Regrets: Amelia Lewis TIBCO Asir Vedamuthu webMethods Logistics [1]. [1] http://www.w3.org/2002/ws/desc/4/04-09-f2f.htm -------------------------------------------------------- Tuesday 14 September -------------------------------------------------------- 09:00 Introductions and logistics - Assignment of scribes Roberto Chinnici, Sanjiva Weerawarana, Kevin Canyang Liu, Tom Jordahl, Prasad Yendluri, Paul Downey, Hugo Haas, David Booth Scribes: Roberto, David, Kevin, Sanjiva, Paul, Tom <Roberto> Scribe: Roberto - Agenda bashing Agenda bashing ongoing. Discussion on schedule. Work on last call issues until November. Then revisit the issues for which we got minority opinions. Then go to CR. -------------------------------------------------------- 09:05 Spec status overview: Media Type Description Note [2] - Finalize plan to issue as Last Call [2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t ypes.html?content-type=text/html;%20charset=utf-8 Anish: One issue was not incorporated, namely the q parameter. That's issue 245 <anish> http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0023.html Jonathan: There's also a thread on 252 started by Umit. RESOLUTION: consensus not to reopen 252 based on Umit's mail. Jonathan: New issue: http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0016.html Anish: We say what @contentType means, but that does not provide much value to applications. Applications are free to ignore it. Tools cannot use the expected media type value and generate special code. Proposal is to remove the second statement "the annotation should be considered only as a hint" RESOLUTION: Consensus to remove sentence "the annotation should be considered only as a hint." Jonathan: New issue: optionality of contentType attribute http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0019.html Glen: Issue says "if there is optionality in the description, we should mandate that at runtime the content type is specified" Sanjiva: It's fine as it is, the spec says that the two values should be consistent. Anish: Optionality wasn't really discussed by this group until now. Tom: The two attributes are linked, so we should list the rules. Sanjiva: @contentType wins, it tells you what the data is. The spec says that, the value of @contentType must be in the range listed in the description. Anish: Analogy between expectedMediaType and HTTP Accept header. Hao: Service providers and consumers have different capabilities; do we address that? Sanjiva: We don't. Tom: The specification should address these three cases. Glen: Lack of media type (or use of a wildcard) in the schema says that there needs to be some other way of figuring out what the actual data type is. Jonathan: Do we need to require that implementations signal the same errors? Tom: Proposes to require contentType when expectedMediaType has a wildcard. Jonathan: This would force a messaging stack to reject all descriptions that use expectedMediaType if it doesn't support contentType. Concern is that @expectedMediaType is very useful in many contexts, so we shouldn't tie it to Web services. Example: XML Query. <anish> How about saying that if the expectedMediaType contains a wild card or a list then the instance document SHOULD contain some way for the receiver to figure out the media type of the binary data. contentType attribute being one such mechanism. Kevin: The schema author could make @contentType required. <dbooth> Proposal on the table: "When expectedMediaType is used and has a wild card or list, you SHOULD write your message schema to require a contentType." RESOLUTION: Consensus on adding "When expectedMediaType is used and has a wild card or list, you SHOULD write your message schema to require a contentType." DBooth: Who should register the media types? Jonathan: The WG, but no specific person. <dbooth> Info on how to register the media type: http://www.w3.org/2002/06/registering-mediatype Jonathan: Call for volunteers to manage the registration of our media type. Arthur: Which extension should we use? .wsdl? .wsdl20? [.wsdl seemed to get consensus] DBooth volunteers. <anish> html media type rfc -- http://www.ietf.org/rfc/rfc2854.txt <anish> xop media-type -- http://w3c.org/TR/2004/CR-xop10-20040826/#identifying_xop_documents <sanjiva> +1 for .wsd and .wsdl because our WG is called WS-D too :( Jonathan: No other media type issues. Do the edits tonight, then have everybody review the document tomorrow and discuss any new issues on Thursday. 10:40 Break ---------------------------------------- -------------------------------------------------------- 11:00 Spec status overview: Primer [3] - Finalize plan to issue as 1st Working Draft [3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.ht ml DBooth going over the primer Sanjiva: Primer shouldn't use "WSD" [Proposal to use "DESCRIPTION" instead.] RESOLUTION: DBooth to change "WSD" to "WSDL Document" throughout DBooth: Sections up to 3.1 should be ready to go. [discussion on "WSD" and its use in the architecture document.] Arthur: The primer should be completely self-contained. Roberto: Web services architecture document is hard to understand without having some understanding of WSDL. DBooth: Disagrees, wsarch document is quite readable. Anish: Remove the architecture document reference and just have the glossary. Sanjiva: Already section 1.4.5 of the wsarch document uses complex terms we don't use in our spec. XML Schema primer starts from a simple example and grows it, it doesn't start with a glossary. DBooth: It's important to put WSDL in context. Our intent for the WSDL primer is to do as the schema one does. Kevin: Instead of listing the wsarch document as prerequisite for the whole primer, we could list it in the section that contains the diagram. DaveO: The interactions described in the diagram must be understood to understand the place that WSDL occupies in the system. The primer should not re-create a description of the Architecture. Arthur: A primer is for a different kind of audience, so you want "progressive disclosure". <dorchard> The first paragraph of primer introduction says "The text assumes that you have a basic understanding of XML 1.0 and XML-Namespaces." <dorchard> schema primer DBooth: Prerequisites are only for information they should already know before they can start reading this document. Glen: Strawpoll DBooth: Proposal to have more specific references for the concepts you need to know. <dorchard> "RTFA" :-) RESOLUTION: Accepted the proposal from DBooth to have more specific References for the concepts you need to know. PaulD: Primer should be an introduction to the WSDL spec itself, not to the whole industry. Jonathan: Are the editors getting sufficiently clear directions? Dbooth: Would lie down on the road about being inconsistent with the architecture document. <kliu> +1 to Dbooth Sanjiva: In the spec we use "web service", not "provider agent" DaveO: Isn't that because the architecture document has a wider scope? DBooth: The primer must provide a wider context than what the spec does Roberto: Proposal #1: CLIENT <-- WSDL --> WEB SERVICE Dbooth: We could have Client (Requester Agent), etc Tom: Text can make references to requester agents and provider agents and point to the note. Strawpoll: (1) use simplest terminology, (2) keep it consistent with wsarch document (1) is client / WSDL document / web service (2) is status quo (2) means be as consistent as possible with the wsarch terminology <youenn> +1 for 1 <Allen> +1 for 1 for me too for (1): 6 for (2): 7 Sanjiva: Will lie down on the road on this. RESOLUTION: Diagram revised to add "client" and "web service" in parentheses Tom: Objects to the use of requester agent and provider agent throughout. Jonathan: Formal vote on the same question of the strawpoll 1: IBM, Sun, Macromedia, Canon, Roguewave 2: BEA, Sonic, Agfa, W3C, SAP, Thomson, Oracle Abstain: British Telecom, UMD Results: 1 - 5, 2 - 7 Option 2 wins (i.e., be consistent with the WS Arch document, which uses "Requester Agent" and "Provider Agent") 12:15 Lunch ---------------------------------------- <dbooth> Scribe: DBooth 13:15 Primer (cont.) Roberto: Re: Diagram 2-1, please change "Web" to "Network". DBooth: Ok. RESOLUTION: Change "Web" to "Network" in diagram 2-1. GlenD: Too much stuff up front before the first example. Want to give a "hello world" example and then build on it. DBooth: I agree. We need to reduce the Section 2 stuff a bit. JMarsh: For example, section 3.3 has an explanation of all the MEPs. Does it need them all? DBooth: No. I haven't reworked that part yet. JMarsh: Let's focus on up through section 5 for the first WD, and leave the Advanced Topics for the moment. Arthur: Primer should cover simple case and things that people often get wrong. Implementers often get inline schemas wrong. Sanjiva: That doesn't belong in the Primer if it's an obscure case. JMarsh: Maybe we should put an example of schemaLocation in the spec. DBooth: Which Advanced Topics should move to the main body? Bijan: Extensibility should move. JMarsh: Import also. PaulD: Maybe we should have another document that lists examples with their rationales. JMarsh: Shouldn't our test suite catch that? Sanjiva: If someone wants to do the work, fine, but let's not add it as a WG deliverable. DBooth: How would this be different from the test suite? PaulD: Different audience. Test suite would be for implementers; I'm talking about examples for WSD authors. DBooth: Sounds like a prime area for training companies, books, etc. JMarsh: Test suite should be linked from our status section. GlenD: Take out the syntax summary. DBooth: Need to merge section 2 into section 1, because it really is intro material. -------------------------------------------------------- 14:00 Reusable Types for ContentType? [New issue raised by Kevin.] Kevin: Should we define reusable types for contentType? Anish: Two complex types, both are elements with contentType attributes. JMarsh: Complex type would define an element with a contentType attribute. Extend it by annotating the value of the attribute. Instead of defining these types, you could have an import statement. GlenD: This would be both an authoring convenience and tool help. Roberta: If the expectedMediaType then you SHOULD set contentType, but in this case you're specifying contentType first. GlenD: Optional would be useful for authoring convenience. Sanjiva: How about defining type for all MIME types? DBooth: I'm against authoring convenience. ;) I don't think the benefit is worth the cost. JMarsh: We could add these to our existing schema, to be available for convenience. RESOLUTION: Add two complex types to our XML MIME schema, one derived from base64 and one from hexbinary. [Discussion of whether to call the namespace prefix xmlmime: or mimexml: , because prefixes starting with "xml" are reserved. Preference is for xmlmime:] Type names will be base64Binary and hexBinary. -------------------------------------------------------- 14:30 Spec status overview: SOAP 1.1 binding - SOAP 11 Binding, first draft [4] - Modified Part 3 (aka, added soap version) [5] - Modified XML Schema for SOAP in WSDL 2.0 [6] - Collect issues - Finalize plan to review [4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-soap11-bi nding.html?content-type=text/html;%20charset=utf-8 [5] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/mod-wsdl20-bindi ngs.html?content-type=text/html;%20charset=utf-8 [6] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/mod-wsdl20-soap. xsd Nothing to say without Asir - skipped. 14:35 Spec status overview: RDF Mapping - Status update? First peek? Postponed till Thursday. 14:40 Last Call issues [7] - (In issues list order, with Asir's last if possible) [7] http://www.w3.org/2002/ws/desc/4/lc-issues/ Last Call Issues <tomj> Issue: http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5d -------------------------------------------------------- --- Issue LC5d --- RESOLVED: Accept DBooth's proposed change in http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0008.html ACTION: Editors to implement resolution to LC5d at http://lists.w3.org/Archives/Public/www-ws-desc/2004Sep/0008.html -------------------------------------------------------- --- Issue LC5f --- (Skipped pending Roberto's action item on it) -------------------------------------------------------- --- Issue LC5g --- Proposal to delete the word "agree". http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5g JMarsh: What if the processor conforms to the WSDL part but not to an extension? TomJ: A conformant processor MUST fail if it doesn't abide by the semantics of a required extension. I have 15 extensions in my WSD, and 5 are marked required. I MUST either conform to those extensions or fault. GlenD: A conformant WSDL processor can legitimately AGREE to abide by the mandatory extension even if it doesn't ACTUALLY abide by it, because it's the extension plug-in's fault -- not the WSDL processor's fault. <Jonathan> "a conformant WSDL processor MUST immediately cease processing (fault) if it doesn't agree to fully abide ...." RESOLVED: Accept the reviewer's proposal: "a conformant WSDL processor MUST immediately cease processing (fault) if it doesn't agree to fully abide ...." ACTION: Editors to implement resolution for LC5g as proposed. -------------------------------------------------------- --- Issue LC5h --- RESOLUTION: reclassify as Editorial. -------------------------------------------------------- --- Issue LC5i --- JMarsh: This says "MUST" in a Note section. TomJ: The reviewer is right that this Note is about the provider agent, whereas the section is about the requester agent. Bijan: There are two kinds of dealing with this optionality. One is that the provider agent can't send a message using the feature until it gets a signal from the requester agent. The other is that the provider agent could send it in an ignorable way. TomJ: This is about defining the semantics of optional extensions. We should move the gist of this to the section about optional extensions. GlenD: Issue: When an optional extension is in a WSD, and you're building a provider agent, you must implement the extension. DBooth: We need to say what is the meaning of an optional extension, i.e., that the service MUST support all optional extensions. TomJ: I proposed to move this Note into the section on extensions. JMarsh: We don't have a section on optional extensions. But the same material already appears in the section on Mandatory Extensions. RESOLVED: Delete the note from the conformance section (as redundant), and promote the material on optional extensions into its own section, and add "See section ___ for further explanantion". ACTION: Editors to implement resolution to LC5i. -------------------------------------------------------- --- Issue LC5j --- http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5j RESOLVED: Close LC5j as resolved by LC5i. -------------------------------------------------------- --- Issue LC5k --- http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5k Bijan: This is just advice for implementers. Dbooth: How about pulling this out into a Note and reworded as a suggestion? RESOLVED: Delete the text, because it is only advice to implementers. ACTION: Editors to implement resolution to LC5k. Hao: Why not just use xinclude instead of WSDL include? JMarsh: They are semantically different. (Discussion about whether xinclude must be supported.) JMarsh: Our spec starts with the infoset, so how the infoset is obtained is out of scope. (Further discussion about potential interop problems if we are silent about xinclude.) Arthur: Should we specify minimum concrete serialization to guarantee interop? JMarsh: WS-I Profile does that. ACTION: Arthur to submit proposal on conformance requirements for XML serialization (of WSDL and schema documents) -------------------------------------------------------- --- Issue LC5l --- http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5l RESOLVED: Leave the Note, but change "processors" to "conformant processors" (and link to the conformance section), and explain this to the reviewer. RESOLVED: Make the Note in 6.3 normative, and rephrase as "Extensibility elements SHOULD NOT alter the existing semantics in ways that are likely to confuse users." ACTION: Editors to implement resolution to LC5l. -------------------------------------------------------- --- Issue LC6a --- http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6a RESOLVED: Change {name} in F&P to {uri}. (I.e., accept reviewer's comment.) ACTION: Editors to implement resolution to LC6a. -------------------------------------------------------- --- Issue LC6b --- http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6b GlenD: The difference is necessary because it will allow schema processors to validate. It is a co-occurrance constraint. RESOLVED: Reject the reviewer's suggestion, explaining that an element Supports schema validation by allowing a co-constraint between 'value' and 'constraint'. -------------------------------------------------------- --- Issue LC6c --- http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6c RESOLVED: Reject the reviewer's suggestion, and explain that we were following XML Schema's convention and that it further clarifies that it is the location of a WSDL document. -------------------------------------------------------- --- Issue LC6d --- http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC6d (Discussion of how XPointer schemes work, and namespaces for them.) <Jonathan> #xmlns(mything,http://bijan.com/mything)mything:frag(xoinxoinxoinxoinxon ) <dorchard> http://www.w3.org/TR/xptr-xmlns/ JMarsh: Couldn't reuse our fragments on other media types. (Much discussion of Appendix C section C.3.) <Jonathan> #xmlns(xp,uri:1) xmlns(wsdl,http;//wsdl) xp:xpath(//wsdl:interface[@name='foo']]) interface(foo) JMarsh: Might want to serve a fragment like the line above as XML media type. As the XPath is validated, I don't know if the xpath part is on the component model. <sanjiva> The chair demonstrates his XPointer legacy and prowess. ;-) JMarsh: Two things to identify: either a WSDL component or an XML element. <sanjiva> Hey, soap's @role can indeed be dereferenced: <sanjiva> http://www.w3.org/2003/05/soap-envelope/role/next ACTION: JMarsh to take issue LC6d to XML Core WG RESOLVED: We should accept the reviewers point about making explicit that we're defining a new scheme. ACTION: Editors to make explicit that we're defining new XPointer Fragment schemes. (Discussion of whether to consolidate the 6 schemes into a single WSDL scheme.) The last part of this issue -- "the application/wsdl+xml MIME-type references this scheme as a possible xpointer scheme - i.e., I don't think a WSDL resource served as application/xml can be resolved using this XPointer scheme." -- is postponed pending JMarsh's action item to talk with XML Core. -------------------------------------------------------- --- Issues LC7, LC10, LC12, LC15 --- Editorial. ACTION: Editors to implement LC7, LC10, LC12, LC15 unless they find problems that require additional group attention. 17:00 Adjourn
Received on Saturday, 18 September 2004 00:42:45 UTC