See also: IRC log
<trackbot> Date: 22 September 2009
<Bob> scribe: Li Li
<Bob> scribenick: LI
agenda agreed
RESOLUTION: minutes of 2009-09-15 approved
<Bob> http://www.w3.org/2002/09/wbs/43088/HursleyDinner/
bob: Please complete it by
tomorrow
... discuss next f2f in santa clara
ram: publishe fpwd by friday?
yves: will try
bob: Is there anything that can't be done by the Hursley f2f?
asir: ask dug if it's possible to send out proposal this week
dug: i think so
asir: ai 94 is being worked on by me, we'll take over ai from geoff
katy: 61
<Yves> dug, mail sent (re AI on x-links)
<dug> thanks
ram: details not ready for f2f
... by the end of this week
RESOLUTION: issue-7678 opened
bob: any objection to the proposal in the issue?
ram: looks fine
<asoldano> fine to me
RESOLUTION: Issue-7678 resolved as proposed
yves: iri is not used in xml namespace, as pointed out by asir
<Bob> proposal is to use IRI for everything but namespaces
bob: use iri in everything except namespace?
dug: ws-a bounced between IRI and
URI
... concrete strings are URI but generic ones are IRI
... what is the pattern for us?
bob: use IRI for everything but namespace and literal strings
asir: URI is also IRI, we can do a global replacement
dug: i'm still confused
... why the exception?
<dug> The working group intends to update the value of the Web Services Eventing namespace URI each...
bob: use IRI to permit
localization
... otherwise we stick to URI
dug: namespace URI -> URI, so it's not global change
asir: someone needs to make a line-by-line change
bob: we have to give either detail changes or instructions to editors
dug: i like line-by-line changes
<Yves> I can do this on friday
bob: prefer line-by-line changes
<Yves> ACTION: Yves to produce a line-by-line diff for issue 7426 [recorded in http://www.w3.org/2009/09/22-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-105 - Produce a line-by-line diff for issue 7426 [on Yves Lafon - due 2009-09-29].
thanks
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0027.html
gil: explains the proposal
... it is about negotiating durations
... it's simple and efficient
daves: subcription is cut down to
yes/no
... more intelligent source can put hint in the response
... how to make response clear
ram: proposal is technical correct,
but compatibility is an issue
... developers should code against failures
... subscriber should be able to negotiate in different
situations
... we need to provide right guidance to developers
... this proposal doesn't help with practical issues
<asir> [Gil's voice is not clear on the phone
<Ram> Gil: Your voice quality is not audible.
<asoldano> the same here unfortunately
gil: in system integration, event
sink needs to count on event source
... [not audible]
daves: incompatibilty 1: failure to provde feedback
incompatibilty 2: provide feedback in failure
...3: complicated protocol and policy
... gil's is in the middle ground
... optional framework for policy later on?
ram: need to deal with device comp.
issue
... feedback from users on back comp. issues
... is not back comp. issue, rather to avoid mistakes by
developers
bob: specific changes?
ram: i sent some response today,
event source should decide duration,
... i can live with subscriber having an option to indicate
hint
dug: there are cases subscriber can
indicate a hint or not a hint
... can we have both, instead of just one?
<dug> bob I'd like to respond to what he just said
<gpilz> go ahead
ram: you are optimizing protocol to
avoid unsubscribe
... what is broken?
gil: yield to dug
dug: lightweight situation can create/delete subscription at will,
but other situation this is expensive
scribe: so we need to indicate "i really want"
gil: device and enterprise people are
talking across..
... we need to support both cases
daves: gil's proposal covers ram's concern by not puting duration in request
<gpilz> A Subscriber MAY indicate that it is willing to accept a Subscription with any expiration time by omitting this element from the Subscribe request.
ram: we're making leap of faith...
<gpilz> (the above is a part of the description of the optional /wse:Expirese element)
<DaveS> Ohh!?
<DaveS> Ooops I sat on the keyboard.
<dug> LOL
ram: flexiblity is needed to
interop
... let's talk more usecases in the f2f
... i'd like to know what is your use cases...
... we shouldn't loose interop between device and enterprise
worlds
... what's wrong with current spec?
<Bob> Asir, I hear hin well
<dug> there's also no guarantee that Renew will be accepted later on
gil: hint doesn't provide value to sink, if the time is cut off
<asir> we have difficulty hearing there is a lot of background noise
<DaveS> Dave agrees with Gil. A hint is the same as providing no duration at all.
gil: [in audible mostly]
dug: 2 issue with current spec: 1 cost of unsubscribe, 2 no guarantee on renew
<gpilz> katy what number do you use to dial into W3C?
dug: why isn't your requirement not supported by proposal
ram: i have the same question to
dug
... current spec is not burdening event source.
... current spec works in many different environments
dug: which use cases are not supported?
ram: i'm lost at what you try to solve
dug: what use case not supported
ram: not about technical content of
proposal
... but on what's goal of the proposal
bob: how would you modify it?
ram: i'll take another stab at it
bob: it's about deployment,
correct?
... which line should be modified?
ram: though technically sound, but it doesn't help me
bob: what part cause you problem?
ram: client having two options is a
problem
... having two parties making decision is difficult to code
... i'm having problem with duality
daves: proposal puts both subscriber and source in the driver seats
<dug> bob - ram can go first to answer dave
<dug> it might make my question moot
ram: giving dualities is a problem
for developers
... cause developers to misuse API instead of coding with
interactions
dug: all elements in subscribe are
optional
... why this one expiry is different from the others?
... while all others can fault when not satisfied
ram: but there is negotiation between subscriber and source
bob: why is it different from unsupported filter
ram: others are black and white, this one is not
dug: please explain why they are different
ram: something negotiable whereas
other are not
... current spec is flexible and interop
gil: where can we go, if nothing can be modified?
bob: strong objection?
ram: need more time
bob: it's long enough
asir: we should not close it now
bob: i asked many different ways
asir: we need to work with oracle
bob: what's wrong?
... we're not progressing
<DaveS> I really would like specfics before allowing more time.
<dug> I agree with Bob - I'm still confused as to what's wrong with the proposal
ram: let's spend time in f2f
<DaveS> What is broken and I am happy to see more time.
bob: let's focus on specifics
... objection or acceptance
ram: will work on it
bob: action to ram to work on the proposal for issue-7478
<scribe> ACTION: ram to work on proposal for the issue [recorded in http://www.w3.org/2009/09/22-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-106 - Work on proposal for the issue [on Ram Jeyaraman - due 2009-09-29].