See also: IRC log
<dorchard> scribe: dorchard
<scribe> scribe: daveorchard
<scribe> scribe: dorchard
Chair requests any more issues
Chair then We'll start prioritizing
crowd: jocularity but no new issues
crowd compliments scribe on word selection
<scribe> chair: issue 6 discussion
chair asks for poll on importance of issues to folks
pushback on question..
Michael: write a paragraph on each issue
rebecca: tech question on issue #6 addresses the same across transports.
<scribe> Chair: Trying to get prioritization and support for issues
Jonathan: how about just ask for priority
DaveO: Concerned about meeting schedule if lengthy discussion of issues
Paul: prioritizing may help keep schedule because a contentious issue resolution could resolve other issue.
Rebecca, Jeff: haven't look at issues list, hard to prioritize
Jeff: how about just start doing the work
Jonathan: WSDL 2.0 issues on call are done by seeing traffic on the list
<scribe> Chair: question for each issue is high priority
Issue #6: high priority: 1
Issue #7: high priority: 0
Issue #7: high priority: 1
Issue #8: high priority: 8
Issue #9: high priority: 8
Issue #10: high priority: high priority: 6
Issue #10: high priority: 5
Issue #11: high priority: 3
Issue #11: high priority: 4
Issue #12: high priority: 3
Issue #13: high priority: 4
Issue #14: high priority: 0
Issue #15: high priority: 7
Issue #16: high priority: 5
Issue #17: high priority: 0
Issue #17: high priority: 1
Issue #18: high priority: 7
Issue #19: high priority: 1
Issue #20: high priority: 10
Issue #21: high priority: 9
Issue #21: high priority: 10
Issue #22: high priority: 3
Issue #22: high priority: 4
Issue #22: high priority: 5
Issue #23: high priority: 10
Issue #24: high priority: 6
Issue #25: high priority: 1
Issue #1: high priority: 8
Issue #4: high priority: 4
Issue 20,21, 23 are high priority
common theme is wsdl interactions
Gudge: every endpoint that I can send messages
to must have a service element
... Q: for anish: every endpoint that I can send messages to must have a service element?
Anish: don't like question. phrases different question.
Marsh: WSDL is central to ws, or is off to the side.
Discussion about knowing protocol, portType, service
Gudge: Imagine redirect, using new address and porttype, no service element
Anish: quoth the raven..... web services arch definition of web service
Gudge: get a reference is a common distributed meme
Anish: have to have a service reference
MarkN: architecture greater than WS-Addressing?
Marsh: is this about accomodating versus enforcing an architecture?
paco: This is about 23
Paco: if we have a more refined address construct, should this replace wsdl address construct?
marsh: 2 solution spaces: EPR into WSDL endpoint structure, OR re-use WSDL address constructs
3 options: nothing, EPR->WSDL, WSDL->EPRs
daveo makes brilliant point about sometimes it is not useful to have an "abstract" class and then 2+ different subtypes, just have the subtypes especially given the weakness of our schema language for refining cardinalities.
rebecca sometimes URLs are not sufficient: multi protocol, message queues
urls don't have interface information
rebecca urls don't have interface information
rebecca: ws-a assumes a priori wsdl knowledge
... services may have extensible information, such as services etc. that can't be accessed from addressing
... have to use WSDL
... properties are good, callbacks/pub-sub
marsh: when given an address, can always get WSDL
daveo: clarification: rebecca wants endpoint to at least have interface so operations are known.
pauld: here's an endpoint, how do I find out how it's described.
anish: serviceQName required.
... make serviceQName required.
pauld: making requiring doesn't solve problem
because they'll use "anonymous" qnames, or "any" content models
... should use metadata separately
... should use metadata separately, and then it won't be metacrap.
chair tries diligently to bring group back to whether issue 23 captures the meaning
pauld: this builds a dependency upon wsdl, and services outlive descriptions
marsh: what about versions of wsdl?
<pauld> worries about the one to many - there may be many ways of describing a single endpoint/service. putting a dependency between an EPR and a given version of WSDL is limiting
<pauld> daveo: suggests going to the whiteboard - doesn't understand the use-case
<pauld> anish and paco discuss discovery of WSDL from endpoints
<pauld> daveo: service has a WSDL, client emits a request based upon a WSDL
<pauld> rebecca: no, you start with a URL
<pauld> ... refernence may have come from somewhere else
<pauld> jeff: programmer finds URL on side of the bathroom wall
<pauld> rebecca: need to know a lot more than just the URL for interface, security, etc
<pauld> gudge: all i have is a URI?
<pauld> jonathan: this is only one of a number of use-cases: could start with WSDL first
<pauld> daveo: you want every web service to provide such a 'discovery' mechanism
<pauld> daveo: discovery of meta-data should be optional
<pauld> daveo: discovery is out of scope!
<pauld> jeff: interoperability is the issue here
<pauld> jonathan: i have a URI, i know it's a web service. what can i do?
<pauld> ... not much! with just a URI there isn't enough information
<pauld> rebecca: that's why just a URI is such a problem
<pauld> gudge: you need a description. i don't understand why a reference needs to carry this information
<pauld> rebecca: what about if you're not using soap
<pauld> markn: (1) you start with a URI
<pauld> ... (2) or you start with an EPR with addr, protType, svcRef embedded
<pauld> jonathan: should we allow multiple portTypes in an EPR?
<pauld> rebecca: but we also have multiple bindings, etc
<pauld> jonathan: other reasons not to include this information, bandwidth, etc
<pauld> ... you agree that in some cases you don't need such information?
<pauld> anish: no, should we allow you to just pass partial information?
<pauld> JT: so we should make it mandatory .. sometimes!
<pauld> jeff: if you want to provide an interoperable solution .. should you be required to include or at least be able to get that information
<pauld> ... as a service provider, you probably have all that information - engineering trade-off, so provide a mandatory way to get that information. which is how other distrib systems have solved this
<pauld> ... so it's either the info is readily available or requires another round trip
daveo: I agree that there is often a need for a metadata discovery service.
<pauld> gudge: to me this is not about enforcing a particular architecture, but about enabling other architectures. i'm unconvinced that it is a requirement that the description should travel with the address
<pauld> markn: (hat off) a URI doesn't exist in a vacuum. an EPR has context, and maybe data could be different depending on where it's going to be used
<pauld> rebecca: is including a portType is too much information?
<pauld> gudge: an address may not be dereferencable
<pauld> paco: address is a runtime construct, service description is not. i think you're making meta-data required at runtime
<pauld> gudge: you may elect to build a system without a description
paul: argument is about whether description exists or not
<Gudge> I *think* anish is saying that 'in order to be a web service, you MUST have a service QName'
paul: version 2 of wsdl comes out, then identifers would change
<scribe> New Issue: multiple description formats
<pauld> paul: i think discrovery is orthognal to addressing: i may have multiple descriptions some of which may be WSDL 1.1, 2.0, RDF, whatever and i'd like my customers to be able to negotiate the description format that suits them (not me as provider of a service)
<pauld> daveo: cites the way the web works - you don't know much from http://.. does it support HTTP 1.1, PUT, GET, no spec says "GET" is a default method, but it just works. addressing system just "works" by having discovery, negotioation as optional features
<pauld> anish: this is slightly different. HTTP has a constrained interface, but Web services are more open.
<pauld> rebecca: dave you described informal standard behavious. i think for interoperable
<pauld> .. you need to be more rigerous
<pauld> paul: is the web not interoperable?
<pauld> daveo: why should i have to give you meta data you may already have?
<pauld> rebecca: extensions may change the way a service works (e.g. https)
<pauld> rebecca: you could cache meta-data
Rebecca: EPR is more than just an identifier
DaveO: There is a difference between an
identifier for a service, and a description of service.
... I don't want to mandatorily couple the description to the identifier
pauld: Where will the world be if the interface description was coupled.
JT: imagine cell phone world with this.
... cell phone requests something and needs to create callback, must he include the callback interfaces in the address
... cell phone wants minimal approach
... wants minimal address
jonathan: If I just have port type and service QName, that doesn't require WSDL to be publicly available, does that also require WSDL:Location in? Falls into discovery bucket
Paco: measured approach, can layer on things later
Rebecca: wants this to work in all cases
Paco: will force people to use other technologies if WS-A is too heavy. WS-* is regularly mentioned as being too heavy, so keep it light.
<Zakim> pauld, you wanted to provide a use-case for when WSDL is not discoverable
greg: layered approach. What about policy? it's going to be removed.. What'll it be? Layers or monolithic
<Zakim> dorchard, you wanted to say if WSDL is in client, then why is Service QName is requred?
DaveO: I assert that if the client doesn't have the WSDL, the ServiceQName is insufficient, and if the client does have the wsdl, then the Service QName is unnecessary
Anish: if client has WSDL + EPR.....
<scribe> ACTION: Anish to answer why Service QName is required if client has WSDL + EPR + engaged in conversation.
Chair suggests 4 options: 1 require metadata in all EPRs; 2) require MD on a use-by-use basis,; 3) no MD constraints; 4) MD + Address optional. 3 is the current state
Chair suggests 4 options: 1 require metadata in all EPRs; 2) require MD on a use-by-use basis,; 3) no MD constraints, address required; 4) MD + Address optional; 5) Address optional, MD required. 3 is the current state