- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: 2004年9月17日 17:43:07 -0700
- To: <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA204E9AB6D@RED-MSG-30.redmond.corp.microsoft.com>
Web Services Description F2F Wednesday 15 Sep 2004 See also: IRC log [http://www.w3.org/2004/09/15-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 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: Hugo Haas W3C Amelia Lewis TIBCO Asir Vedamuthu webMethods Scribe: Kevin Liu ------------------------------------------------------- Wednesday 15 September ------------------------------------------------------- 09:00 Last Call Issues Jonathan: Arthur has a call till 10am. agenda this morning changed. Continue last call issues. ------------------------------------------------------- Issue LC8: "Permit URI References instead of URIs " Roberto, Jim: text sounds like encoded [Roberto: http://www.w3.org/TR/xmlschema-2/#anyURI] Roberto referred to schema spec for uri reference DBooth: What do we need to do? Roberto: Use URI reference, use the same trick as schema. [Group looks at schema spec part 2 section 3.2.17 for anyURI] Bijan: Using qname is more consistent with rest of the spec? Glen: We had discussion in Palo Alto, was for it, but it was shut down. Roberto: Find out where we are using anyURI type. Jonathan: And figure out whether we should allow URI reference [more discussion on using frag id] [dbooth: http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#fragment] [dbooth: "As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent and regardless of the URI scheme."] DBooth, Roberto, Jonathan: what to do in the spec? [Frag id is stricken out before deferencing. It's up to applications decide how to deal with it. It's web arch issue, nothing specific to web services. Seems schema spec doesn't really say anything about anyURI's value space.] Jonathan: Gave three example URI's in white board (using e-acute vs. %-escaped value), all same except some contain spaces. Are they all the same value space? They are in different namespaces, so ns processor treat them differently. [hugo: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#uricompare] JM checking section 2.19 of part 1 for our definition of "comparing uris" Jonathan: If we add a frag id to the end of any of the uri, it's different. Don't see problem allowing frag in URI. We are OK with frag id. [Our def of uri need a little update to make it clear its actually uri reference.] Sanjiva: Why not define our own type? Jonathan: We should keep our type as close to schema as we can. ACTION: Editors update spec to clarify our using of anyURI is actually URI reference except targetNS RESOLUTION: LC8 closed by allowing # everywhere but targetNamespace. ------------------------------------------------------- Issue LC9: How does the Operation Name Mapping Requirement (Part 1, section 2.2.1.1) relate to interface inheritance? Glen: It's is not only for operation name, a general composition issue. Spec is not clear. We should add a paragraph to clarify this. DBooth: We already have a section for that. Glen: We need to answer Tim. [The answer to his first question is yes, but what to do with spec is not yet clear.] DBooth: Conformance section says something. (section 6.1) ACTION: Glen to respond to Tim saying yes to his first question, and pointing out sections 6. Jonathan: Answers to Tim's three questions: yes, n/a, no [dbooth: Operation name mapping requirement: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?cont ent-type=text/html;%20charset=utf-8#Interface_OperationName] [Disscusion on what to do with spec/] Glen: Section2.2.1.1 should be clarified. When you are using a service, it's got an interface, plus we should write it in English :) ACTION: Editors to clarify spec about operation name mapping requirements by moving paragraph preceeding section 2.2.1.1 and whole 2.2.1.1 to service section, and clear up the text. [Marsh: RESOLUTION: LC9 closed] [dbooth: The intent of this action is to associate the operation name mapping requirement with a *service* rather than an interface, so that the requirement only applies when an interface is actually used by a service.] [GlenD: Clarification on this action - "clear up the text" means 1) make clear that this applies to the interface component of the service component, and 2) indicate that any in-scope feature or extension (scoping of extensions left as an exercise to the author) may satisfy the ONR] [dbooth: This also means that the prose in list item 1 of "2.2.1.1 Operation Name Mapping Requirement" should NOT refer only to properties of the interface component, due to the F&P inheritance rules defined in e.g. "2.7.1.1 Feature Composition Model".] 11:00 Break ---------------------------------------- ------------------------------------------------------- 11:30 Zed notation update/QA issues Arthur is ready to present Zed notation Authur: will send material to www archival mail list . Basically we have an xml source, it can be translated naturally into math and generate test assertions. [dbooth: Arthur draws on the board: | | XSLT | XML ------------> HTML + CSS | \ | \ XSLT fuzz | \----------> Tex ---------> TypeErrors | \ | \ Tex | \-------> PDF ] Hugo, Roberto are concerned about browser sniffing Arthur: Shows chart for "rendering Z notation symbols in a web page" and demos how IE and Mozilla behave differently. [pauld: arthur's question to the mathml WG: http://lists.w3.org/Archives/Public/www-math/2004Sep/0009.html] Arthur: Demos how fuzz does type check and generates type errors and think fuzz type checking is quick and useful. Addreses hugo's concern on browser dependency for rendering the zed html. It will be problem for this generation is to be published in W3C if browser dependency issue can not be solved. [Now group discusses how this affect our spec assuming rendering problem can be fixed.] Arthur: Shows a generated normal version of wsdl2.0 spec and how interface component looks like. It has mathematical expression and English explanations. [alewis: url?] Sanjiva: Is concerned changing the spec after the last call. [it's ok to add to what's already published.] DBooth: This is not change to the semantic of the spec. Anish, Roberto: Aare concerned another additional presentation will add more confusion. [We already have component model, infoset model, now add zed notation?] dbooth: There are a few ways to go: 1. replace the current notation, 2. in addition to current notation... Paul: Find zed is easier to read than informal notation Sanjiva: Would like to see how the spec looks like with this new notation before we decide anything. [Now discuss possible impact on our publication schedule, may need another last call.] ACTION: Arthur to (re)write a subsection of the spec to show exactly how it looks with the Zed notation included before next telecon. ACTION: Hugo to investigate potential options for get the Zed version published in W3C web site. Tomj: Is concerned adding the z will make the spec more intimidating to read. Arthur: Will do this for QA anyway. Doesn't hurt to give it a try with the spec, we will see how people feel about it [Arthur: fyi, I posted the pdf of the XML Infoset Spec to http://lists.w3.org/Archives/Public/www-archive/2004Sep/0027.html] [Arthur: The Z notation for it, that is] [Arthur: Watch the www-archive - I posted it too but it hasn't shown up in the list yet.] ------------------------------------------------------- 12:45 Last Call issues [8] - (In issues list order, with Asir's last if possible) [8] http://www.w3.org/2002/ws/desc/4/lc-issues/ ------------------------------------------------------- Issue LC29a: It's unclear why default binding rules are not defined for fault components. Roberto: Useful info in binding fault is the code and subcode, there is no good value to provide as the default code and subcode. RESOLUTION: Add a rationale to the spec explaining there is no good default value for code and subcode. ACTION: Editors to add rationale to spec to explain why no default for binding fault is defined (no good default codes) Tomj: Suggests involving a tech writer to inspect the spec and fix similar issues. Hugo: You need to spend a lot of time to talk to a tech writer to get the job done. dbooth: Not sure the result will be significantly better. 13:00 Lunch ---------------------------------------- [dbooth: Scribe: Sanjiva] ------------------------------------------------------- 14:00 Individually read the Media Types Spec [tomj: http://tinyurl.com/6mvur] [sanjiva: we're spsed to be reading the media types spec now ..] [Marsh: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t ypes.html?rev=1.11] [dbooth: My talk on What's New in WSDL 2.0: http://www.w3.org/2004/Talks/0915-dbooth-wsdl/] 14:15 Additional media type comments Discussion about rationale for why the expectedMediaTypes attribute has restricted MIME parameters to the 'q' parameter. Sanjiva: Make it be consistent with what HTTP has unless we have good reason not to. Jonathan: Is this totally congruent to accept header, which would rationalize following HTTP rules? Tom: Doesn't think so [hugo: Minutes from last discussion: http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0054.html] [tomj: q is the only argument to the Accept header in section 14.1. The other arguments are extensibility, and we don't want or need the extensibility point here. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 So we are not limiting a list of things to just q, we are supporting all the specified options, but none of the "accept-extension" options.] Straw poll on whether to follow Accept: or whether to restrict the value to be only with the q parameter without the extension capability. Yes change to follow the http spec: 4 No leave it alone: 4 [Allen: abstain] [youenn: abstain also] take the vote again because of some flip-flopping... Yes: 6 No (status quo): 4 Objections to moving forward? Tom can't live with it. [pauld: Voted in order to loose the schema pattern ] Tom: Change the status quo to say "we allow the parameters defined by http ('q') but we don't allow the extensibility". Discussion about why we change the actual syntax from what's in HTTP. Sanjiva: Proposes to change the syntax to follow the http spec, drop the pattern facet from the schema, and say that the format of the string which follows the appropriate production in the HTTP RFC (except for not supporting extensions) Jonathan: Any objections to the above? Nope, we're all happy campers. ACTION: Media type editors to change the syntax to follow the http spec, drop the pattern facet from the schema, and say that the format of the string which follows the appropriate production in the HTTP RFC (except for not supporting extensions). Tom: The media type document doesn't seem to explain how this actually fits together .. DaveO: Write a primer for the media types spec? Tom: What about an overview section? Words like "here's the problem we're trying to solve, you put this stuff in the schema, then at runtime this happens and this is how it works" Consensus to add some more text in the introduction. ACTION: Tom and Anish to figure out the right words. Jonathan: Status section of the doc has "Second Public Working Draft" incorrect capitalization and too many words in the link. The status section is going to change anyway .. so above comment will get fixed automatically. Jonathan: 2nd bullet of requirements has redundancy in the last sentence: combine with previous occurrence. ACTION: Media Type editor to remove last sentence of 2nd bullet, combine with previous occurrence (remove redundancy). Jonathan: Section (2) refers to requirements by number when the reqs are an ULIST. Oops. ACTION: Media Type editor to make requirements an OLIST. Jonathan: Section 3 defines a binary EII as defining additional infoset props: These are not additional infoset props.. they are more constraints on current ones. Glen: Offers wording: "A binary EII is an EII defined as follows ...." ACTION: Media Type editor to clarify binary EII term, a la "a binary EII is an EII defined as follows" (More discussion about the document wording .. low level editorial type stuff.) Consensus to change examples to have one example which uses the full syntax instead of the authoring convenience types. ACTION: Media Type editor to have at least one example which uses the full syntax instead of the convenience types. Jonathan: remove ":" from 2nd para of 3.1 after "both" Straw poll on whether to remove colon? Nahh, we will remove it ... ACTION: Media Type editor to remove colon from 2nd para of 3.1. Anish: Would like to add an example of a schema and an instance doc Sanjiva: Appendix for schema definition: use "xmlmime" as the namespace prefix instead of "tns". Jonathan formally appoints Anish as editor of the spec from the wsdl wg too. He is already the editor from the xmlp group. He accepts it with a lot of worry about the additional work thereby created. Jonathan: Next steps: update the document, declare as WSDL LC and ask our dual personality editor to take it to XMLP to agree to LC status. If they agree the doc goes to LC and thence to a Note. ------------------------------------------------------- 15:00 Last Call issues (cont.) Issue LC29b Skipped till glen is back. Issue 29c Hugo: There is not resonable default for HTTP binding? Jonathan: Do exactly what we did for the previous issue (LC29a)? [hugo: It could be 400 or 500 depending on whether it is a client or service error.] ACTION: Editors to record same solution for Issue 29C as the resolution for why faults are not given a default binding discussion (again) whether that was the right decision ... Roberto: Suggests that we could just always use 500 as the status code because app level faults (those that are described in WSDL) fault because of app problems on the server: meaning 500 RESOLUTION: We will resolve this issue as before (no default for WSDL faults). ACTION: Editors to implement a fix for LC29c similar to the fix for LC29a. Roberto has raised a LC issue against us whether to allow setting the "reason phrase" for HTTP 500/400 etc. responses. ------------------------------------------------------- Issue 29b: Glen says Mark got it wrong - Glen will send an email explaining to Mark ... ACTION: Glen to send email to Mark ACTION: Glen to write an ACTION item to implement this ACTION item. [Marsh: RESOLUTION: LC29b closed, no action.] ------------------------------------------------------- Issue 29d Skip until DaveO returns ------------------------------------------------------- Issue 29e: The spec already says what happens if element is not there. We will clarify that nil-valued elems will result in the empty string. Discussion about how our current binding rules (which says that if the element is missing then its a fault) doesn't support the case of elements defined with minOccurs=0 [pauld: An area we see lots of implementations issues is with combinations of minOccurs=0 and nillable=true] Jonathan: For the case of URI construction, it seems to make sense to say nil values (instance data that has xsi:nil=true on it) result in the empty string being created [pauld: Schema spec has been open to interpretation here: http://www.w3.org/TR/xmlschema-1/#cElement_Declarations] Lots of discussion about whether we are being schema-correct Straw poll option1: nils are treated as empty strings for purpose of URI construction (including param replacemetn) option2: outlaw nillable elements and hang them if they appear in schemas that are going to be used in http bindings no vote taken .. more discussion happenin' Proposed compromise: instead of disallowing nillable types, we say that its an error for instance documents to have elements with xsi:nil=true [Roberto: in the first bullet point of 3.8.1.1] Any objection for this compromise? nope; accepted RESOLUTION: It is an error for instance documents to have elements with xsi:nil=true. ACTION: Editors to add as 1st bullet of 3.8.1.1 that it is an error for instance documents to have elements with xsi:nil=true. Tom: Proposes the same solution for 3.8.1.2 Roberto: Suggests that for automatically dropped parameters its better to silently omit it .. Tom convinced Roberto that its better to be an error because there's a diff between missing values and minoccurs=0 cases [Roberto: promptly changed his mind since there is loss of information in this case] Consensus to make it an error to have nillable values when trying to auto generate parameters [Roberto: "uncited non-nil, non-list, possibly empty single values"] [tomj: Also change bullet items to be "Uncited elements with single values (including empty values, but not nil)..."] RESOULTION: It is an error to have nil values when trying to auto-generate parameters. ACTION: Editors to change first bullet of section 3.8.1.1. to say "Uncited non-nil elements with a possibly empty single value are serialized ..." Close 29e with the above changes. ------------------------------------------------------- Issue 29f Same resolution as before - nil values cause errors RESOLUTION: close 29f with the same resolution as 29e (add bullet to 3.8.3) ACTION: Jonathan to ask XForms folks to review WSDL. ------------------------------------------------------- Issue 29g comment 1: deal with forward reference from 3.8 (ser formats) to 3.9 (styles). Classified as editorial. comment 2 of 29g: we don't see a need to have a default style ACTION: Jonathan to split 29g to two issues: first one to be tagged editorial, 2nd (29h) to be closed as no need to do it. RESOLUTION: 29h closed - no need. ------------------------------------------------------- Book-keeping of issues list Proposal: mark 32, 34a, 35, 36, 39 and 40 as editorial and refer to editors. ACTION: Editors to implement editorial issues 29g, 32, 34a, 35, 36, 39 and 40 or come back to the WG with questions. [tomj: done for the day!] 17:00 Adjourn
Received on Saturday, 18 September 2004 00:43:09 UTC