See also: IRC log
Erik Ackerman Lexmark David Booth W3C Allen Brookes Rogue Wave Software Roberto Chinnici Sun Microsystems Paul Downey British Telecommunications Youenn Fablet Canon Hugo Haas W3C Amelia Lewis TIBCO Kevin Canyang Liu SAP Jonathan Marsh Chair (Microsoft) Jean-Jacques Moreau Canon David Orchard BEA Systems Bijan Parsia University of Maryland MIND Lab Arthur Ryman IBM Asir Vedamuthu webMethods Sanjiva Weerawarana IBM Umit Yalcinalp Oracle Prasad Yendluri webMethods, Inc.
Tom Jordahl Macromedia Josephine Micallef Telcordia/SAIC Dale Moberg Cyclone Commerce William Vambenepe Hewlett-Packard
PENDING 2004-01-08: Pauld to write up examples of schemas for the Primer. PENDING 2004-01-28: Philippe and JMarsh will look at the ipr for test suite. PENDING 2004-02-12: DaveO to produce a refined proposal for Asynch HTTP binding addressing the concerns of folks that object to leaving replyTo info out of WSDL. PENDING 2004-04-01: Marsh will get schema tf going. DONE [.4] 2004-04-01: Editors to update SOAP 1.2 Strawman proposal to take Part 1 changes into account. DONE [.2] 2004-04-22: JacekK to add text on the purpose of endpoints and incorporate Kevin's breakdown to design/configuration/run-time. DONE [.3] 2004-04-22: Marsh to add attribute vs. property syntax as an issue. DONE [.3] 2004-04-22: Marsh to add UseWebMethodAsOperation shortcut syntax as an issue. DONE [.5] 2004-04-22: DaveO to come up with list of HTTP functionalities to evaluate the coverage of our HTTP binding against. [.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0077.html [.3] http://www.w3.org/2002/ws/desc/2/06/issues.html [.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0080.html [.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0083.html
(Discussion about implications of XML 1.1 on WSDL. Arthur notes that the character set is expanded and this may have implications.)
JMarsh: You may get values from a 1.1 parser that you wouldn't get in a 1.0 parser. Infoset defines character information items and says what they mean.
Arthur: THey also define a char set: ISO 1046(?) char code.
...I think it's coupled to XML 1.0. If the spec were tight, it would say what are the legal values.
<scribe> ACTION: Arthur to write up concerns about XML 1.1 implications on WSDL 2.0 for potential forwarding to XML WG
JMarsh: Important not to bake XML 1.0 into WSDL 2.0.
...I could send you a description in 1.0, and right now there's no way to know if your SOAP messages will be 1.0 or 1.1. Perhaps that would be a property or binding flag.
<Marsh> ACTION: Marsh to add an issue on describing the XML version of SOAP messages.
JMarsh: Jacek proposed text on the purpose of the binding.
Sanjiva, DaveO: Read briefly and seemed ok.
Roberto: More interesting example would be to say "I want message integrity" or "confidentiality".
...I.e., replace TLS.
Sanjiva: It could go somewhere into part 1.
JMarsh: It's introductory material.
dbooth: We should clarify that "service defines a set of interchangeable endpoints" refers to application-defined interchangeability.
Arthur: Yes, like quality of service, for example.
JMarsh: Let's drop the word "interchangeable" from the intro, and say more about this in the section on services.
DaveO: We split this into two issues: 1. add the put/delete verbs 2. How to do extensibility.
JMarsh: We did the put/delete part as part of issue 64. Now our status quo is 5 verbs, and DaveO proposed adding any qname.
DaveO: I just mirrored the way XForms did extensibility.
...Two separate things: 1. allow names, 2. Allow qnames.
Hugo: When you see a bare name, that means the input is app/xml and output is app/xml and works with any style. HTTP method is the name you use.
...That's confusing because we define "post" which does "POST", but "get" does something different from "GET", so my friendly amendment was to allow only any qname -- less confusing and covers the previous case anyway.
DaveO: Sounds like Hugo should take my proposal and his amendment and write it up, to have one clear text to discuss.
JMarsh: The other question: Do we *want* it to be extensible?
Sanjiva: I think it's overkill.
dbooth: What's the cost?
Sanjiva: Maybe no cost, but there is a cost to people reading the spec. I don't see people using it.
(Cost: Adds to the spec.)
Sanjiva: We don't add things just because they're no cost.
DaveO: Cost is minimal. Traditional use of WSDL has not made full fidelity use of HTTP, but it's hard to predict that future use wouldn't make fuller use.
Sanjiva: Fair enough, but SOAP .09 used MGET, but my sense is that most HTTP sites don't adopt that easily.
Hugo: This issue is tied to the issue of using different media types: The last line that DaveO wanted to add to the table would allow any method and any media type. It would be good to hear if people are interested in having more than app/xml flying by. If we want to allow more media types, we'll need a similar solution and we'll get the HTTP method extension for free.
...Not sure what the TF is doing though.
(JMarsh ponders other ways to do this)
Umit: We thought that we would not deal with how it would be on the wire in that TF.
...All you're describing is that you have a schema and a bunch base-64 items, but not how to do the binding. That would be next.
JMarsh: If you add media type to HTTP binding that wouldn't have re-use capability, right?
...Whereas other HTTP features could be reused in the context of the SOAP HTTP binding.
PaulD: Trying to understand where this is leading. WSDL describes WSs. Some people describe REST view. Would this satisfy those people?
DaveO: Typical REST view is 4 ops: get, put, post, delete, which are already satisfied by issue 64. This is not necessarily a REST view, though I've seen interesting traffic on other operations, such as PATCH, which is like a PUT to a fragment. Also seen discussion of WebDAV, and how to bind to PROP-FIND and PROP-PATCH.
...Not satisfying REST per se, but it's hard to predict that only the 4 HTTP ops would be enough, and this extensibility comes at low cost, and people may end up needing it.
PaulD: It has definite benefits. Anything we can do to ensure that WSDL can be used beyond SOAP over HTTP is worthwhile.
...Describing future WSs is worthwhile even if it adds a little to the spec.
StrawPoll: Should we have extensibility of the HTTP method?
Result: 6 yes, 4 no
<scribe> ACTION: Hugo to redraft DaveO's proposal for extensible HTTP operations
<asir> I believe this is related to Issue 164: Support for HTTP chunking and other HTTP options, right?
(DaveO is explaining his http features proposal)
went thru several specs to see what properties may be useful to describe in WSDL. Does anyone have others that should be there?
arthur: should not describe http aspects that are dynamically negotiated in http. A well-behaved client should just do http properly.
Arthur: In most cases, you'll get the WSDL once and let it rip.
...I think this would be harmful. HTTP is a very loose coupling, and that's what made the Web scale.
DaveO: In the way you design the description of the protocol, it has an effect -- trade-offs. For HTTP, with typical interaction it makes brilliant sense. I'm surprised you don't want to update your WSDL when something changes in HTTP and more capabilities are available. There is a cost to the more chatty interaction needed if you don't have a more complete description.
...Looking at cost/benefits at greater up-front description versus more runtime negotiation is a good way to analyze this.
Umit: In the media TF the acceptable range of wild-carding media types is a similar thing -- the range of things that are known at description time.
...The wild-carding is one example of what DaveO is describing: the accept versus content type.
...At description time you'd like to say you accept binary/*, but not necessarily jpeg.
Arthur: We don't tell people to continually update their WSDL. We treat it as development time artifact. The apps do not at runtime check to see if WSDL has changed -- that would be disruptive.
...Suppose on day 1 gzip is used, and later a new binary xml compression is available and advertised on their servers. Most clients will ignore it, but at some later point the HTTP stack may get upgraded for the new one, and it will get picked automatically. That's loose coupling, and it's a key feature.
DaveO: I understand how to version in compatible ways. I'm not suggesting that you create a WSDL doc and describe gzip and super-cool-binary format, and then *require* that the HTTP stack be replace. It shouldn't supercede or invalidate HTTP. The idea is to skip some of the negotiation steps.
Sanjiva: If we do this we'd be making these option attributes on the HTTP binding, right? (Yes) Then we'll need to define best practices, or they won't be used. We'd have to say: at dev time figure out the runtime features, and write them down.
JMarsh: If this is info that could improve performance, perhaps it should be left to extensibility.
Umit: By looking at what's been proposed, there are different areas that are features of HTTP that you're using and how they can be configured. This looks like Features and Properties. It would be valuable for people to use this in their WSDL. We could publish a set of F&P that people have found useful, in a separate doc.
JMarsh: Let's bring this back to the mailing list for more discussion.
DaveO: I don't think people have had time to digest it. We could do a survey of all the properties of HTTP that people find useful, and then see how many of these are useful in WSDL. One position: Anything that can be done with negotiation should NOT be included. But there are other things outside of negotiation that are worth examining.
JMarsh: EVERYONE please go through DaveO's list and see if you agree/disagree with his categorization.
JMarsh: Issue 163: publishing WSDL 2.0 schema. Media type needs this. Can we close this issue?
Umit: Yes, close it.
Umit: Had a conf call, made progress. Closed all issues. Decided about wildcarding.
JMarsh: I'd like to see a WD published.
...Please have a WD ready by our May F2F meeting in NYC, to get approval from the WG.
<scribe> ACTION: Umit to work with Anish to create a working draft on media types ready for our May F2F meeting in NYC.
DaveO: What about a WD for LC on part 3?
JMarsh: My goal is a "zero-bug bounce" (i.e. 0 outstanding issues) at our May meeting.
DaveO: What does the WG need to do before, to help?
...We need to do a SOAP 1.1 binding, so someone should submit that, right?
JMarsh: That's to be a separate document, per our charter. It isn't on the same LC schedule.
...Same with the primer.
...And RDF mapping.
...How to be helpful: Look at what Sanjiva and Jean-Jacques did on part 3.
...People should think about what their company's positions are on part 3 draft.
Sanjiva: Might be helpful if we take a clean start against this draft. Most issues are against the old stuff, which are far out of whack now.