Web Services Resource Access Working Group Teleconference

19 May 2009


See also: IRC log


Ashok Malhotra, Oracle Corp.
Asir Vedamuthu, Microsoft Corp.
Bob Freund, Hitachi, Ltd.
David Snelling, Fujitsu, Ltd.
Doug Davis, IBM
Fred Maciel, Hitachi, Ltd.
Geoff Bullen, Microsoft Corp.
Gilbert Pilz, Oracle Corp.
Katy Warr, IBM
Li Li, Avaya Communications
Paul Nolan, IBM
Tom Rutt, Fujitsu, Ltd.
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
Bob Natale, MITRE Corp.
Jeff Mischkinsky, Oracle Corp.
Mark Little, Red Hat
Paul Fremantle, WSO2
Prasad Yendluri, Software AG
Ram Jeyaraman, Microsoft Corp.
Ranga Reddy Makireddy, CA
Sreedhara Narayanaswamy, CA
Vikas Varma, Software AG
Bob Freund, Hitachi, Ltd.
Li Li


<trackbot> Date: 19 May 2009

<Bob> Scribe: Li Li

current agenda

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

geoff has a new finished AI for the agenda?

agenda accepted

<dug> If its Tuesday this must be Belgium

approval of minutes

UNKNOWN_SPEAKER: minutes approved w/o objection

f2f schedule

geoff: when to indicate decision?

bob: we'll discuss it today
... hope to get one of mode and t/rt merge clean in f2f


bob: how about next week for snapshot review?

geoff: yes

6401 team

gil: consentrate on relation between raw and wrap notifications

try to schedule a call to go over it

bob: any fundamental issue?

gil: no, more one detail...

bob: estimate of time?

gil: we're still brainstorming

consolidation of mode proposals

geoff: they are on wiki, runtime policy for doing mode?

<dug> I think Bob was talking about using a namedPolicy

Bob: explain about how to use policy in subscribe

gil: wiki lists all choices so far - three options
... Bob pointed out that there is a way to simplify policy intersection

as a choice to make during deployment time, which may work for small devices

<dug> scroll down to the PolicyReference stuff: http://www.w3.org/TR/ws-policy-attach/#ExternalPolicyAttachment

Bob: we can profile policy to restrict its complexity, and use that policy to replace mode

asir: someone needs to make a proposal and show how it works on small devices

dug: Should Chris should create it on the wiki?

<Bob> ACTION: Dug and Ashok to write up a constrained policy mode proposal [recorded in http://www.w3.org/2009/05/19-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-65 - And Ashok to write up a constrained policy mode proposal [on Doug Davis - due 2009-05-26].

new issues

any objection to openning them?

katy: 6920 missed

bob: objection to it?

no objections



<Wu> 6429 was updated with the agreement from Gil

<dug> I think this is the latest: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0149.html

<Wu> Li: As far as we can see, we seemed reached concensus on issue 6429 on standard wrapped interface

bob: any objection

<asir> Vow!

bob: no object and 6429 is resolved

<asir> Thanks to Li for driving consensus on 6429!!


bob: any objection...no objection


bob: objection to resolving...no objection and resolved


gil: no proposal but it's obvious for editors

bob: do we need detail proposal?

geoff: ok with it

bob: objection to resolving it...no object and resolved.


<Wu> Li: the purpose is to hide some operations from the tool. Can we have two set of WSDLs, one for advertise services, and one for generating code

<gpilz> +q

gil: agree with dug and explain some use cases regarding ws-e

geoff: have concerns about losing info on operations by using policy
... such as security
... using transfer to get may have different security requirements

katy: implicit doesn't exclude explict
... security may be addressed by ws-policy, some pattern may be created.

<Zakim> asir, you wanted to ask a question of clarification (when appropriate)

asir: drop all wsdl but use policy?

dug: yes but not concrete yet

<asir> Thank you recognizing a Microsoft use case!

dug: geoff raises some valid use cases
... rm is indicated by policy assertions, which may be a pattern to follow, we can investigate them

<asir> we lost bob

<dug> oh no

<Bob> oops

<asir> Yves?

<Bob> I am back

<asir> Cool!

gil: attaching policy to operations worth more thinking...

katy: 6721 is related to find patterns to attach policy assertions
... RM can be used to study our approach

<gpilz> an app-level WSDL, a infrastructure WSDL, a Notification WSDL . . .

<gpilz> ?

dug: explore Li's idea, using mex to retrieve application wsdl

<dug> and retrieve implicit operation's wsdl

asir: our assertions define security features, define interrelation between domains

<scribe> new policy has to consider such compositions

<asir> Here is a link on how to think about RM as an example ....

<asir> http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112/#interrelated-domains

<Bob> ACTION: Li and Dug to explore proposals and start a thread on this topic [recorded in http://www.w3.org/2009/05/19-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-66 - And Dug to explore proposals and start a thread on this topic [on Li Li - due 2009-05-26].

daves: composing operations from different app into one port type
... what is our strategy to deal with it?

asir: wsdl doesn't mention any rules
... only ws-policy attachment has some rule, but only to wsdl 1.1 not wsdl 2.0

gil: i caution using ws-rm because it has some constraints

<asir> +1 to exercise caution!

gil: that do not apply to transfer
... we need to be careful not to over generalize

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0159.html


dug: add an appendix to illustrate how to use transfer on subscription

geoff: it's non-specific and good
... all properties returned by get?

dug: not necessary

geoff: what if you can't put all properties you get'ed

dug: that's valid but is generic to ws-t

geoff: is this a good use of ws-t?

dug: i think so

geoff: need more careful design

dug: ws-e has read-only properties but should be left to ws-t to decide

geoff: what about optional headers and policy
... how to use ws-t to modify them?

gil: it's too simplistic to say not puttable is just a transfer issue
... we are profiling ws-t if we define which field is writable?
... it's an extension to ws-t

dug: it's up to the extension to decide which properties are writable
... it's not a profile but a use case of ws-t
... we need to improve ws-t to cover it if necessary

bob: leave it and move on?

geoff: still thinking and agree with gil
... not convinced yet and need more time to think
... need more words to clarify it

bob: more time to think?

gil: i create a new issue on what happend if server is unable to honor a put request

asir: action not supported?

<gpilz> the problem is not the action

<gpilz> it's what you tried to do with the action

<gpilz> another put with different data may have succeeded

dug: format element should be optional

<Bob> folks agreed

dug: it's forgotten by editors only


AI 69 assigned to geoff

goeff: ...looking for his AI...

<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0078.html

asir: geoff you submitted a proposal
... on may 5th

<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0010.html

geoff: the latest discussion is that i still try to understand why we we need it
... i think both are valid resoruce rep and i don't understand the issue
... i control what rep a resouce has and i don't understand what's missing

dug: there is a baseline use of ws-t, you send xml to update resource

<asir> basic interop = first child element is service- or provider-specific; service or provider is in control

dug: the server needs to separate instruction from rep itself

<asir> think about HTTP PUT or POST

dug: if using any, this valid use case is not supported

geoff: there is an assumption that rep is inside an wrapper element
... there is no place to say the wrapper is an instruction and the children is rep
... resource defines any level of wrappers
... it's up to the resource to decide not the spec.

dug: literal resource rep is the key.
... first-child element should be the rep

<asir> am confused ... Transfer submission says, 'The first child element of the s:Body element MUST NOT be omitted. The contents of this element are service-specific, and MAY contain the literal initial resource representation, a representation of the constructor for the resource, or other instructions for creating the resource.'

gil: server is willing to accept anything as resource rep, in that case, there is no difference.

<dug> Bob - e.g. provide an EPR to copy the resource from

gil: we need to add attribute or constraint to separate instruction from resource rep

geoff: you define "literal" but spec doesn't define it

<dug> are people dropping on purpose?

geoff: resource can define its rep
... you can use xs:any if the resource can tell the difference
... it's the receiver's problem, not sender

asir: close with minor clarification

bob: please propose the clarification

dug: geoff please define "literal rep"

bob: Are there any corrections to irc?


Summary of Action Items

[NEW] ACTION: Dug and Ashok to write up a constrained policy mode proposal [recorded in http://www.w3.org/2009/05/19-ws-ra-minutes.html#action01]
[NEW] ACTION: Li and Dug to explore proposals and start a thread on this topic [recorded in http://www.w3.org/2009/05/19-ws-ra-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/05/30 17:07:10 $