See also: IRC log
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?
<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?
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
<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
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?
jjm: reading the SOAP spec...hugo, is webmethod *really* limited to GET, PUT, POST, DELETE? There are brackets which seem to allow for extensibility.
...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!
<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]
NEW ACTION: JacekK to add text on the purpose of endpoints and incorporate Kevin's breakdown to design/configuration/run-time
NEW ACTION: Marsh to add attribute vs. property syntax as an issue
NEW ACTION: Marsh to add UseWebMethodAsOperation shortcut syntax as an issue
NEW ACTION: DaveO to come up with list of HTTP functionalities to evaluate the coverage of our HTTP binding against.
PENDING 2004-01-08: Pauld to write up examples of schemas for thePrimer.
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.
DONE [.2] 2004-03-25: Hugo to look at the Handling Privacy in WSDL 2.0 for issues against our spec.
NO RESPONSE YET 2004-04-01: Marsh will get schema tf going.
PENDING 2004-04-01: Editors to update SOAP 1.2 Strawman proposal to take Part 1 changes into account.
MOVED TO EDTODO 2004-04-08: Editors: to incorporate Youenn's proposal [.2] with Jacek's modifications (
DONE [.3] 2004-04-15: DaveO to come up with a concrete proposal for indicating REST operations at the interface.
DONE [.4] 2004-04-15: Hugo will look at adding extensions to http proposal to allow arbitrary http verbs.