See also: IRC log
<trackbot> Date: 27 January 2009
<Yves> Scribe: Gilbert
<scribe> scribenick: gpilz
roll will be tracked separately from the minutes
Katy: I raised 6472 as a new issue
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
<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: we aren't using Tacker for issues
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)
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
geoff: will those be available?
doug: this is where we will put
...: 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].
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
katy: (describes issue)
wu: can you provide more
...: 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
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)
<dug> interesting, so "+q" does work
geoff: I have no real objection
...: we need to think about the wording
... the "Delivery" section in the eventing spec
... one question; using "Push" is NotifyTo mandatory?
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
...: 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
...: 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].
Li: (describes issue)
<dug> no objection
<dug> woo hoo - one down! we're flying now! :-)
<Geoff> no objection
resolved: 6427 closed with proposed resolution plus ammendments
doug: (describes issue and
... 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
geoff: we're not going to talk about the xs:any* issues?
doug: to me that is a side
...: 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
...: 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].
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
all: we did this one already
<dug> Gil: reviews his proposal
doug: two parts - remove
wsa04:action is obvious
... thinks we should use wsam:Action
<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: 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
...: 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
Li: (describes proposal)
<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.