Web Services Description Teleconference
29 Apr 2004

Review of Actions

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.

Task Force Status

(skipped)

Issue 165: Adding HTTPS support

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.

(Group agrees)

Issue 54: Allow binding to any HTTP method

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.

Media Type Task Force Document

JMarsh: Issue 163: publishing WSDL 2.0 schema. Media type needs this. Can we close this issue?

Umit: Yes, close it.

(No objections)

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.