Web Services Description F2F - Thursday -- 19 Jan 2005

<Marsh> Scribes: Paul, ?, DaveO, Arthur

<scribe> Scribe: pauld

<Marsh> Hugo.Haas is the line to Melbourne?

<Marsh> Hugo.Haas holds Arthur, Tom, Michael, Glen, Tony, Jeff, Anish, Youenn, DaveO, PaulD, Marsh, Paco Curbera, Steve Winkler

<scribe> Chair: Jonathon Marsh

<scribe> Meeting: Web Services Description F2F, Jan 2005, Melbourne Hosted by BEA

Agenda Bashing

marsh: we've still lots of last call issues ..
... schedule - we're not going to close them all this F2F and we're going to have to go to the director

<Zakim> hugo, you wanted to talk about justification to the Director and LC status

hugo: we do have a few issues, and some new ones still arrising, so we have to go to the director. we have some in relation to the addressing work and async. we have formal objections, etc. what does the WG think about aligning ourselves with addressing rather than racing to meet our schedule
... do we want to rush something out or produce something more appealing to users

dbooth; why would someone want to adopt WSDL 2.0. do we push it out as it stands or create something better targeted at addressing

marsh: even if we ignored addressing, we'll still have to coordinate with them. difficult to ignore addressing procedulary (sp?)

glen: it's hard to ignore addressing given the overlap. it's going to happen anyway.

paul: we're at the point were we have to make this kind of decision

glen: we have tons off issues which aren't addressing based

paul: someone else might come along and have similar difficulties ..

amy: ws-chor also gave us feedback, if we call out other WGs we might have to include them

marsh: addressing has raised a lot of issues

tom: how can we meet our current schedule?

marsh: close all our issues here
... we could divide the WG up and deal out the issues

tom: we could just close down and ship
... group should change it's thinking into 'we're shipping'

dbooth: a better spec will get adoption

tom: so would shipping now

jeffm: my experience is we can't rely upon promises to work in a certain way

arthur: jonathan's made an effort to achieve concensus. let's empower him now to be more dictatorial

marsh: you guys can help me!
... progress would be helped by timely completion of AIs. we still have many outstanding, e.g. fatal faults ..

paul: lets put a time on AIs and drop them if they dont' get delivered on time?

marsh: yup. we tend to rely upon people who are overworked, so maybe we should spread the load

hugo: what's the conclusion of this discussion?

marsh: inconclusive. we have to just work faster. no formal change in how we're going to work
... umit has been talking to henry about his LC comments. TP could be a good time to meet him F2F about this issue if it doesn't resolve quickly
... soap 1.1 binding note is fairly small. no open issues/actions on that. makes sense to wait before publication due to dependence on other documents
... and the primer?

dbooth: we got more comments before than after publication. we still need to solicit help.

marsh: let me know if you need telcon time and we'll make it happen

kevin: (to dbooth) we can discuss this on our regular call
... what's out time frame for publication?

marsh: ideally by the end of the TP?
... primer doesn't really go into CR, so we can synchronise publications at PR

<dbooth> ACTION: dbooth and KevinL to scope remaining primer work and identify who needs to supply what advanced topic sections

marsh: media type editors encouraged to answer LC comments and inform the WG via email

agenda rearranged for Roberto's benefit

Single interface per service - Issue LC73/LC75n

roberto: we made a descision to have a single interface per service, however we've had comments that this is not realistic for management interfaces, meta data services, discovery and other motivations
... Versioning is an important use-case.
... [continues to outline proposal]

tom: the service is only a set of angle-brackets that collects endpoints. how do i know which one i'm using?

glen: it's just like WSDL 1.1

roberto: you can select the service you like based upon information available, e.g. which binding you want

tom: so it's a more interface centric approach which i prefer

glen: we had a long conversation about this.. i want to keep the status quo with the service element. association can be best met by another mechanism, e.g. "service group" or other meta-data

<alewis> note that we have last call comments asking for multiple interfaces per service from Anne Thomas Manes, Jeffrey Schlimmer, and Rich Salz.

tom: i'd accept this proposal over "service group" or any other radical rearrangement. i'm firmly opposed to multiple interfaces for a service. but i want to answer these use-cases, so i'm open to roberto's proposal

arthur: there are 2 kinds of bindings: generic and ones which specify an interface

<Roberto> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0094.html

kevin: what's the effort to explore this given we now have more evidence and use-cases to support the proposal?

<TomJ> Proposal URL: http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0094.html

paco: i understand you have discussed this long ago. it's a nice separation of concerns. there are other better ways of describing an association.

jeffm: if we reopen this, then people can make whatever proposals they want

<alewis> that's not what roberto said!

roberto: i'm not adocating going back to how things worked in WSDL 1.1. other specs layered on WSDL 2.0 would tighten up the relationship

<alewis> yes, that looks right ....

dbooth: adding this may increase adoption

<Roberto> I also said that endpoints that implement the same interface would be functionally equivalent (unlike in WSDL 1.1)

glen: there are other ways to achieve this functionality
... (to roberto) would service group or target resource satisfy your concerns

roberto: we shouldn't abuse the word "service" we need to think about what "web service" means

glen: i don't think a web service is a group, it's a single 'type' of thing ..

<prasad> I support Service group idea instead of overloading one service for multiple interfaces. KISS for the most usable case

arthur: like status quo. it's cohesive. and there are other ways of expressing relationship. the group as a whole already agreed upon these clear semantics and don't want to reopen this issue

daveo: i'm torn. BEA like the status quo - not least it helps tooling. but what do you do about the multiple interface problem?

tom: there already is a syntax grouping

jeffm: i'm with arthur. we've already had the debate and there is no new information. look at the record. unless we can resolve "what is a resource", "what is a web service", we're not going to make progress here

STRAW POLL

do we reopen the "single interface per service" issue?

marsh: 10 no, 5 yes, 6 abstained
... we've not going to reopen this issue

<scribe> ACTION: Editors to call out the difference between WSDL 1.1 and 2.0 in this respect

dbooth: we should offer an alternative method for expressing this relationship

<dbooth> There are at least three alternatives: 1. Group in the same <description> element; 2. Group in the same targetNamespace; 3. Separate documents that happen to use the same endpoint address

marsh: no objections to closing issue LC73/LC75n

<umit> There is another alternative. Add an extension that links all services that represent different views of the same thing together.

RESOLUTION: close last call issues LC73/LC75n with no action

<dbooth> Good point umit

RDF is the answer. what was the question?

<Zakim> asir, you wanted to ask clarification

LC89k

asir: i don't understand the relationship of this to the inheritance model

<scribe> ACTION: editors to call out the difference between WSDL 1.1 and 2.0 in respect to single interface per service, and indicate alternatives

RESOLUTION: close last call issues LC89k with no action

<bijan> On in a minute I hope

BREAK

<bijan> Or not :(

- DRAFT -

Web Services Description F2F - Thursday

19 Jan 2005

Attendees

Contents

Agenda Bashing

Single interface per service - Issue LC73/LC75n

LC89k

Summary of Action Items

Scribe.perl diagnostic output