- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 9 Mar 2004 08:40:30 -0800
- To: "WS Description List" <www-ws-desc@w3.org>
- Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA202DA770D@RED-MSG-30.redmond.corp.microsoft.com>
Web Service Description Group Minutes, FTF meeting 4 Mar 2004 Cannes-Mandelieu, hosted by W3C. irc: http://www.w3.org/2004/03/04-ws-desc-irc Present: David Booth W3C Roberto Chinnici Sun Microsystems Glen Daniels Sonic Software Paul Downey British Telecommunications Youenn Fablet Canon Martin Gudgin Microsoft Hugo Haas W3C Tom Jordahl Macromedia Jacek Kopecky Systinet Kevin Canyang Liu SAP Jonathan Marsh Chair (Microsoft) Jeff Mischkinsky Oracle Jean-Jacques Moreau Canon David Orchard BEA Systems Bijan Parsia University of Maryland MIND Lab Arthur Ryman IBM Igor Sedukhin Computer Associates William Vambenepe Hewlett-Packard Asir Vedamuthu webMethods Sanjiva Weerawarana IBM Umit Yalcinalp Oracle Observers: Martin Chapman WSChor Yves Lafon W3C Philippe Le Hegaret W3C Coralie W3C Paul Biron Health Level 7 Anish K Oracle In addition to the above observers who were present for most of the meeting, we had a number of other observers who observed parts of the meeting. scribe: Igor Sedukhin -------------------------------------------------------- Thursday 4 March -------------------------------------------------------- 08:30 Introductions and logistics - Assignment of scribes Igor Sedukhin, Umit Yalcinalp, Youenn Fablet, Kevin Liu Paul Downey, Jeff Mischkinsky, Asir Vedamuthu, David Orchard Hugo Haas Igor, Umit, Youenn, Kevin - New scribe policy: Since the chair is maintaining the issues list, but not the edtodo, the two can easily get out of sync. Our minutes should henceforth include explicit actions to the editors as well as resolutions of issues. - Agenda review -------------------------------------------------------- 08:40 WSDL Component Designators: Trolling through old minutes does not reveal clearly whether WSDL Component Designators should be added back into the draft as an Appendix. My memory says "yes, we decided that" but the minutes are unclear and the edtodo does not mention this. If you clearly remember something different, this is your chance to scream. Jonathan: WSDL Component Designators should be added back into the draft as an Appendix. [No objection] ACTION: Editors to add back the WSDL Component Designators back to the spec as SHOULD. -------------------------------------------------------- 08:43 Correction to minutes on wsdl:ServiceType [2]. Confirm correction to the minutes as enumerated by Umit. [2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0224.html Glen: This was my proposal and this was resolved at the last F2F. Umit: Checked and this was done. Sanjiva: Spec is not clear on when service name attribute is required. Glen will look at that ACTION: Glen to look at schema derivation in the current draft -------------------------------------------------------- 08:45 Issue 79: How much validation? [3] Jacek posted a relevant proposal [4]. David's analysis [5] [3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x79 [4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0121.html [5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0234.html [dbooth: My presentation: http://www.w3.org/2004/Talks/0304-dbooth-wsdl-lang-vs-proc/] DB presentation: WSDL Language vs Processor DBooth: Separate section in the spec on the processor. Roberto: Then we need to add a WSDL editor too. DBooth: Yes, maybe. Extract all the statements about what WSDL processor should do and put them together. Such statements are already in the spec, but scattered. Jonathan: Another pro I was expecting is simplification of the spec. Will address the complexity problem by addressing the language in the main spec. Arthur: We can spec the language without necessarily calling on the processor. DBooth: WSD is a set of assertions about interacting agents. WSD only partially describes the interaction. Umit: You seem to imply that WSDL is not a complete contract. Does not agree with that. Glen: That is actually true, it is not complete. [JacekK: Bijan, does David have the defn of monotony right? 8-)] Umit: It should be true by looking at the WSDL which must be the base. Bijan: The original contract may not be sufficient, but why is it not complete? Glen: There could be out of band things that WSDL does not capture. Sanjiva: WSDL is necessary, but may not be sufficient. DBooth: WSDL is a contract, but there could be additional obligations Extensions: extensions are non-monotonic. Glen: Extension may change the original 'assertion'. Jacek: That should not be true. Bijan: It depends on the extension. It defines if it is monotonic or not. DBooth: Yes, but we cannot assume. Jacek: Binding extension only affects the binding. Glen: Except that if it adds default operations in which case it also affects other description component DBooth: (from TAG) extension is ID'ed by a qname, target namespace must identify the meaning. Proposed clarification text for 6.1.1. Limiting the scope of understanding to the component to which mandatory extension is applied to. Arthur: That means existence of such extension may affect the whole document. Glen: Like in SOAP, look for those .. addressed to you and then look for what you must understand. Bijan: The doc means different things depending on how one processes it. Roberto: At least it coerces it. Kevin: Is the meaning of the whole component affected by a mandatory extension? DBooth: Essentially yes Glen: mustUnderstand = required = mandatory. You don't change the meaning of what the binding is. Bijan: You could. DBooth: Mandatory extension may change some of the assertions expressed in the WSDL spec Gudge: Ext mandatory not = it changes the semantics. Do we expect those things to so fundamentally change what is expressed in WSDL. Glen: Yes that is possible and we need to craft this into the spec. Bijan: What does this mean for validation of the WSDL doc? Glen: You can't validate what you don't understand. Bijan: If the meaning of the component is changed its validation rules may change too. DBooth: The spec is directed towards the meaning of the WSDL document. Glen: Difficult part is to describe the rules for the extension writers and make sure that does not screw up. Jeff: If binding ext adds ops why is it changing the interface? What is being validated: the document or how it is processed? Turning this into the context-sensitive language. Have to express what the context is. Kevin: Agrees with Jeff. If there is a binding and an ext and if I only need to understand the binding only and not the ext then why should I care about the ext? With the proposed changes I will need to. Roberto: The meaning of the component containing the ext is changed? What if the component was 'built' before the ext was added? DBooth: Maybe component is not right word, may be the element. Jeff: It feels like the 'foundation of sand' Jacek: .. lost ya... Gudge: Why is important for service to say the extension is required? DaveO: Isn't it that the client just does not want to have the error msgs? It wants to know up front what is required. Gudge: Do we anticipate exts that are optional. Are there use cases? [KevinL: In the "late bound" case, if there are multiple binding extensions defined under the wsdl:binding component and are all marked with wsdl:required, for a processor who only care about one of the binding extension, why should it be failed if it doesn't understand a binding it doesn't care at all? Especially in the "late bound" case where the WSDL file is discovered at run time, and artifacts are generated at run time to communicate with a service.] Jonathan: Let DBooth proceed. DBooth: Optional exts [pdowney: Trying things out and faulting can reveal your hand - like playing Cluedo..] DBooth: Those that do not change the meaning of the WSD assertions. Glen: That is not necessarily true. Bijan: It is not monotonicity, it is the "ignorability" that is doing it here. Being monotonic is not a sufficient characterization. Roberto: Then adding implicit ops to the interface by an ext will not be optional now? Glen: The ext adds those ops if you want to process it. [JacekK: <wsdl:binding> <soap:binding/> <http:binding/> ... </wsdl:binding> is this allowed?] [Bijan: I.e., optional extensions are optional only for the service client, not the provider.] Kevin: Required by who: the consumer or the provider? Jonathan: WSDL is from the service POV we agreed. Sanjiva: Move on [Bijan: It's *not* the case that the server is obligated to support all that. At least, that's not the right way to put it. It's a fact of the *language*, that the document won't be *true* unless the server supports all the extension,etc. etc.] Glen: Add an issue: is there a difference with client or service obligation with regards to ext. [Jonathan: New Issue: What is the scope of extensions?] DBooth: WSDL defines the way two agents interact and the way to test it is to actually verify if the interactions are as described. Arthur: Test case: WSDL and the message and assert if the message is conformant to the WSDL. Another one is to give a sequence of messages and assert that against the WSDL. Glen: Unless there is an ext that says something about the semantics of the op. Arthur: 1) is the WSDL consistent 2) is message conformant 3) is the sequence of messages conformant. DBooth: We should be able to test anything that the spec says the processor should or should not do. Bottom line: separate the processor from the language. Jonathan: We can adopt this and close the issue 79. Tom: Will this make the spec more or less readable? Is Jaceks proposal on including statements on validation in the spec also with this issue? Jacek: Was looking to separate it out. Glen: Also wants to keep it separate. DBooth: There are simple questions 1) separation of the definition of the language and assertions about the processor. Glen: Cares that we have clear expression of that whether or not it is in a separate section. DBooth: Can modify the doc and generate the changes that the WG can look at. Jonathan: Is this simply an editorial issue? [Bijan: +1 to cleaning specifying the *semantics* from various bits about arbitrary processors but not moving text around :)] Tom: Just state what has to be validated and add this text anywhere in the spec. [Bijan: I.e., for each section, you can just add a "Note: A processor that blahblahblah would blahblah blah with this component"] Hugo: There is no impact of what DBooth is proposing on the WG schedule. Glen: Let DB do it or reject. Tom: Does making these editorial changes address issue 79? Jonathan: Yes. Umit: Will the statements include "conformant processor"? [GlenD: as opposed to say "buggy processor"... All buggy processors MUST put 500ドル into Jacek's bank account.] Sanjiva: That would require defining classes of processor, there should be one for clarity. Jeff: There has to be the definition of what processor is meant. Start with those things that matter for interop. [.. snip ..] Jonathan: Just define the meaning of the language :) Bijan: Can't entirely *ignore* processing issues when specifying the semantics& different semantics can make processing sane or not. Sanjiva: Needs clarification 1) scope of required and that is it. Arthur: We are transplanting SOAP approach to WSDL. SOAP has processing model and WSDl doesnt. Define how processor maps infoset to the component model and that defines conformant processor. Gudge: How is that different from the way the spec is now? [DaveO: Glen, btw my point about "optional" bindings is that you and I might use the same WSDL, but I implement one binding and you don't. That to me should be ok. If we are both "required", then I should have to.] Glen: The issue of "requiredness" is different from separating the processor assertions. [GlenD: If we both claim to implement the same WSDL, we both need to be prepared to accept anything which is produced by clients which process that WSDL. So with bindings, you're right, in that it's unlikely I'm going to implement a WSDL that actually has your endpoint address in it.] [DaveO: If they only use required. The whole point of "optional" is that it isn't necessary. :-)] [GlenD: But if I put an optional extension in an interface which allows two different behaviors, ANY implementation of that interface must accept both. That's my point.] [Bijan: Hmm. Glen, with features and properties, one can, in some sense, avoid the global scope of extension changes in this way. Extensions can always set properties. So a binding could set a property. And in the interface, I have a feature parameterized by that property. Which say, adds an operation (or "enables" an operation).] [DaveO: Glen, I disagree. If there are 2 different behaviors that must be accepted, then they should be required, not optional.] [GlenD: DaveO: the whole POINT of the optionality is that the client can do EITHER.] Sanjiva: "Processor must do x" is ok to use except the extensions part. DBooth: Should we continue to mix definition of the language and processor assertions? Sanjiva: Yes, that is ok. [GlenD: And if the client can do one of two behaviors (avec ou sans extension), any implementation which claims to be conformant must accept both.] Gudge: Are there places where the processor is implied, but not asserted? DBooth: Not sure about that. Sanjiva: Right now the processor comes up only in types and extensions. Let's just fix the exts section. Processor assertions in the types section are ok right now. DBooth: This does not clarify the requirements on the conformant processor though. [GlenD: This discussion has instilled in me a deep and sincere, and in no way optional, desire for caffeine.] Sanjiva: No-one has complained about it so far, but there are a lot of complaints about the exts section. [Gudge: Gudge concurs with glen] [JacekK: Do we keep discussing it or do we just trust the editors, since we're not yet really going to LC?] Jonathan: However we can have a section on conformant processors that has all the necessary assertions. Introduce the conformant processor section and solve the two outstanding issues. -------------------------------------------------------- 11:00 Break -------------------------------------------------------- 11:30 Issue 79 continued. Current proposal, add conformance section with: 1) document conformance: conform to schema, etc. 2) infoset conformance 3) processor conformance (types, exts, Jacek's proposal) Sanjiva: 3 builds on 1 and 2. DBooth: Add to 3) accepts any conformant WSD. Jonathan: Proposed to the group to accept this Group did not disagree RESOLVED: Add conformance section as above. [DBooth: PROPOSAL ACCEPTED! WE HAVE PROGRESS! HALLELUJAH!] ACTION: Editors to incorporate the above proposal. ACTION: DBooth to propose specific changes needed for processor conformance text] [Issue 92, Issue 133 skipped for now.] -------------------------------------------------------- 10:50 Issue 112: Headers at the abstract level [9] - Headers as first-class citizens [10] - Glen's OOB feature proposal [11] [9] http://www.w3.org/2002/ws/desc/2/06/issues.html#x112 [10] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0004.html [11] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0053.html DaveO: Headers are fundamental at the protocol level. Most protocols have headers. Glen: Two mechanisms now: F&P and the binding. F&P may attribute what data needs to go into the application and then binding could lay it out into the header. Jonathan: There may not be disagreement that we do it via F&P. Umit: The proposal is that F&P is used, but there is an additional 1st class construct Jonathan: There was agreement that we will add such a feature. Close with AI on Glen and Yaron to reconcile? DaveO: We're not near the consensus there. Glen: It is simply side band data, why constrain it at the abstract level? DaveO: Having it at the abstract level may help apps to decide where to look for such information. We should take advantage of the SOAP model. Glen: It is not good to encourage people to say something must be in the header or not. Sanjiva: Can the same feature be used in the component? Jonathan: Same feature URI can be used repeatedly, yes. Glen: F(P*) not necessarily (FP)*. My proposal has one header (composed of various data) Sanjiva: We agreed on F&P mechanism for defining headers on the wire. Glen: We still wanted to have a header and not multiple. Roberto: If the feature components are different that may be multiple. Sanjiva: These proposals have to converge. Glen/DaveO: That's the problem. Jonathan: Clarification: application headers vs protocols headers. Tom: Defining headers is what people do with WSDL. Sanjiva: HTTP has mechanism for both sorts of headers. WSA defines headers for SOAP. [Yves: Point of clarification, cookies are NOT in rfc2616 (HTTP/1.1 spec), so there are not 2 ways of doing extensions in the spec.] DaveO: We're building toolkit that allows both kinds of headers. Tom: It should be possible to mix headers and it should not be constrained by WSDL. DaveO: To get to consensus: we want a generalized facility and then the other well defined ones. Glen: It does not work that way, 1) there are the headers or 2) here is the data that appears in the headers [Will attempt to reconcile positions during lunch.] -------------------------------------------------------- 12:15 Lunch Scribe: Umit -------------------------------------------------------- 12:40 Issue 112 cont. [GlenD: <soap:Header> <myDangerousStuffMasqueradingAsApplicationData soap:mustUnderstand="true"/> </soap:Header>] Jonathan welcomes the schema group members as observers. Issue 112: Glen suggests that it should be closed with a future proposal Glen suggests a strawpoll: 1. one bag one header for an application header 2. There can be multiple headers for applications. 3. abstain Paul: Is this about SOAP binding or WSDL in general? Glen: We can resolve this by defining one single feature. Jonathan: We can solve this by one feature, but we don't have to solve whether this resolves into one or more headers right now. [Anish: Does proposal one prevent proposal two and vice versa, or is it a question of what we want to encourage?] Glen: We will define how it gets resolved in the future for SOAP binding. DavidO: Objects because it makes Glen's proposal accepted. Correction: Third option is to do nothing, not abstain. DavidO: The question is whether there is one place to put app data or be flexible as BEA proposes. Sanjiva: We should close the issue, continue to work on the action item for Glen. We are not done yet with respect to the action item since there are two proposals. RESOLUTION: Close this issue. Open another one to decide whether there should be a single header vs multiple headers (or both). -------------------------------------------------------- 14:00 Issue 109: WSDL versioning [12] - Use cases (DavidO) [13] - Requirements (PaulD) [14] - Scenarios [***** ACTION: DaveO to write up a proposal for augmenting schema information to enable versioned data. *****] [12] http://www.w3.org/2002/ws/desc/2/06/issues.html#x109 [13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0016.html [14] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0082.html PaulD: Must understand with tag finding should be discussed. [DaveO: My post to schema is at http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0124.html] PaulD: If we have WSDLs with versions, the next thing that needs to be discussed how do we refer to them? DavidO: There are multiple things that are in WSDL that the Schema group do not care about, but issues about what we do with Schema is relevant to the schema group. Adding operations, etc should be addressed separately. Jonathan: The issue is what do we do with documents that have the same namespace. DavidO: We use XML schema to describe the messages. Is there a different interpretation of Schema we can use? Is there a dial in the schema that we can use that allows the extensibility desired? PaulB: If you use a restricted schema, this is possible. If content model is flat and the extra content is at the end, it is deterministic and easy to accept a document. There are two attributes: Validation attempted and validity. [HenryT: Their relation is discussed in detail in the following informal note, which WSD WG members may find helpful: http://www.w3.org/XML/Group/2001/06/validity-outcomes] [asir: http://www.w3.org/XML/2001/06/validity-outcomes.html is the public version] PaulB: If the root node is invalid, you can look down the tree and strip the nodes that are valid unknown. CMSMCQ: Paul's algorithm is applicable with Schema 1.0 with the restrictions that are defined. Jonathan: There may be a convention we can recommend in WSDL. Is this true? [DaveO: There's a really cool benefit, you don't need wildcards..] HenryT: Use global elements and validate twice. Use 1st time what Paul recommends, and validate again. Sanjiva: Why are we talking about this? This is not about WSDL. Jonathan: Versioning of schemas is relevant for us. Sanjiva: Perhaps a note from the schema group DavidO: If we want to enable someone to take advantage of the double validation, etc. we need to say explicitly say it in WSDL. Jonathan: Use a style. JeffM: We can be more prescriptive about the way the Schema is used. [DaveO: Q: does this require special schema tools] Paul: The result of a schema processor should make more information available but it is doable by the current processors CMSMCQ: Use top level elements. Use what you learn with regular languages. The techniques may be recommended for schema authors. HenryT: WSDL should recommend WSDL normalized schemas. With wildcards added at the end. Jonathan: If this is solved in Schema 1.1, we can recommend moving to Schema 1.1 HenryT: We can recommend best practice. [HenryT: The advantage of the two-pass story doesn't require authors to take action.] DavidO: Two pass processing does not require the WSDL author to include a wild card. [HenryT: Paul Biron points out that receivers are in control in e.g. the two-pass+surgery story. Whereas in the auto-insert-wildcard(+boundary) story, the receiver has lost control of how strict they want to be.] PBiron: Is the extra stuff in the same namespace or not? What are the requirements for the extra stuff? DavidO: If there are constraints, that may allow us to get to the point needed. Sanjiva: This is not problem for WSDL. [HenryT: So I understand MSM's suggestion as saying -- "Give me a schema for a WSDL language -- I'll use redefine by extension to make every type, or any subset of types you name, extensible, by redefining by extension with the above] Sanjiva: The schema is not defined by WSDL, it comes from somewhere else. [HenryT: Note this rules out schemas which use 'all' groups (no bad thing :-)] DavidO: If there is a mode, WSDL 2.0 can define a WSDL application of schema with the validation rules that are discussed. DavidEzell <scribe misses some points>. DavidO: We have extensibility and versioning. It is not clear how they overlap. There are instances when versioning and extensibility collide. It is very hard to decide where the boundaries of versioning are. DavidEzell: You need to give a hint up front when you have a new version up front, with a new namespace. JeffM: We have not decided what we mean by versioning. Asir: Says that the WSDL does not care about the underlying type system, why are we discussing schema specific issues? Jonathan: We need to specify at least Schema for interop. Bijan: Can we take this out of critical path for Part 1 to meet our timeline? Jonathan: If we can adopt a marker and best practices, it would help the problem. DavidO: I will get my customers to send a last call comment if this is not handled here. [Bijan: Ah, that was what I wanted :)] DavidO: we are describing the validity of the message, this is part of the description. JeffM: You have not established what the requirements are. Get a definition of versioning first to move on. PaulD: We are not only using schema, this is intrinsic to WSDL. We generate messages as well. DavidO: If it is done with the primer, the functionality will not be in. Put this on the back burner as an issue. If we can close all the other issues, we can come back to this. Bijan: Q for David. Lets say have a task force and come up with recommendations? Should they be normative? DavidO: Yes. There are range of solutions Bijan: If we need to solve this problem, this will affect Part1. DBooth: This is a best practices issue. This can not be normative. Sanjiva: Close this issue right now. We already restrict the messages with XML rules. If there is additional constraints within the schema expressed by schema, it will be perfectly fine. This is a solution offered by schema. Jonathan: We need a definite proposal. DavidO: Why aren't the people in this group interested in pursuing with this with Schema wg? JacekK: I am interested in pursuing WSDL construct versioning. Lets move this issue to the primer. [KevinL: +1 to move on. I don't believe we agreed to move data versioning to primer.] [Discussion on whether we should have a joint task force goes on. ] Jonathan: The mission of the task force is to come up with improvements to Part1 and Part2 or Schema itself? [sanjiva: I have completed the action item to insert a conformance section - would appreciate if DavidB and others would take a look and propose additional conformance constraints.] RESOLUTION: Joint tf with Schema and WSDL to investigate whether there may be mechanisms developed. RESOLUTION: Close the issue. ACTION: Primer to include best practices and the Schema group to review the best practices language. -------------------------------------------------------- 15:10 Issue 140: Version attribute [15] - Tom's initial proposal [16] and follow-on proposal [17] [***** Paul to develop clear enumeration of options *****] [15] http://www.w3.org/2002/ws/desc/2/06/issues.html#x136 [16] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0049.html [17] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0069.html [pdowney: Has posted an attempt to synthesize the versioning discussion: http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0014.html] CMSMCQ: My perception is that there is a need to point to the version of the schema language. KevinL: Three issues: attribute for defn, define how to use it, version attribute for interface. PaulD: If there are two documents with the same namespace, how do you differentiate? You need to know which is the newer version. Gudge: The usage of namespace is the same as in schema. DavidO: The reason for a version attribute is to allow compatible changes to be introduced without changing a namespace. Changing a namespace is costly for introducing compatible changes. We also need to construct a uri from the version attribute in addition. [pdowney: So is the definitions namespace synonymous with the interface major version ?] Sanjiva: We need to make changes to all our components in order to refer to versions of the components. This is drastic change. [Anish: +1 to Sanjiva's comment] Sanjiva: Versioning of the definition is not meaningful. [GlenD: Wow. Sanjiva rocks my world.] JacekK: Version attribute does not help much except when WSDL is downloaded and you need to refresh/regenerate artifacts. [DaveO: +1 to JacekK's pov] JacekK: We don't need to say more than that. [JacekK: dbooth, personally, I think checksum or diff is simple enough, but I guess for some people this might vary.] KevinL: Optional version attribute will be helpful in the defn elements will be helpful for internal development. GlenD: When definitions have to refer to other documents, the referencing will be problematic. You need to carry the version attribute to make sense of what is being referenced. There is not much need for this, other than the use case JacekK brought up. WilliamV: we should not do anything on this, but if we do we should use the namespace URI to convey version info. [TomJ: I think messing with the target namesapce and adding a version convention is not a good idea] [sanjiva: +1 to it not being a good idea] Bijan: There are two aspects to the problem: when to say things are different and how to define relationships between things. JeffM: This problem is an old problem. The version attribute with unspecified semantics is not useful. We need to define substitutability. DavidO: Schema group has looked into the formal defn of substitutability, acceptable sets, etc. [pdowney: wanted to state that David and Norm's TAG finding on versioning matches his practical experience] Igor: Version is useful at runtime. If one needs to maintain relationship between changes, change management is the place to do it. [pdowney: Interesting point from Igor - that actual version could be discovered at runtime.] Tom: Describes the details of his proposal. Version attribute indicates a minor revision. [MSM: For the record, the current rough draft of the schema paper on accept sets, etc. is at http://www.w3.org/XML/2004/02/xsdv] Tom: If WSDL artifacts change, the compatible changes are adding operations, added endpoints. These changes allow the clients with the old versions to still operate. This solves a very well defined set of problems. This is not a solution to the entire versioning problem. [DaveO: big + 1 to Tom.] [KevinL: +2] [igors: Tom, if someone has changed the wsdl or schema then he has to change the namespace. Things won't work otherwise.] [Roberto: A hash computed by the consumer of the wsdl would work just as well as the version attribute (actually better, because the client could decide what the relevant information is)] [DaveO: Tom, don't do that.] RESOLUTION: Close the issue with no action. -------------------------------------------------------- 15:45 Break -------------------------------------------------------- 16:30 Joint Session with TAG (Web arch [21]) - Saying more about QName mapping (?) [22] - Error recovery vs. not having to "validate" parts of the doc not used or examined by a processor. [23] - Comparison of XML namespaces with Schema and WSDL namespaces. [23] - Cracking a component designator URI. [23] - Operation safety? (Issue 117) [24] [21] http://www.w3.org/TR/2003/WD-webarch-20031209/ [22] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0164.html [23] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html [24] http://www.w3.org/2002/ws/desc/2/06/issues.html#x117 [dbooth: Jacek's WebArch comment from http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0030 .html: 4.5.5 below the Good Practice: QName Mapping - the section (or some other) should probably say more on the interaction of QName Mapping, fragment identifiers in XML (4.5.8) commonly used for this mapping and namespace documents (4.5.4)] JacekK: We need a new scenerio to connect sections. [dbooth: WebArch section on QNames: http://www.w3.org/TR/2003/WD-webarch-20031209/#qname-uri-syntax] [plh-lap: (sections 4.5.5, 4.5.8, 4.5.4)] Stewart: If Qnames are going to be used for identification, you need a mapping to URI space. JacekK: However, there is no requirement to use these mapped URIs somewhere. [Chris: http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html] DanC: The discussion is still going on, there is an error (number?) and the architecture document just reflects the current state. Next issue: http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html DanC: Should be clarified if not clear enough. [Gudge: http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html] Jonathan: We name abstract components in a targetnamepace. We have taken the namespace to a different level. DanC: How does the qnames and targetnamespace interact? Have you specified how Qnames mapped to URIs? If you have done this, you are done. Jonathan: Do we need the mapping for URIs for the importing mechanisms in WSDL? It is ambiguous whether the namespace should be absolutized before adding to the component model. [Gudge: Likes the notion of mandating that targetNamespace URIs be absolute to begin with.] [DaveO: +1 to absolute URIs. ] [asir: +1 to absolute URIs. Simple things should be simple.] umit: +1 to absolute URIs [dbooth: +1 to absolute URIs] [jjm: +1 to URIs, absolutely] [Chris: +1 to absolute URIs fwiw] [Anish: +1 to absolute absolutely :-)] [alewis: +1 to absolute URIs in targetNamespace] DanC: Don't canonicalize, just absolutize then compare string by string. Jonathan: There needs to be one mechanism for interop. [Stuart: URI comparison bit in RFC2396bis is at http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison] ChrisL: Agrees with DanC (if scribe got it right) [asir: My +1 was to mandating that targetNamespace URIs be absolute to begin with] [Chris: Mostly - except dan expressed that comparing IRIs either by character or by hex escape was undecided whereas actually the IRI spec says to compare them by character] Jonathan: Is the relative URI allowed for schema [namespaces] imports? [Stuart: Basic idea is that there are multiple comparison functions. There is one 'identity' function (absolute and then compare character-by-character). Other compariisons must respect 'identity'.] [DaveO: rfc 2616 says http://www.abc.com and http://www.ABC.com are the same.] [Chris: Yes, and http says that foo.org and foo.org:80 are the same.] [DaveO: yup.] MSM: If it is not an absolute, it will not work. [Stuart: ie. beyond an identity comparison, other comparisons that compare 'identical' URIs must not say they are different (I think).] MSM: Schema does not prescribe behaviour for absolutization. DBooth: QName is ambiguous by itself. The mapping should be sensitive to partitioning. Stuart: You need to incorporate partitioning. Component Designator URIs: http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html [Chris: you don't have to use http. But a transport that reports the media type is easier, naturally. So (to summarize) webarch says that the interpretation of a fragid depends on the media type of the resource representation. if you don't fetch one, you don't know which set of rules to apply.] [Bijan: (except if you have that information from some other means)] Issue 117: Operation safety [dbooth: Hugo's message: http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0246.html] [DanC_jam: idempotent(P) iff forAll X P(X) == P(P(X)). # the definition I carry around in my head] [Bijan: http://en.wikipedia.org/wiki/Idempotent. Yep.] [dbooth: Hugo's slides: http://www.w3.org/2004/Talks/0304-hh-wsdl/] [Bijan: Which isn't what Hugo said. Or, at least not clearly.] hugo: Idempotent messages get the same result regardless of the number of times they are repeated. [Roberto: The bit about side effects for idempotent operations was suspect.] [Bijan: "same side effect" must mean *the* very same *one*.] [caribou: http://www.w3.org/TR/2003/WD-ws-gloss-20030808/#idempotent] [Roberto: right, just one in number] DanC: Motivation for safe is important. The lower levels need to know whether the operation is safe or not defined by the person that defines it. [Stuart: There is clearly more to be said about idempotency - see http://www.amazon.com/exec/obidos/tg/detail/-/052155344X/qid=1078416611/ /ref=sr_8_xs_ap_i1_xgl14/104-6324547-4209537?v=glance&s=books&n=507846 :-)] Bijan: Is this the only place where we define something about semantics of an operation/Message exchange? Discussion ensues whether GET operation is safe or not. [Stuart: Idempotency and Safety enter the vocabulary from RFC 2616 Section 9.1 (HTTP 1.1 spec) http://www.faqs.org/rfcs/rfc2616.html] Bijan: Safety is context dependent. Sanjiva: From WSDL perspective, the question is whether we should do the marking of safeness at the abstract level or not. [Stuart: BTW defn of idempotency n RFC 2616 is not very adequate either (side-effect free)] Arthur: Most of the Web is for information retrieval. It is a good idea to mark safety at the abstract level. Glen: Is it possible to break the safeness in different levels in WSDL by adding additional headers, etc? JacekK: It's not yet clear if an operation identifies a piece of functionality or not, because if not, we cannot mark an operation as safe as that depends on the functionality behind the operation.] [Chris: Yeah, it has the same result every time ....] Stuart: There is no way to make the WSDL generator to define an operation to be safe for bottom up case. [DanC_jam: Yeah... what he's saying.] [Chris: Modula-3 allows modules to be marked as 'unsafe' meaning they use untyped memory access.] Arthur: For top down, it is relevant to be able to mark operations as safe. [pdowney: +1 to Arthur] [DanC_jam: I heard Arthur mention several programming languages with a relevant notion of safeness: const in C++, .Net attributes, Java 1.5 something.] KevinL: What is the safeness mean for the client of the service? Why is this useful? [asir: according to Hugo, e-mail, - a safe operation is cacheable; it may be serializable as an HTTP GET (or even HEAD) request; if so, the request can take advantage of the Web infrastructure such as caches. A toolkit could make the choice of using an HTTP GET or SOAP GET binding for such operations (e.g. GetStockQuote) if there where marked as such. Knowing that an operation is safe or idempotent can allow poor-man's message reliability, or message reliability optimizations: safe and idempotent operations can be repeated without additional side-effects, and therefore this eliminates the problem of ensuring that a message is received only once.] [Chris: http://en.wikipedia.org/wiki/Idempotent] Jonathan: An example is when your credit card is going to be charged and you are informed on the web. [Chris: In user interface design, a button can be called "idempotent" if pressing it more than once will have the same effect as pressing it once. For example, a "Pause" button is not idempotent if it toggles the paused state. On the other hand, if pressing it multiple times keeps the system paused and pressing "Play" resumes, then "Pause" is idempotent. This is useful in interfaces such as infrared remote controls and touch screens where the user may not be sure of havin...] [plh-lap: http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction] DanC: Web Architecture has already defined. SAnjiva: It is not covered for all the MEPs that exist in WSDL. We have to define it for any pattern. [Stuart: FWIW see RFC 2616 "9.1.1 Safe Methods"] [Arthur: I said that Java 1.5 will have code attributes, so even though there is no language syntax to mark a method as safe, you could define a code attribute to mark a method as safe. In C++ you can mark a method as const which means it doesn't modify the object.] [Roberto: minor nitpick: they are called "program annotations", or simply "annotations"] Chris: Safe does not mean that anything bad will not happen, for example downloading illegal material from the web may be a safe operation. [Chris: because no additional obligations were incurred] [Arthur: In .NET there are code attributes and these are used for Web services, so you could also define a new .NET code attribute to mark a method as safe.] PaulD: Worries that 'safe' is just one instance of a generic problem - how to publish policy. DBooth: We need to clarify that the safety is from the perspective of the client for any MEP. DAnC: The only requirement that I can speak for is the Request/Response (In-out) pattern [plh-lap: http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction] Phillipe: Section 3.5 of the Web Arch docuement will suffice [DanC_jam: (I don't know whether "input messages" get exposed sufficiently to designers)] Jonathan: Lets refer to HTTP or web architecture document. [dbooth: DanC, yes in WSDL they do get exposed to the designer to the same degree as operations.] Glen: Has an issue for addressing interactions with extensions. JacekK: Do we expect/agree when we have an operation in an interface that we can assign semantic to an operation? This is the same problem, because assigning safeness is adding semantics. -------------------------------------------------------- [Chair recalls Joint session TAG ended at about this point.] [Discussion onto whether the operation carries semantic or not.] Gudge: What are we looking for? To label an operation "safe" in the same way the HTTP GET is safe? Sanjiva: This may not work in general, but we are asked just to add a mechanism to enable marking safeness. [TomJ: If we have to add it because the tag will demand it, lets just stick some syntax in there and we can be done with it.] [KevinL: +1, but that syntax must be optional] [plh-lap: 1. safe='yes' 2. safe='http://..../safe' 3a. feature/properties (we define the uris) 3b. feature (we define the uri) / property (we reuse soap/get)] [sanjiva: +1 for (1)] The wg starts discussing whether the safeness should be expressed via feature (hugo), a simple property (Tom), feature at the abstract level (and property at the binding), etc. [anish: +1 to feature -> webMethod] Proposal: Add an attribute on operation, default to false to indicate the safeness. [KevinL: against default to false. If not specified, it means no claim is made.] [asir: SOAP 1.2 - Underlying protocols designed for use on the World Wide Web provide for manipulation of resources using a small set of Web methods such as GET, PUT, POST, and DELETE. These methods are formally defined in the HTTP specification [RFC 2616], but other underlying protocols might also support them. Bindings to HTTP or such other protocols SHOULD use the SOAP Web Method feature to give applications control over the Web methods to be used when sending a S...] Glen: This is the same as setting the webMethod to GET. [plh-lap: -1 to reuse the webMethod get property] Jonathan: We will have duplicate information if we need to specify the web method in the binding as well as the abstract level. Sanjiva: Proposal: Add a safety property to the interface operation component. [plh-lap: Property?] [anish: Is the WSDL then going specify exactly what is meant by "safe"?] [plh-lap: We point to the web architecture] Roberto: Property syntax is better because it can mark interfaces to be safe instead of defining it on operation. [plh-lap: And if people don't like the definition of safe in web architecture, they should fix the web architecture.] Glen: There is no reason to add anything to the component model. The wg continues to discuss properties in component model vs features & properties. [Arthur: e.g. ASP.NET happily exposes every operation of a Web service as SOAP/HTTP, HTTP GET and HTTP POST] Straw Poll: 1. boolean property to operation component 2. use property (from F&P) to designate safety. 7 in favor of 1 8 in favor of 2 Resolution: We don't have a strong preference. Bijan: redo the strawpoll. Boolean property in favor 8 F&P : 8 [Chair asks who cannot live with the approaches, there are some on each side. Chair adjourns meeting, will figure out a procedure for moving forward before tomorrow.] [hugo: Hugo's slides: http://www.w3.org/2004/Talks/0304-hh-wsdl/] [Issues 123, 117, @wsdlLocation skipped for now.]
Received on Tuesday, 9 March 2004 11:41:06 UTC