- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 7 Nov 2003 15:17:48 -0800
- To: <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA201B62767@RED-MSG-30.redmond.corp.microsoft.com>
Web Service Description Group Minutes, FTF meeting 3-5 November 2003 Sunnyvale, hosted by Fujitsu. ------------------------------------------------------- Tuesday 4 November ------------------------------------------------------- Present: David Booth W3C Allen Brookes Rogue Wave Software Roberto Chinnici Sun Microsystems Glen Daniels Sonic Software Paul Downey British Telecommunications Youenn Fablet Canon Tom Jordahl Macromedia Jacek Kopecky Systinet Philippe Le H馮aret W3C Amelia Lewis (phone) TIBCO Kevin Canyang Liu SAP Lily Liu webMethods Jonathan Marsh Chair (Microsoft) Jeff Mischkinsky Oracle Dale Moberg Cyclone Commerce Jean-Jacques Moreau (phone) Canon Bijan Parsia University of Maryland MIND Lab Arthur Ryman (phone) IBM Jeffrey Schlimmer Microsoft Jerry Thrasher Lexmark Steve Tuecke Global Grid Forum William Vambenepe Hewlett-Packard Sanjiva Weerawarana IBM Umit Yalcinalp Oracle Observers: David Martin SWSI Scribe: Paul IRC: http://www.w3.org/2003/11/04-ws-desc-irc ------------------------------------------------------- 09:00 Pattern inference [6] (optional @pattern, optional @messageReference): - Tabled decision on optional @pattern to future telcon. - Tabled decision on optional @messageReference to a future telcon. - Sanjiva proposes dropping redundant {direction} property from the component model [7] [6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0172.html [7] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0210.html Marsh: Quick background of subject - Sanjiva to outline proposal, Amy & Jean-Jaques to reply Sanjiva: Status quo syntax for operations, user has to remember pattern uris (complicated), value for messageReference - not orthogonal, only not user settable Marsh: Two issues: could come up with better labels, and make it optional. [Marsh: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0344.html] Sanjiva: Rename input and output are redundant Roberto: So long as you understand the pattern Sanjiva: Outlines the proposed new rules to derive optional values [jjm: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0013.html] [alewis: Amy's alternative proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0017.html] jjm: Remembering uri not a problem, easy to remember - basically the same for many patterns. Paul: Why not have the name of the message in the pattern tags? Amy: Specifies single rule: one way messages can have a short-cut - only for unambiguous MEPs DBooth: jjm's if you do not know the MEP you would not know the direction of the messages being passed Tom: +1 to Amy's proposal Marsh: Amy's proposal has extensibility point for URI for a pattern .. Sanjiva's extension would be an error ? Sanjiva: Combine best of both: we should adopt Amy's proposal as his proposal builds on it. URI can override the default rule jjm: Why is important to keep the direction of the message ? JeffSch: Firewalls and other intermediaries Amy: May be better off using the words "input" and "output" rather than A, B, Request, Response, etc Sanjiva: "input" "output" seems natural now, but may seem strange in the future. DBooth: Name could be used as a heuristic, "inputXXXX" "outputYYYY" Sanjiva, JeffSch: some problems with jjm's proposal, element names can't be in the WSDL namespace DBooth: Let's decide on Amy's proposal [DBooth: Amy's proposal: Proposed syntactic changes: - Make interface/operation/(input|output|infault|outfault)/@messageReference optional (this was one of Sanjiva's proposals) - Introduce the following rule: When a pattern contains only one message in a given direction, then the messageReference attribute is optional. When a pattern contains more than one message in a given direction, then the messageReference attribute is required (to disambiguate which message is defined by the element). ] JeffSch: Let's come up with some text for this Marsh: straw poll [Straw poll: Make the messageReference optional if there is only one message in the MEP (Amy's Proposal) ] youenn: Use schema to validate rather than infer the valid patterns. I would like to study each pattern, write a schema extract and use it to validate each operation, default value, missing messages etc. Marsh: Is there enough value in writing schema extracts just to support WSDL validators ? [DBooth: DBooth's generalization of Amy's proposal: If the MEP has no more than one message in each direction, then the messageReference attribute for each message is optional, because it can be deduced from the pattern. ] [alewis: Agreed. That was what I intended to say. Actually, that's what I thought that I said.] Scribe: Clarification of wording ... Amy: DBooth has presented well my original intention. [DBooth: Generalization 2: If the MEP has only one message in a given direction, then the messageReference attribute for the message in that direction is optional, because it can be deduced from the pattern. ] [alewis: I can agree with that extension, though, because it makes sense to me, too.] Sanjiva: confusion reigns .. [alewis: Examples: 1 input: always does not require @messageReference 1 input, 1 output: always does not require @messageReference 2 inputs, 1 output: inputs *require* @messageReference. In my original proposal (as intended), output also required it. In the modified proposal, does not.] TomJ: Wants simple rules! Roberto: And what about faults ? DBooth: This doesn't address faults Amy: Would like to see the outcome of yesterday's discussion before covering faults in my proposal. Sanjiva, TomJ: use similar simple rule for fault. [DBooth: Fault wording: If the MEP permits only one fault in a given direction, then the messageReference attribute for the fault in that direction is optional, because it can be deduced from the pattern.] JeffSch: doesn't that bake-in FRM ? Sanjiva: this wording isn't enough [alewis: JeffSch: No, it doesn't bake FRM in. The fault wording counts the places where faults can occur, and allows WSDL authors to use the same shortcuts.] [DBooth: New wording: If the MEP (including its fault rule) permits only one fault in a given direction, then the messageReference attribute for the fault in that direction is optional, because it can be deduced from the pattern.] [alewis: FRM: fault replaces message. MTF: message triggers fault] Sanjiva: We're talking about deriving the inferend default value for messageReference. Roberto: I don't like it, there is an order requirement / significance. Sanjiva: XML has a document order concept Amy: You have to look at the child element, sounds unnecessary complex. URI isn't too difficult. jjm: +1 [Roberto: +1] [youenn: +1] Sanjiva: It's going to be an extra burden to someone used to writing WSDL 1.1 Amy: Pattern URI saves a child element traversal TomJ: It's not going to be that bad! Amy: It's syntactic sugar, tools won't care or have any significant burden Roberto: +1 to Amy youenn: XML default for this attribute [TomJ: So if the tools don't care, then we should do this because it is for the human reader/writer. pauld: +1 to youenn Umit: syntactic sugar should be more explicit jjm: This makes WSDL more complex, the URI rules have to be learned, and extra burden to users pauld: +1 to jjm Sanjiva: These patterns are going to be very common and maybe written by hand, so should be as simple as possible. [alewis: I do not agree, and I *do* write all my WSDL by hand. And read other people's WSDL. And *really* *really* want to *always* see the nice @pattern uri, because it's unambiguous altogether.] Glen: I want something to happen here, and now! Straw poll: Should we make the pattern attribute optional in some fashion? 8 for, 10 against Marsh: Status quo reigns as for now .. Sanjiva: This issue is important to IBM. Marsh: Anything else on patterns? no, so take a break! [alewis: David: we probably need action items for someone to write up the @messageReference optionally. You had some good text for that, I thought.] [DBooth: Amy, good idea. Please steal my text. :) ] [JeffSch: FYI, I added the appropriate editorial for optional @messageReference.] ------------------------------------------------------- 10:30 Break 10:50 Features and Properties - Glen's Features and Properties musings [21] - Arthur's proposal to unify property URIs and QName URIs. [22] Alternatives include using property markup, or a QNamed attribute. - Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [23]. [21] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0144.html [22] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0047.html [23] http://tinyurl.com/mwuy#x2 Marsh: Inline schemas postponed (until tomorrow, if time), May cover header item in this discussion. Glen: Outlines his overview document. [Roberto: http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0144.html] Glen: New pattern from SOAP 1.2 not yet widely used but has great promise. WS-Reliable-Messaging as a worked example. Marsh: How do we evangelise this pattern in our spec? Glen: Properties can be set and used generically, or may be tailored to a given higher-level spec. Umit: How do we know how WSDL and an external spec are tied together ? Glen: It's the well known URI Umit: By referencing an external spec WSDL may no longer describe the messages exchanged. Glen: Dips his toe into headers discussion Umit: My question specifically was about how a feature/property would be able to "refer" to specific WSDL definitions. Sanjiva: Difficult to define F&P in this working group, would like to move this into an external policy framework. Marsh: soapAction ? Scribe: Glen and Sanjiva discuss how generic policy is .. JeffSch: Concerned about scope of this discussion Glen: Acknowledges richer policy frameworks may emerge in the future .. Roberto: May be other policy languages such as RDF, F&P is immature and maybe should be removed from the spec. Marsh: Maybe out of scope for this discussion. Dale: There is a requirement that F&P answers. Sanjiva: Open content ? Umit: Uniqueness on the wire was going to be resolved by F&P and now you are going to remove it ? JeffSch: Group agreed to do something about uniqueness, push-back on F&P is not related. other extensibility models exist. Philippe: Maybe remove them and add them in again later if required. Sanjiva: Concerned about wide impact F&P has on spec for something that may not get used. Bijan: As someone interested in layering on top of WSDL, extensibility is good, even if we don't have a concrete worked out use now youenn: Discusses Roberto's concerns. Features are abstract and not at the binding level. Roberto: SOAP 1.2 binding needs to express what SOAP 1.2 does. we need stronger requirements here. jacek: Postpone discussion until we can discuss policy (or whatever) Glen: Accept they're there now and move on. JeffM: Leave it in there. purpose is for users, not us. JeffSch: Microsoft may consider filing a minority opinion against F&P [Marsh and DBooth discuss where F&P would be described .. Primer ? ] Dale: Questions who would implement what and would these URIs be registered Marsh: W3C is moving away from central registries. Not clear which extensibility mechanism should be used when Philippe: It will be simpler to remove them now than later. Roberto: Still troubled that best (or only) use of F&P may be policy. what is the requirement for F&P ? Bijan: Questions Marsh about procedure, at-risk and last call .. JeffM: Let's just move on. Glen: Pen in hand. outlines another (non-policy) example of F&P - a notary service. Marsh: What more do we need in the spec to better describe F&P ? Arthur's proposal ? Sanjiva: Only use we have is for soapAction, so maybe a specific attribute better than generic mechanism. Marsh, Sanjiva: is Arthur's proposal still alive ? Arthur: I prefer not to discuss proposal until the F&P issue has been resolved. Glen, will you champion my proposal on my behalf. JeffM: Let's just move on. JeffSch: Would like to see the impact on the component model of a first class property versus open extensibility model. Yesterday we decided on a 1st class property for parameterOrder Glen: Here is a spec by which you can add things generically Sanjiva: hot food has arrived! Marsh: let's decide quickly! Umit: why are people against this proposal Glen: it's not clear to me Roberto: any elements question implementation of new WSDL propertySchema construct. This is a big step. soapAction doesn't justify this change. Glen: just because we only have one or two examples now, doesn't preclude others in the future Straw poll: adding propertySchema in lines of Arthur's spec 4 for, 4 against Marsh: Abstains carried the day. can we not do this ? satus quo ? Glen: Anyone want to lie in the road Marsh: Anyone object to dropping the proposal [silence] Marsh: soapAction *before* lunch [hubbub, near revolt. Chair is undeterred :-)] Sanjiva: Discusses syntax with Glen and JeffSch. TomJ: I like Sanjiva's proposal (from the list). JeffSch: Why is the WG obsessing on syntax ? Philippe: With F&P we have a way to achieve this. this is a syntactic short-cut [further discussion on impact on component model] Sanjiva: Let's vote! JeffSch: 3 things: syntax, component model and structure and description how component model speak about external spec, HTTP, SOAP, etc. third part requires parlence of external spec. Marsh: Do we care that we have two different component models for the same thing? Maybe a canonicalisation issue in the future to address. JeffSch: We have two parallel tracks at the moment. Glen: Mentions possibility of another proposal Umit: Is soapAction required ? Glen: No [working group have full-bladders and empty stomachs.] Marsh: Lets tackle soapAction before lunch! Straw poll: retain a non-generic way of representing soapAction ? for 10, against 2 Straw poll: keep operation (versus action) 1 for, 3 against Marsh: can we live with <wsoap:action uri="uri"> ? [consensus for yes, pizza smell in room!] Straw poll: URI in simple content or attribute ? [consensus for attribute] [stampede for lunch.] ------------------------------------------------------- 12:30 Lunch 13:30 Drop @headers - Proposal from Sanjiva [24] - Related questions from Youenn [25] [24] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0107.html [25] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0033.html Issue: should headers be dropped from interface? Reason: headers are part of binding. Youenn: appeal to an application data vs other data distinction Umit: Is a marker needed at abstract to indicate what is multiply realized in binding? Glen: Point is that multiple header treatments still expressible in binding. Youenn: Describes an image processing service with alternative parameterizations. In some way one binding appears to use a SOAP header to carry some image info or ref. Use case is maybe that we don't support partitioning app data in different parts of a binding. Sanjiva: Presumption has been not to support that partitioning, maybe we should Lily: Customers make use of headers for app functions Glen: Should we enforce app in soap body and metainformatin context in headers? Jeff: Not ours to set soap conventions. JeffM: Where does wsdl allow the distinction to be drawn? Glen: Contract on what and where data placed, not of course on dynamically selected values. JeffM: Wants the interface to include contract details. If f&p endangered and we trash headers aii in interface, then what is left? Sanjiva: Headers attribute inadequate to document some attempted protocol implementations. So drop them. Glen: The body is a big bag that bindings pull parts from. Big bag encourages bad non-modular design. So headers attributes and f&p support good modular design JeffM: In practice headers glommed on incrementally and ad hoc jacek: +1 Glen tom: Wakes up. Supports Sanjiva. Straw poll: Remove headers attribute from interface and headers property from the model 13 for 1 opposed, none lying down in road RESOLVED: Remove @headers. ISSUE: Should the body attribute be renamed since the contrast with headers is gone? [renaming fracas resumes] Poll on which names are acceptable: 15 ok with message 15 ok with element 5 ok with body 14 for data many mj 11 content Preference poll on winners: 8 favorite for message 8 favorite for element 1 favorite for data Runoff poll on winners: 10 for message 8 for element RESOLVED: rename @body to @message. [Issue can be reopened if name seems confusing.] ISSUE: Considering the details attribute in infault poll called for whether to rename details att. message 3 for details 10 for message RESOLVED: Rename @detail to @message ISSUE: is there a proposal for removing headers from the binding JeffSch: Wants to have binding headers declarable as the bare fallback support in wsdl 2.0 Glen: Insists that this approach is either useless (except for cookie case) or promotes bad design or both TomJ: Supports having binding header descriptions. [general remarks about how much, and in what detail, and by what means to declare in wsdl:definitions] poll to determine whether removing soap headers from binding many opposed 2 favor ACTION: Glen to write up his proposal and rationale on headers ISSUE: headerfault Umit: Sample apps use it in ws-i ------------------------------------------------------- 15:00 Break 15:30 Attributes [26] [26] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/att-0320/GetterSetterStyle.html ISSUE: Attributes Umit presentation, uri to come to document [Umit: the presentation is http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0038.html] [JeffSch: http://lists.w3.org/Archives/Public/public-ws-desc-state/2003Oct/0021.html] Jacekk: Propose to combine get set into one section TomJ: Driving force for feature has withdrawn request-- so? Sanjiva: One style uri confusing JacekK: No, point is one section in document, but one style might be OK too ACTION: Jacekk to make proposal on combining the get/set styles into one [Discussion took up the subject of Sanjiva's and Steve Grahams posts. ggf wanted first class treatment to meet objections against creating extensions to wsdl. Result, however, might not be adequate for their needs "obfuscated".] Sanjiva: Resource attributes don't have to be captured in WSDL for resource management goals. [However, this is not necessarily a consensus view in the GGF] Roberto: Service itself could have properties needing management. JeffM,Sanjiva: on stateless, stateful, resource behind service, also stevet. Marsh: Invite people to review and comment during last call on attribute support adequacy for grid. Sanjiva: Predicts IBM will not urge wsdl attributes as way to offer needed extensions for grid. Marsh: Removal of style and sections on attribute not motivated at this time. TomJ: Says that the effort has been undermined by withdrawal of key advocates. JeffM: ggf wish for us to provide this is critical factor on pulling section. [discussion of schedules, timelines impacting proposal to remove attribute style.] straw poll (informative only - no action planned): favor dropping 13 favor dropping and 5 against] [People who had supported effort summarize their rationales for changing their view.] Issue: Make @style a list of URIs? Marsh: Anyone volunteer to say how styles can be composed? [no one steps up.] [DBooth: To be clear, a nice thing about a style attribute is that it places no burden on implementors that don't care about it. A WSDL generate the doesn't care about it doesn't have to use that style, and a WSDL processor that doesn't care about it can alway safely ignore it. For this reason, the cost of adding a style attribute to our spec is minimal: only the spec-ese that is required to describe it. (And Sanjiva adds: Plus the additional burden placed on other sp] ------------------------------------------------------- 16:00 Updated definition of equivalence (Sanjiva) [remaining for today, http binding and updates on equivalence] Sanjiva: Substitute interface compatibility for equivalence of service. details to come. Glen: Does not think this should be undertaken by wg, could be cool on a wiki blog. [Some support for what Sanjiva wants is already in the spec. No further action anticipated.] ------------------------------------------------------- 15:20 http binding [27] [27] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0230.html [Some brainstorming about how to update the HTTP binding. Discussion will inform Philippe who already has an action to propose an update.] ------------------------------------------------------- 17:00 Multiple inline schemas [20] [20] http://lists.w3.org/Archives/Public/www-ws-desc/2003Oct/0074.html ISSUE: treatment of multiple inline schemas [pauld: Norm Walsh's blog on schemaLocation: http://norman.walsh.name/2003/11/03/locrules] [scribe lost connection, hope this stuff gets logged somewhere] [Chair recreates: WS-I is revisiting issue of inlined schemas importing each other. Current recollection is that it was to ban schema import pointing to a WSDL to mean importing any inlined schemas in that WSDL. Umit wants inlined schemas and imported schemas to behave the same way, e.g. schemaLocation is allowed and means the same thing in both cases. After some discussion, we decided not to restrict xs:import and xs:schema appearing in wsdl:types. We will not constrain the strategies specific implementations have for locating schemas (even embedded siblings.) The question of whether wsdl:import also pulls in schema components from wsdl:definitions/wsdl:types. Some members expected it should - we need to check this out more thoroughly.] 17:30 Adjourn
Received on Friday, 7 November 2003 18:17:56 UTC