See also: IRC log
<dbooth> Scribe: TonyR
minutes approved
skipping action items
reminder - register early and often for Mountain View and Berlin
<pauld> ACTION: DaveO to produce HTTP binding section for primer [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action01]
<pauld> ACTION 1 = daveo to produce HTTP binding section for primer
DaveO: need someone to propose text to close LC28
Charlton: volunteers to propose text
<dbooth> ACTION: Charlton to propose text for LC28: HTTP Transfer Coding and 1.0, per Asir's proposed resolution [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action02]
DaveO: volunteers to write up response to LC47
<dbooth> ACTION: DaveO to propose text for Issue LC47: describing the HTTP error text for faults [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action03]
DaveO: resolve by allowing a list
of separatorchars
... looking for volunteers to write up this solution
Charlton: is volunteered to take this on
<dbooth> ACTION: Charlton to propose solution for Issue Issue LC69a: XForms comments on (WSDL) Version 2.0 Part 3: Bindings (a): XForms comments on (WSDL) Version 2.0 Part 3: Bindings (a) [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action04]
DaveO: any objections to allowing
the separator char to be specified
... none
DaveO: recalls this being included already - why was it dropped? Anyone remember?
Arthur: yes, we had it
<dbooth> ACTION: DaveO to figure out when/why multpart/related got dropped from HTML binding section [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action05]
Arthur: can find multipart form, not multipart related
DaveO: will resolve it
DaveO: namespace name was going
to be ignored
... speaking as BEA: seems like a bad idea
... describing an earlier proposal for handling namespaces in
urls
<pauld> notes xforms appears to support a variety of multipart methods: http://www.w3.org/TR/xforms/slice11.html
DaveO: we have a choice: contrain
elements to be unqualified, or explain how to serialise
them
... comments? suggestions of other solutions?
omnes: silence
DaveO: suggests qualified names should be serialised, and say how
Arthur: why not serialise it as XML?
<dbooth> ACTION: DaveO to dig up his old proposal for URL-encoding namespaces, for Issue LC77a: Namespaced elements and urlformencoded [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action06]
DaveO: HTTP Get does not allow a body
<dbooth> Arthur: XPOinter has a way of putting Qnames on a URI.
Arthur: XPointer has a way of putting QNames on a URI - has a syntax for including namespaces
<dorchard> #xpointer(xmlns...)
Arthur: XPointer uses schemes
DaveO: other comments?
omnes: none
DaveO: as BEA: will be implementing full WSDL 2.0 spec, including HTTP binding
Arthur: renewed interest in REST
DaveO: wrote up what a REST implementation (Yahoo search API) in WSDL would look like
<dorchard> http://www.pacificspirit.com/blog/2005/03/02/yahoo_search_web_service_in_wsdl_20
<dbooth> Bijan: DAWG will also be using the HTTP binding.
DaveO: the WSDL HTTP binding does
a good job
... there are scenarios where it doesn't work well - when HTTP
operations are spread across many URIs
... few operations, many URIs is not so easy - bulky and
complex for something that should be simpler
... binding is fine for parameterised operations
Arthur: can we keep the binding?
<gdaniels> Sonic has no immediate plans to implement this portion of the spec.
DaveO: LC77b is an announcement that MS won't support this section. Any other companies wish to disclose their plans?
Arthur: IBM a strong supporter of SOAP binding. Intend to support lighter technologies such as PHP
DaveO: Yahoo sent a comment to the list
Sanjiva: Apache will be supporting both bindings
<pauld> notes we're chartered to deliver bindings for "HTTP/1.1 GET and POST requests."
DaveO: HTTP binding has support from at least a few vendors, and it's in the charter, therefore close with no action
<sanjiva> ARGH! Pressed the wrong button ...
<sanjiva> calling back
<sanjiva> sorrry
<dorchard> sanjiva, did you want to be on the queue?
DaveO: anyone opposed to closing the issue with no action?
omnes: no opposition
RESOLUTION: LC77b (drop HTTP binding) closed with no action
Roberto: HTTP binding covers many
cases
... REST not particularly well served by HTTP binding as it
stands
... perhaps the three cases should be covered by separate
bindings?
DaveO: interesting - perhaps we
need an HTTP core + ...
... perhaps the core could be used directly by SOAP
binding?
... perhaps they could be separate documents?
... maybe the raiser of LC77b might support a subset of the
binding?
Roberto: charter references WSL 1.1 - can we decouple what is ready from what will take more work
<pauld> 'REST' APIs such as del.icio.us actively encourage client URI manipulation
DaveO: difficult to use WSDL to describe construction of a compound URI
Sanjiva: if we can support Yahoo, Google, Amazon, it is probably sufficient
DaveO: we seem to be inventing
technology, rather than standardising existing
... lack of proposals from the community
... is there a proposal of where to divide the binding?
Roberto: hard to draw the line
accurately
... we need to describe the HTTP binding carefully
<scribe> ACTION: Roberto to suggest where to divide the HTTP binding into pieces [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action07]
<dbooth> ACTION: Roberto to draft proposal to split HTTP binding into 3 bindings [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action08]
<pauld> ACTION- 9
<scribe> ACTION: DaveO to query MS whether they would support part of the HTTP binding if divided [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action09]
<dorchard> fault definition SHOULD NOT go against
<dorchard> the definition of the HTTP error codes
DaveO: perhaps this issue can be addressed by a simple sentence
DBooth: should that SHOULD NOT be a MUST NOT?
<dorchard> the definition of the HTTP error codes
<dorchard> the definition of the HTTP error codes
TomJ: let's keep it as SHOULD NOT, so it is not a testable assertion
<dorchard> The fault definition SHOULD NOT go against the definition of theHTTP error codes, see RFC 3205.
<scribe> ACTION: editors to include a sentence stating that fault definition SHOULD NOT go against the definition of theHTTP error codes, see RFC 3205. [recorded in http://www.w3.org/2005/03/24-ws-desc-minutes.html#action10]