See also: IRC log
<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
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: 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
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
Gil: "literal" must be defined in a broader way than service
<dug> darn - gil is taking my comment :-)
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?
<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> agreed
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
<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
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?