<trackbot> Date: 27 January 2009

<Yves> Scribe: Gilbert

<scribe> scribenick: gpilz

roll call

roll will be tracked separately from the minutes

agenda

Katy: I raised 6472 as a new issue

minutes

yves: did people get a chance to look at the minutes from the F2F

resolved: minutes from F2F approved

resolved: minutes from 1/20/2009 approved

<Yves> http://www.w3.org/2005/06/tracker/irc

tracker

<dug> trackbot, status

<trackbot> Sorry, dug, I don't understand 'trackbot, status'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<Yves> http://www.w3.org/2002/ws/ra/tracker/

yves: we aren't using Tacker for issues

<Yves> http://www.w3.org/2005/06/tracker/users/my to access your own actions
...: so the issue-related commands are irrelevant

geoff: will that allow you to get a list of all action item?

yves: two modes
...: in general, all AIS
... but using "my" will just give you yours (across all W3C WGs)

editors report

yves: traffic on mailing list

doug: we're half-way done
...: 2.5 specs complete and the others in a day or so
... on track to get conversion done by end of the week

<dug> http://www.w3.org/2002/ws/ra/edcopies/

geoff: will those be available?

doug: this is where we will put our files
...: we'll send out a note at the end of the week

yves: tomorrow I will add links to the editors drafts

<Yves> ACTION: Yves to add link to the edcopies (once they are ready for review) [recorded in http://www.w3.org/2009/01/27-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-1 - Add link to the edcopies (once they are ready for review) [on Yves Lafon - due 2009-02-03].

new issues

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

katy: (describes issue)
...: how would we recommend that clients get the policies that they should use for the GetMetadata request
... bootstrapping problem
... how should policy be exchanged?

geoff: any ideas on how to do this?

katy: it may not be possible to exchange policy; may need some out-of-band agreement
...: as a group we need to agree on what we would recommend

yves: accept this?

resolved: 6463 accepted

assign 6463 to Katy

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

katy: (describes issue)

wu: can you provide more details
...: do you want to propose similar changes on "unable to renew"?

yves: we can accept this and close with no action if necessary

wu: we can accept this issue but we'd like to see more details

resolved: 6472 accepted and assigned to Katy

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

<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0047.html

wu: I don't have anything to add to this proposal
...: we left this for people to study

<dug> No objection to the proposal

Li Li: proposal is to expand the current element

Wu: (describes proposal)

+q

<dug> interesting, so "+q" does work

geoff: I have no real objection to this
...: we need to think about the wording
... the "Delivery" section in the eventing spec
... one question; using "Push" is NotifyTo mandatory?

wu: yeah

geoff: the spec doesn't say that and neither does the schema

li li: it's hard for the schema to enforce that

geoff: we need to fix the normative language
...: we also want to make sure that there is there are optional things you can add

li li: that's the sense we got from the discussion
...: I agree, the language should make it very clear
... not sure there is a way to make the schema enforce this

gil: we do this all the time; normative language that enforces further constraints on the XML

geoff: we need something that says "in delivery modes other than push you don't need NotifyTo"

<Yves> ACTION: Li Li to add some wording to clarify the use of NotifyTo (re: issue 6426) [recorded in http://www.w3.org/2009/01/27-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-2 - Li to add some wording to clarify the use of NotifyTo (re: issue 6426) [on Li Li - due 2009-02-03].

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

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0048.html

Li: (describes issue)

<dug> no objection

no objection

<dug> woo hoo - one down! we're flying now! :-)

<Geoff> no objection

resolved: 6427 closed with proposed resolution plus ammendments

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

doug: (describes issue and proposal)
... nothing new since last week

yves: crux of issue was xs:any vs. xs:any*

doug: that was a separate issue

yves: depends if the group agrees

geoff: one issue we have is doesn't this effect what happens with 6392 and 6396?
...: I know you're talking about schema, but the wording is effected as well
... how will the text change?

doug: basically leave text as is, then look at them separately
...: this proposal may close those issues with no action

geoff: the wording will have to change somewhat

doug: that is either another issue or, during review, we can raise a new issue
...: don't think we need to resolve that in this issue at this time

+1

geoff: we're not going to talk about the xs:any* issues?

doug: to me that is a side issue
...: i'd like to just get the wrapper in place
... then address the cardinality issues later

geoff: i'm not sure i'm going to be willing to close on this today
...: are you expecting others to raise those issues separately

yves: i hear that people are not ready yet to agree on closing it

geoff: i'd like one more week
...: how is it going to affect RT and everything gels

yves: be ready to discuss this next week

<Yves> ACTION: dug to raise issue about cardinality of xs:any, relative to issue 6398 [recorded in http://www.w3.org/2009/01/27-ws-ra-minutes.html#action03]

<trackbot> Created ACTION-3 - Raise issue about cardinality of xs:any, relative to issue 6398 [on Doug Davis - due 2009-02-03].

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

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

doug: don't want to resolve this but am willing to discuss
...: one way is to simply remove this operation
... but that probably won't be popular
... would like to defer this until we resolve the WS-Eventing issues
... because whatever we do will probably be patterned after that solution

geoff: I don't like the option of removing this operation

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

all: we did this one already

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

<dug> Gil: reviews his proposal

doug: two parts - remove wsa04:action is obvious
... thinks we should use wsam:Action

geoff: agrees

<scribe> ACTION: gpilz to update proposal to include wsam:Action [recorded in http://www.w3.org/2009/01/27-ws-ra-minutes.html#action04]

<trackbot> Created ACTION-4 - Update proposal to include wsam:Action [on Gilbert Pilz - due 2009-02-03].

doug: would like to discuss proposals

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0051.html

yves: lets start with gils

<dug> gil: talks about his proposal for wseventing bp/policy/... issues

<dug> ... very raw proposal - looking for initial feedback

<dug> ... endpoint policy subject

<dug> ... wsdl port level

<dug> ... this wsdl defines what the event sink needs to support

<dug> bea.com?? what's that???

<Wu> would like to have a better understanding of backward competibility with exisiting ws-eventing implemetation

doug: I don't believe this impacts what appears on the wire

wu: i think this is something we need to really study
...: one thing we need to think about is how to maintain the spirit of ws-evetning

+q
...: need to make it friendly to existing implementations
... we need to be prudent
... everybody should check this out for issues

<Wu> Thanks for point out that

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jan/0056.html

proposal on 6429

Li: (describes proposal)

+q

<dug> that's ok - I didn't mind if gil went first :-)

<dug> <wse:Notify actionURI="xs:anyURI"> ...data... </wse:Notify> would be the body

<dug> <wsa:Action> http://.../wseventing/Notify </wsa:Action>

why not the wsa:Action?

putting metadata (which is what "action" is) in the body makes it harder to retrieve

<dug> some people dispatch on the wsa:Action - so it would need to be static just like the Body in order to go to the same operation each time.

fair enough