See also: IRC log
<trackbot> Date: 19 May 2009
<Bob> Scribe: Li Li
geoff has a new finished AI for the agenda?
<dug> If its Tuesday this must be Belgium
UNKNOWN_SPEAKER: minutes approved w/o objection
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?
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
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 -
... 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].
any objection to openning them?
katy: 6920 missed
bob: objection to it?
<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
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
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
... 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
... 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> I am back
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 . . .
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 ....
<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
... 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
... we need to be careful not to over generalize
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
... 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
... 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...
asir: geoff you submitted a
... on may 5th
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
... 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
... 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?