glen: can't you have one framework for both things. F&P discussion ensues

pauld: Sure, but some of things youenn were asking for in interface seemed to be implementation issues

glen: both are valid

daveo: (?) agree

<pauld> sorry, been a long week!

glen: You might want to specify properties of all realizations of the abstract interface
...even not yet exisiting ones

<dbooth> One person's interface level is another person's implementation level. Whether you view a particular feature as being pertinent to the application, or merely an infrastructure detail, is a matter of viewpoint.

glen: lines blurring, no hard line

Marsh: If it's observer dependent, what should we do? Supply persepctive info? Leave it to the observers to figure it out?

Kevin: Hesitate about specifying what goes where (infra or application)
...The WSDL parts area associate with different lifecycle, interface: design time, binding: something time, endpoint: runtime?

dbooth: we should expound on this a bit

Marsh: In primer?

Kevin: in the language descriptoin

dbooth: yes. Could have extra material in primer.

Ah. Binding is *configuration* time.

Marsh: Not clear consensus on breakdown. Solution: Put something in the spec and go back to see if we want a specific marker in the binding re: https
...How do we get to resolution?
...Put it back on the stack and see if it lines up with JacekK's text or write something new along Kevin's proposal?

DaveO: add a "location" attribute
...you need a relationship between binding and interface, typically done at operation level, but you want to get *all* the operations in one fell swoop. Add an interface attribute for this.

[More from dave. A lot]

DaveO: Response to Roberto's pushback. A developer will want to support inputs and outputs, not just the method. The way this will come out is with method level inheritence.
...So, there isn't a lot of reuse gained by only using a method name isn't high, and the cost of reinventing inheritence isn't worth the benefit

Roberto: fair statment of *one* of my concerns. I have two more.
...Problem with these operations in the abstract: they may be REST methods or Atom ones. So we must clarify these.
...Third point: This proposal introduces a relationship between bindings (e.g., extending bindings with other bindings). This seems really big and we should try for the general design (since other bindings might benefit from such relationships)
...Point 7 is also relevant and interested. Does webMethod solve the issue?
...Take the stockquote example, that interface could define its own get operation, and that operation would have a webMethod=GET annotation.

DaveO: Interesting. We've discussed that internally, and this actually connects to the SOAP Webmethod issues. Originally the proposal was monolithic and addressed both issues.
...What I'm hearing, is that one might solve Issue 64 with the SOAP 1.2 webMethod support

Roberto: I don't know why it's SOAP 1.2 specific, but generally, yes

DaveO: We say it's SOAP 1.2 because of how it seemed to fit into the charter.

<alewis> +1 to generalization

Marsh: Can we generalize it along Roberto's suggestion?

<umit> +1 to Roberto's suggestion

DaveO: I think it's possible and congenial. We should look at the SOAP1.2 proposal and look for where it's generalizable.
...Whether the WSDL operation names are the http method names *or* whether they are the application defined names.
...that's the crux

Sanjiva: we don't prevent someone from defining http verbs to be operation names?

DaveO: We don't *preclude* it, but WSD-WG seems the right place to define the meaning of the "HTTP operations", because from the individual app perspective, they can't affect the meaning of the HTTP verbs

Sanjiva, Roberto, DaveO rapid discussion.

<dbooth> Sanjiva, but I think the point is to have the semantics of those operations be uniform *across* applications -- not just defined by each application.

alewis: Strong agreement with Roberto. I propose we go ahead and explore this generalizatoin of SOAP1.2 webmethod to a general webmethod. Let's pospone 64 until the explanation

Marsh: but Mark Baker would like a syntactic shortcuts for this
...but that's distinct from getting the functionality in.

DaveO: I tried to write up some syntax bits in the SOAP1.2 WebMethod proposal email. I have looked over hugo's Apr 14 proposal. Are these aligned?

hugo: One thing DaveO has added is an attribute on binding "useWebMethodOperation" which seems neat. Otherwise, they seem the same

Marsh: and that's just syntax

Down to some syntax decisions?

DaveO: We should realize this feature we need some way to set the property, so why not a WebMethod attribute on interface.

Marsh: That's just synshortcut

DaveO: How do you set the property?

Marsh: We have a generic syntax.

Hugo: the property value is a uri

glen: no, it's just a string

Marsh: Sounds like we converging on adopting Hugo's proposal with some issues: attribute for setting the property from interface, another for stuff in the binding, adding put and delete (which is in hugo's proposal), and then Issue 54 (extensibility)
...all but the last seems independaent.
...If we have the WebMethod property as just an enumeration, then we preclude using an URI and that sort of extensibilty. So we'd have to invent something to handle that.
...Original proposal didn't allow arbitrary valuess in the webmethod property?

jjm: reading the SOAP spec...hugo, is webmethod *really* limited to GET, PUT, POST, DELETE? There are brackets which seem to allow for extensibility.

Marsh: Aha!
...Need to investigate that more. Moving forward: Are we happy to adopt Hugo's proposal, i.e., the WebMethod characterizatoin and then adding PUT and DELETE (with the proviso that we may add more later).
...Any objection to using Hugo's proposal as the status quo for solving issue 64

Umit: I like the proposal, but lets just use our existing syntax

Marsh: I'm trying to move forward. If there is no objection to using the property syntax I'll not record an issue. Any objection.

DaveO: no one thinks there's a need to describe http operations as interface operations?

Marsh: Roberto's and amy's concerns seemed compelling, but if we've provided enough to support what you want, we can publish your text in w3c space
...Slew of issues wrt HTTP binding. High level overview: Full featured binding vs. a minimal binding with extensibility covering the issues
...TomJ sez: no new features in the HTTP binding!
...other people

<WilliamV> +1 to simple

<Roberto> simple wins

<asir> +1 to simple

Sanjiva: +1 for simplicity

DaveO: What's the difference between simple vs. full featured? What does it look like? What complexity is introduced?

Marsh: Let me restate: I've listed a bunch of issues, are people in favor of most of those or just a few of those?
...Is the issue list on features sufficient to make a judgement about the desirability of these features?
...Do people have use cases today for judging the desirabilty of these features?

DaveO: We have a lot of internal discussion but have reached no conclusions yet. What are the underlying features of 2616 and stuff layered on it?

Marsh: yes. What is the *set* of underlying functionalities that are intereseting to describe?
...If we think we haven't caught that set, perhaps we should have a task force to consider the binding as a whole and come up with a coherent proposal.

DaveO: Ah, sounds good.

Marsh: Like to develop a rationale for what goes in or is left out of the binding.

DaveO: I'll take an action to write up a list of the functionalities as a starting point.
...Is cache-control interesting?

JacekK: Yes, cache-control is. We should try to support things that are architecturally important. So we should aim for a full featured binding wrt significant architectural issues.

DaveO: Describing cache-control doesn't do much for you since HTTP requires certain things of c-c. What we should aim for is what's *variable*. So while chunking is an optimiation, it helps to know where its in effect since it isn't always?

JacekK: I want to describe things like this operation is cachable but I agree that non-optional things need not be described in terms of being supported.

<scribe> ACTION: DaveO to come up with list of HTTP functionalities to evaluate the coverage of our HTTP binding against.

DaveO: next week is better to talk about it, so I'll try to get something done early enough for next week.

Marsh: If it comes quick, goes to top of agenda, otherwise work on SOAP binding next week.