Web Services Description WG
22 Apr 2004

Action item review (see Summary of Action Items)

Members leaving: Jaeck and a slew of Michaels

Missive from XML-P about SOAP 1.2 using XML1.0 (vs. XML 1.1)

(vs. XML 1.1)

<JacekK> SOAP 1.0?

Er..

SOAP 2.0?

<JacekK> SOAP 1.2

marsh: WSDL is infoset based, serialization independant. Any issues about XML 1.1 and soap? no

Marsh: New issues: Schema out of sync, editorial issue against part 1

MarsH: New issue: Mark Baker thread about "which operation". Confusion reigns

Marsh: Lump this with issue 64, track separately, or hope it goes away?

Glen: There's a lot of little parts, etc. with lots of discussions, so we should address it. (E.g., it affects the HTTP binding.)

dicussion about issue 165, relationship between binding and endpoints

youenn: some binding relationships clear, others not

Marsh: jacek, does your text address this

JacekK: I think so, but perhaps it's not as clear as hoped

Marsh: Call for clarifing volunteers about bindings

JacekK: Is there general agreement? If so, I could write about the purpose of endpoints

Marsh: No known issues with JacekK's text. Youenn just wondering about how endpoints fit in. So more such text could flow right ot the eds.

dbooth: Is the confusion stemming from the name "bindings"? The term is misleading (not that we can change it).

pauld: [scribe failed to understand]
...endpoint properties getting confused with interface properties. Implementation issues vs. abstract thingies

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?

dbooth: it's application dependent
...(what is infrastructure vs. application)

glen reiterates and expands

JacekK: summing glen, we'll specify the layers but not what goes in them

Marsh: rabbit hole?

JacekK: we put aside issues with https while we settled what the layers are. Once we have the layers we can now revisit and figure out where various bits should go.

Marsh: But the layers are perspectival?

JacekK: In one sense, i.e., *what goes in* the layers. But the layer structure itself is fixed (in some sense).

Marsh: Our spec has different components with different xml representations. And we describe how properites are combined. How does this map into applicatoin vs. infrastructure.

JacekK: My "purpose of bindings" tretise should clarify this. I'm not describing the binding, I'm using it(?)

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?

JacekK: I intend to write up more stuff. Kevin can write up his.

Marsh: Can we combine these?

JacekK: Sure.

Kevin: I can help out.

<scribe> ACTION: JacekK to add this text and incorporate Kevin's breakdown

Marsh: And perhaps Kevin will become new owner

Issue 64

<JacekK> ACTION 1= JacekK. Add text on the purpose of endpoints and incorporate Kevin's breakdown to design/configuration/run-time

Marsh: DaveO put for a number of concrete proposals about the various components of a solution for this area
...Start with the WSDL for HTTP

<JacekK> ACTION 1= JacekK to add text on the purpose of endpoints and incorporate Kevin's breakdown to design/configuration/run-time

Marsh: Do we want to write something about WSDL and REST

<Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0053.html

Umit attended

DaveO explains first part of his 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> Hugo's proposal: http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html

hugo: I'm getting more confused as we discuss the issue

Marsh: Didn't hugo's proposal take care of this?

hugo: I think the SOAP1.2 proposal *is* general enough and not SOAP1.2 specific. So what's missing?

Marsh: Hugo's proposal explicitly addresses the generalization and concludes that it is fully general in the right way

Roberto and alewis: oops, we didn't read it closely enough. Sounds great.

Roberto: we should thus remove all references to SOAP to highlight the generality

hugo: The name makes it seem more specific than it is.

dbooth: we can clarify it in the spec

glen: or get XML-P to clarify it

Marsh: Say instead of "SOAP's webmethod", "WebMethod *from* SOAP"

there was much rejoicing

<hugo> SOAP 1.2 says: This section defines the "SOAP Web Method Feature".

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?

hugo explains his proposal

Marsh: hugo's proposal just reuses existing values for webmethod (GET, POST, PUT, DELETE)
...but the second part of hugo's proposal genrealize, but webmethod isn't extensible

hugo: and i think we shouldn't extend the webmethod attribute.

Marsh: So we can keep the proposals separate?

hugo: I think so.

Marsh: DaveO, agree?

DaveO: ok

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: yes, i object

ISSUE: Special syntax for Hugo's proposal

RESOVLED: Adopt hugo's proposal for webmethod

<Marsh> ACTION: Marsh to Add attribute vs. property syntax as an issue

<Marsh> ACTION: Marsh to add UseWebMethodAsOperation shortcut syntax as an issue

Marsh: Issue 54 remains

<Marsh> RESOLUTION: Issue 64 is closed!

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.

Farewell to JacekK!

<dbooth> [Meeting adjourned]