Web Services Resource Access Working Group Teleconference -- 23 Jun 2009

<trackbot> Date: 23 June 2009

<Bob> test

<Bob> trackbot, start telecon

<trackbot> Meeting: Web Services Resource Access Working Group Teleconference

<trackbot> Date: 23 June 2009

<Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0050.html

<Bob> scribe: Paul Nolan

<Bob> scribenick: Paul

Geoff: should we eximine vacation plans?

Agenda agreed

No objections to approving all 3 F2F minutes

Minutes approved

No objections to closing incoporated issues in snapshot

new issues

7013

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7013

issue accepted

7014

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7014

issue accepted

7015

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7015

Geoff: associated with 6398 - wich makes identification of message ambiguous

Gil: Re formal objection. Does this issue address the issue?

Geoff: Objection remains if 7014 is not satisfactory

Bob: Objections help air issues

Gil: Feels objection was not originally raised as a technical issue

issue accepted

7039 new issue

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7039

Doug: EPR identifier. Problem is ref params can be mis-used
... 1) Remove
... 2) Clear explanation in spec

li: with no identifier how is sub-mgr able to identify message?

issue accepted

Geoff: Mode proposal has been circulated

<gpilz> http://www.w3.org/2002/ws/ra/wiki/Use_Cases_for_6401-6661

Gil: 6401 use cases complete

<Bob> acl li

Bob: next step on 6401 is to develop requirements

Gil: would prefer to produce some proposals

Wu: Agrees with Bob - we should gather more requirements
... will try to develop requirements

<Bob> ACTION: Wu and Team 6401, develop detailed requirements extracted from usecases ref 6401 [recorded in http://www.w3.org/2009/06/23-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-77 - And Team 6401, develop detailed requirements extracted from usecases ref 6401 [on wu chou - due 2009-06-30].

Doug: Could proposal owners explain how arrived at their proposals

<dug> ... in the wiki

issue-6975

Geoff: Have examined how a literal resource can be defined.

<asir> sorry we got cut off

<asir> we are dialing back in

<Bob> resolution: All agreed

<asir> all agreed with geoff!

Geoff: Can definition simply say that the service defines resource

<dug> darn - gil is taking my comment :-)

Gil: "literal" must be defined in a broader way than service

Doug: could schema be used

<asir> they are service-specific, similar to HTTP

Geoff: With schema how can client and service have different understanding of the resource definitions?

Doug: need a way for service to advertise what is valid XML for a create request

<asir> well ...

Gil: issue described by Doug sounds like 6401

<asir> it is upto resource owners to advertise resource descriptions

<asir> this is orthogonal to transfer

Doug: "server knows" approach. How does the client know?

<gpilz> what issue are we discussing?

<Bob> 3975

<Bob> 6975

<asir> Transfer is a generic protocol

<dug> "there's no interop issue here" ?

<dug> no I quoted him :-)

<dug> correctly

<asir> that is what i heard

<Bob> aggreed

Geoff: server defines and advertises its resource definitions

Gil: Sees the use case where client and service are tightly coupled. However there are services that are not data aware
... We could remove reference to literal resource rather than define it

Doug: Removing literal resource definition means all data becomes opaque
... How does the client know definition of instructions available

Geoff: already feels that Transfer client needs additional information to function. A link between client and service must be defined.

Doug: feels there are cases when a client may be able to either send an instruction or some literal data. Client needs to know the difference.

Geoff: a policy mechanism to help service sounds useful. However it should only be a hint not strict definition

issue-6413

<dug> http://www.w3.org/2002/ws/ra/9/03/Issue-6413-2009-03-25.html

Geoff: can we take a higher level look at the issue
... what are the real goals?
... is it to force WS-MAN ti implement frag support?

Doug: is it not about WS-MAN

<asir> Doug mentioned - clear direction to the industry (that includes WS-Man

Doug: it is for interop and industry direction

<Yves> I wonder if the WG should work on a single spec instead of five, to avoid "proliferation"

<dug> yves +1

<dug> would help guarantee people make sure they all work together

Bob: mentions that DaveS feels this issue may lead to multiple frag specs being developed

Geoff: If we define a good frag spec then it will be used and become adopted
... we should not fore people to use a frag spec they do not want

Bob: how does WS-RT relate to frag support in WS-MAN?

Doug: very simplar
... new proposal is different from WS-RT
... header / body main diff.

Bob: if frag support were in WS-T what would be left in RT?

Doug: other things do remain
... aspect 1) framework for frag support. 2) definition of dialects which are open for new definitions.

Yves: do not need to support frags for WS-T, or vice versa.

<Geoff> agree with Yves

<Geoff> +

Asir: there are many differences between proposal and WS-MAN

<Yves> for the minutes, to get frags adopted you need a good spec and good implementations, more than sticking it in any other spec

<asir> +1 to Yves

<asir> a W3C spec that describes frag only is a clear direction to the industry (including WS-Man

<dug> would we ever say that?

Geoff: composability is important. This is is made worse by proposal

Bob: is it felt a good independant frag spec would encourage adoption?

Doug: a lot of spes build extensible support into main spec.

Bob: is frag independant or part of WS-T?

- DRAFT -

Web Services Resource Access Working Group Teleconference

23 Jun 2009

Attendees

Contents

new issues

issue-6975

issue-6413

Summary of Action Items

Scribe.perl diagnostic output