See also: IRC log
May 6th [.1]
APPROVED
[JMarsh to fill this in]
Jonathan: Will try to get draft agenda out EOD Friday
Proposed testing meeting Thursday afternoon in NYC for those interested
Umit: What's up with MTOM/XOP?
Jonathan: We should have some discussion about that at the F2F
... Goal was to finish all issues - not too likely at this point, but we can shoot for at least tightly categorizing issues (AIs, etc) that we can't finish
Kevin: Phone access?
Sanjiva: Should be phone, but not sure of quality...
c. Review of I18N WS Task Force documents [.6]
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0034.html
a. Media type description
- Draft of first WD for WG approval by May FTF.
Jonathan: Would be good to get consensus on publishing the draft, even if there are issues, as a starting point
- Track operation safety (TAG) [.2]
Opening new issue
- Normative dependence on XML Schema 1.0 precludes XML 1.1 (JJM) [.3]
- Can a WSDL 2.0 XML 1.1 document contain (or reference), a XML Schema 1.0 type description? [.3]
- Is it valid for a XML 1.1 document to import or include a XML 1.0 document (and vice versa)? (Paul) [.4]
Add new issues
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0093.html
Hugo: (summarizes proposal)
Jonathan: Big question is do we want extensibility at the method level?
David: Wanted to see concrete proposal before going ahead.
Jonathan: Issues with having a QName as opposed to an HTTP-specific enumeration?
Arthur: Why not just a string?
Jonathan: Name collisions, IBM-foo vs. Microsoft-foo
Arthur: Arent these HTTP verbs? GET, POST, etc?
Hugo: This came from discussion of using HTTP method as method attribute. That's not enough to have all the parameters you need... for instance, two ways to serialize HTTP POST.
... This means you need to specify a bunch of things, which you could wrap up in a QName.
<pauld> http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0042.html ?
Sanjiva: Clarify what this proposal is about?
Jonathan: Status quo == a string for method, with various other properties. New proposal wraps up various properties behind a QName for method.
Sanjiva: For common usage, the HTTP method might be variable, but the rest might be the same... serialization for GET and MGET might be the same, etc.
... Capture extensibility in
... HTTP methods by using a String
Arthur: Combining how you're serializing with the method seems like a bad idea. Let's just make method a string, with another attribute(s) for other stuff?
DavidO: Maybe we should change "method" to "method-and-related-stuff"? Seems easier to just combine things than to have to deal with each area of extensibility separately.
Paul: On the wire, both IBM:BUY and MS:BUY would be the same... why not use what's there, "BUY"?
DavidO: Tooling would know that particular serializations, etc, would be associated with the particular company-specific "BUY"...
Umit: There's a distinction between method and the other stuff... we should be describing them separately.
JeffM: Does this lead to everyone defining QNames for every combination of attributes?
DavidO: Basic HTTP should only have a few. Trying to provide an extensibility point for the simple case.
JeffM: How does this optimize for the simple case, do we specify QNames?
DavidO: For basic HTTP, yes
JeffM: Why not F&P, by the way?
Hugo: Table 3.1 is modelled on the XForms submission table, and follows their lead for dealing with extensibility. Address the simple cases, and allow for potentially infinite extensibility.
<umit> +1 to Arthur
Arthur: Why not just have attributes for basic stuff like method and MIME type, then extensibility for other stuff?
<sanjiva> I'm confused as to why we don't introduce http:serializationFormat, http:authenticationType etc. as defined in DaveO's http props message and allow users to put those where they want to. The http METHOD is a speciial thing which is a fixed string or some extension string ... so make it an xsd:string and then say the values GET/POST etc. are defined and that anything else that goes there MUST conform to HTTP spec's requirements of operation name.
<Arthur> +1 to Sanjiva
DavidO: F&P vs. WSDL extensibility is a separate issue
<Arthur> +1
<Arthur> +q
DavidO: We have use cases for this stuff, but they aren't great. We've learned that extensibility is a good thing, so let's support it rather than not allowing for it
<umit> +1 to Marsh :-)
<sanjiva> +1 too!
Jonathan: Why isn't it better to enable extensibility for each parameter, rather than wrapping them up in QNames?
DavidO: Worried about a more-complex-looking proposal...
Arthur: QName makes spec harder to read (as opposed to "GET", "POST", which are well understood), and harder to implement (need table lookup, etc)
... Doesn't scale if you need new QName for every combo
DavidO: Do we have a "full potato" proposal?
Hugo: Had one, but it looked overly complicated...
scribe note - "full potato" == allow setting all properties individually
DavidO: Can the group see it?
Jonathan: Would no extensibility for method be OK?
Arthur: We clearly have a requirement from somewhere (WEBDAV). But that doesn't mean we have to slam everything together under a QName
Jonathan: Isn't strictly a requirement yet...
<Zakim> sanjiva, you wanted to make a proposal
Arthur: Why exclude WEBDAV folks, though
<pauld> and Atom uses PUT and DELETE ...
Sanjiva: Change method name to string, values are same as HTTP spec
... Then introduce properties as needed
Jonathan: Yes, you mean the "full potato"
... Big question is do we want a full-featured HTTP binding, or is a more limited one OK for now?
<sanjiva> In my mind, doing a full featured HTTP binding begs for profiling. Because of that reason I would favor doing a more 80-20 HTTP binding which has extension attributes (in the whttp namespace) for those properties we deem 80-20. However, I am not going to fight against 80-20 vs. 82-18 split ..
DavidO: Want to make this real, and will peel however many potatos we need to investigate the parameters thereof.
Arthur: Simple case shouldn't be complicated.
Jonathan: If you say "PUT" that should default other properties appropriately
<sanjiva> I'm against defaulting serialization format - just make it an attribute and be done with it. We already have two perfectly good serializations for POST so it doesn't make sense to default to one.
Hugo: Full potato with clever defaulting is what we should examine as next step?
Jonathan: Sounds like...
- Summary:
+ HTTP Version
+ Content coding
+ Transfer Codings (Chunked encoding)
+ Caching (Vary, etc.)
+ Content Negotiation ?
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0019.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0083.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0027.html
DavidO: Certain common cases will cause Content coding not to get
(darn return key)
DavidO: ...used
... Two buckets - required and extensions. Transfer coding should be called out as really useful, if not required...
Jonathan: Clear that some of these things are needed, and the WG is very interested. Optimization stuff in some cases is less clear
... Need to figure out which of these things goes in, so buckets was an attempt to help with that.
... Do we need these in the core spec? (back to question above re: full-featured binding or not)
DavidO: Getting most of the HTTP functionality seems pretty straightforward to me...
Jonathan: Looks like adding 10-15 attributes, which in most cases would be omitted if you like the defaults
Glen: If people want to do these things, we should supply them. If not, we should point them at extensibility.
Jonathan: How many folks are psyched about implementing this?
Arthur: Setting all this stuff up doesn't have a lot of benefit because HTTP has negotiation...
... It's really a small optimization (saving round trips)
<dbooth> GlenD: If you're a cell phone, an additional round trip is a big cost.
Paul: +1 to Glen, mobile interactions are expensive, so optimization is good.
... Also, optimization in general (GZIP available, etc) is useful for big docs, many situatinos
DavidO: BEA has been deploying GET and POST with tweakable serializations for a while now, and while not everyone uses it, there is some definite usage.
... You need to know what uname/pw to use, for instance, when challenged for authentication. Much easier to do with WSDL than with runtime challenges.
<pauld> how to describe a service is protected by BA is something i'm asked for all the time ..
Sanjiva: May be properties which affect the programming model which can be gen'ed from WSDL - those things should be described in WSDL (access control, for instance)
... Rest as hints/optimizations are OK
Paul: Can we reuse this stuff with the SOAP HTTP binding?
Glen: SOAP HTTP binding is different than WSDL HTTP binding
Paul: Lots of useful work here.. why not reuse?
Glen: Would want to vet anything like that (adding properties to HTTP binding) past the XMLP group
Jonathan: Anyone +1 Arthur's concern about not going there with HTTP?
TomJ: +1
Jonathan: Most folks sound like they're up for some level of support for optimization. Can we get a more concrete proposal?
DavidO: Two things - 1) "full potato" proposal, 2) Transfer-coding as a first-class property (required in some cases)
Jonathan: Would be good to have proposed syntax for each of these by F2F so we can just vote away.
<scribe> ACTION: Dave Orchard to produce proposal for expressing Transfer-coding as an HTTP property for F2F
greek chorus: <silence>
Jonathan: If no proposals, we won't put 'em in...
<dbooth> [Meeting Adjourned]