See also: IRC log
<trackbot> Date: 21 April 2009
<Bob> trackbot, begin conference
<trackbot> Sorry, Bob, I don't understand 'trackbot, begin conference'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<Bob> trackbit, status
<Bob> trackbot, status
<Bob> trackbot, start telcon
<trackbot> Meeting: Web Services Resource Access Working Group Teleconference
<trackbot> Date: 21 April 2009
<DaveS> Hi Bob, I on line and will dial in in a few minutes. I'll tell you when I connect.
<Bob> scribe: Asir
<scribe> Scribe: Asir S Vedamuthu
<scribe> ScribeNick: air
<asir> ScribeNick: asir
<Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0126.html
<scribe> Meeting: WS-RA WG Conference Call
<scribe> Chair: Bob Freund
Agenda approved!
Resolution: unanimously approved the minutes at http://www.w3.org/2002/ws/ra/9/04/2009-04-14.html
Resolution: accept all
Bob: Geoff - did Doug address your comments?
Geoff: yes
... has anyone else reviewed the editors' snapshots
Bob Freund, Geoff Bullen and Doug Davis
Anyone else?
[SILENCE]
<DaveS> Davd Snelling joined the audio.
Resolution: close issues incorporated in the Mar 31st snapshots (that is, bug list in the editors' snapshot change logs)
<Geoff> We have worked on our goals.
<Geoff> We have had a con-call, but did not reach consensus.
<Geoff> Geoff has an action item to come back soon with new thoughts on how to move forwards.
Geoff: no ETA yet
Bob motivated members to close actions
<Bob> whip whip
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6739
Doug: use boiler plate to ensure
consistency
... across specs
... retain the current wording to ensure that nothing is
lost
... hoping this is editorial
Geoff: no objections to the
proposed direction
... but it is only half finishing work
... some of these specs need specific wording
Bob: open to members to raise additional bugs
Doug: yes, yes
I missed the action
<scribe> ACTION: Doug to (upon completion of 6739) highlight the differences across WS-RA conformance sections [recorded in http://www.w3.org/2009/04/21-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-58 - (upon completion of 6739) highlight the differences across WS-RA conformance sections [on Doug Davis - due 2009-04-28].
Doug: apply the boilerplate, move spec specific contents to after the boiler plate text
Resolution: closed issue 6739 as proposed at http://www.w3.org/Bugs/Public/show_bug.cgi?id=6739#c0
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6712
[Doug is walking through the issue]
Doug: based on last night
thinking, wants a flag to indicate whether the body is a rep or
something else
... not much feedback
<Yves> well, you have the URI (well EPR) and the Action, why do you need more?
[I am specifically not recording that fragment]
Yves got a good question
Geoff: anyone of the content is
okay, upto the resource to figure out, rather than Doug's
interpretation
... resource can support more than one type
... one simple way to resolve would be - clarify one and upto
the resource to figure out which one
... willing to provide some clarification text
... is that a reasonable approach
... are there any use cases for IBM interpretation
... has anyone implemented the IBM interpretation
Yves: create is similar to HTTP
PUT and URI, we have an action URI and body
... not sure I understand what Doug wants to do with additional
flags
Doug: Yves is right
... passing in an EPR to copy the contents
... passing in fragement stuff
... does not matter what the instruction set is
... add the ability to provide multiple constructors
... MS interpretation, full representation | nothing
... but not allow other constructors
... Transfer spec allows that
... forcing the users to choose one or the other translating to
removing features
... What about the 'Content-Type' header?
... how to interpret the data
... no hint
what about the QName of the element?
Katy: full representation or
partial representation ("fragment")
... pity to restrict the scope
<Yves> why not doing a null 'create' then a 'put' from a template service?
<Yves> seems like an optimization that has impact on the complexity of handling create
DaveS: if we have a resource that has exactly one behavior then okay. the problem is want to build in pieces
<dug> yves - why force people to jump thru hoops when transfer says you can do this today
<dug> ?
DaveS: in theory, that is supported by the current transfer spec
<Katy> Dialect (or something like) enables creation of resources in other ways, for example via command if resource is very big (large policy docs)
<Yves> create from template looks more like a POST to me
Geoff: don't need a flag or dialect or something else to accomplish this
<Yves> so specific action
Geoff: many of the comments are irrelevant to the issue
<dug> yves - talk in Transfer terms please :-)
<Yves> dug :)
<Yves> like a "other action" to me
Geoff: put allows message and defers interpretation to the resource
Bob: don't have a real crisp view of what to do?
Doug: regardless of the point of
view, we are not talking about adding new features .. no real
differences
... can a resource support multiple types?
<dug> I'd like to point out that I'm talking about adding any features - just allowing for more than one type of create at the same time
<DaveS> DaveS's Use case summary for the minutes: A resource may need to be constructed through several steps where the resource needs to respond differently to different invocations. Dialect addresses this. The current spec is vague. A boolean (however implemented) is not rich enough.
Geoff: upto the resource to decide, not the client
<Yves> in WebDAV, COPY or MOVE are in fact doing the same thing as a PUT. Same thing here, creation of a resource is not always linked to a wst:create
[just like HTTP/REST]
<dug> but the service should be allowed to choose how many ways to expose
Geoff: add clarification text to better explain this
<DaveS> It is important that the existing implementations do not get restricted by changes we make.
<scribe> ACTION: Geoff to propose CLARIFICATION text to resolve issue 6712 [recorded in http://www.w3.org/2009/04/21-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-59 - Propose CLARIFICATION text to resolve issue 6712 [on Geoff Bullen - due 2009-04-28].
Geoff: not restriction, clarification and would like to move to consensus and not vote one versus the other
Issue 6712 - waiting for Action-59
[Doug walks through the issue/proposal]
Doug: interesting stuff is the filter dialectg nested assertion
Geoff: no objections to using
WS-Policy ... want to understand
... how we use policy assertions and its implications
... unclear been beaten around for a while
... policy as a substitute for WSDL constructs
... used for instrastructure specification
... are these specifications infrastructure specs (leaving that
aside)
... there are some trade-offs
... OTOH, want to make sure that we thought through the use
cases to ensure success
... how does this compose with other policy assertions defined
else where
... what happens?
... say security assertions, per operation basis, per message
basis, how would we solve that problem?
Doug: agrees with everything
Geoff said
... opened a separate issue to discuss the impact on operations
| messages
Geoff: but these issues are
overlapping, what happens when I specify the enum policy
assertion
... what is the relationship between the assertion and the WSDL
constructs
Doug: agrees again!!!
... ... may need to tweak this, want to avoid what it means to
support enumeration
Geoff: need to clearly articulate
the overlapping point and then move forward
... come up some wording
... that clearly articulates what needs to be resolved
Katy: agrees with Geoff!!
<dug> no no no, Geoff agrees with Doug and Katy :-)
Katy: problem space is quite
simple
... policy assertion indicates that enum MUST be used
... may be it says, may be used
... simple solution might be s/MUST/MAY/
... want to discuss implicit/explicit operations, how to
associate policy expressions to implicit operations and
messages
<dug> 6694: which operations are implicit
Katy: overlapping issues are 6721 and 6694
<dug> Asir agrees with Doug
Asir: elaborate on filter dialect policy assertion?
Doug: uses a QName = uri of the
filter dialect, local name filter dialect
... to leverage policy intersection specified in WS-Policy
[katy, may i request you to type your comment]
Doug: started with basic functionality, made sure that the proposal can be augmented
Bob: where are we?
DaveS: move forward
Geoff: refine some language
around what we are resolving and what we are not
resolving
... doug took an action to describe the situation
<dug> The resolution of this issue does not preclude us from modifying this policy based on issue 6694.
Geoff: would like to work together
<dug> +1 bob
<DaveS> +1
[Bob is typing a proposal]
<Bob> resolve 6403 with the proposal in bugzilla subject to future consideration as may be required in the resolutions for issues 6721 and 6694
Geoff: not ready yet, there are a couple of issues outstanding, move forward, solving 6403 does not resolve those open issues
Katy: issue 1 - how to associate policy expressions to implicit operations | messages
<Katy> A endpoint should include a filterdialect policy assertion for each of the filter dialects that it supports.
<dug> +1
[where is this being inserted?]
<dug> end of: /wsenp:WSEnumeration/wsp:Policy/x:FilterDialect
<dug> text
Bob: are we open to resolve issue 6403 with the amendment from Katy and Bob's statement (need to resolve other issues)
Geoff: request another week to review the proposal
<DaveS> +1
[Bob is inserting Katy's amendment to 6403 proposal]
<DaveS> To the insertion into bugzz...
everyone is playing with BugZilla!
Collision .. oops oops oops
Doug messed up Bob's entry :-)
Bob baptizes 6403 with an #
Gil is absent
Skip?
Bob: any questions on the
proposal, has been marinating (but not ready for grill)
... let's start next week
subscriber is not addressable
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6432
'THIS' proposal
Doug: re-baptizes 'PUSH' as 'EPR IT IS'
Bob: where are we?
Geoff: wearing a
non-conflationary hat (what is that?)
... proposal uses an EPR mode, that is not specific
enough
... gone backwards and forwards
... you need to parse the EPR to figure out what is going
on
... parsing an EPR in an eventing code bit is not the right
thing to do
<dug> I have not added any new requirements for parsing the EPR by changing the name of the Mode
Doug: changing the mode from push to epr based does not say that you need to parse EPRs
Bob: what does asynchronous mean?
Geoff: by using an EPR rather
than something more specific, you are actually loosing
important semantics
... no need to look into an EPR
... Geoff claims written evidence on the WG mailing list
:-)
<dug> name change alone doesn't do that
<dug> if the eventing layers need to know MC is being used then it can look at the EPR just as easily as the Mode URI.
Geoff: relying on EPR means the eventing layer is left behind, does not know what delivery semantics are used
or requested by a subscriber
Bob: which parts of the proposal conflates?
Geoff: renaming is the concern
DaveS: nothing in the proposal
changes the semantics of the submitted eventing
... use the default semantics
... use the push mode
Doug: what if we rename it to default mode
I heard Dave S support that
Bob: Antoine asked - what happens
a subscriber behind a firewall is using that
... we need to dev a proposal for that
Geoff: push mode need to
retained, create a new mode, perhaps Pull MC
... that woulld be a more viable solution
<Bob> acl li
DaveS: two choices - (a) get lost (b) change pushmode -> eprmode
Li: correctly describe the mode
and then let the users figure out what to do
... could use MC even with addressible EPRs
... would like to define a new mode
[Bob is auctioning the last 60 seconds]
scribe: would like to retain the current Push mode and define a new mode
Geoff: is tied with 6692, no doubts
<DaveS> Daves Clarification for the minutes: Option A) close with no action and tell Antoine to use WS-Addressing to do it, or B) provide guidance in the specification and clarify the name of PushMode to be something less specfic.
Geoff: the current proposal conflates both push and pull
<dug> Geoff - you on IM?
<Bob> Bob adminishes folks to correct test scribed now while it is still fresh in their minds
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Doug/Bob/ Succeeded: s/beat/beaten/ Succeeded: s/6721/are 6721/ Succeeded: s/'EPR' it is/'EPR IT IS'/ Succeeded: s/is the right/is not the right/ Succeeded: s/teh/the/ Found Scribe: Asir Inferring ScribeNick: asir Found Scribe: Asir S Vedamuthu Found ScribeNick: air WARNING: No scribe lines found matching ScribeNick pattern: <air> ... Found ScribeNick: asir Scribes: Asir, Asir S Vedamuthu ScribeNicks: asir, air WARNING: No "Present: ... " found! Possibly Present: Ashok Ashok_Malhotra Asir Bob Bob_Freund DaveS Doug Doug_Davis Geoff Gilbert_Pilz Microsoft P0 P14 ScribeNick TRutt Tom_Rutt Vikas Yves aaaa aabb aacc dug fmaciel gpilz jeffm joined katy li trackbot ws-ra You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0126.html Found Date: 21 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/21-ws-ra-minutes.html People with action items: doug geoff[End of scribe.perl diagnostic output]