See also: IRC log
<trackbot> Date: 08 September 2009
<dug> (Paul - is that right?)
<Yves> Scribe: Dug
<scribe> scribe: Dug
Ram: sent in a note about "updated references" - would like to review on today's call
Yves: will add to the agenda
minutes approved w/o
Yves: complete the
... everyone find docs/hotel info... ok?
Wu: info on how to take the train from London would be nice
Paul: will send info to the group - from LHR
Ram: best way to get from LHR to Winchester? Taxi? Train?
Paul: train is a lot of trouble
-need to take a bus - taxi is the easiest
... name of taxi company is in the doc I sent
... will make sure it does
Yves: anyone reviewed?
Ram: would like more time - by next week's call
Yves: would like to make these a
Working Group Draft
... everyone please review for next week
Yves: # of open AIs might cause
us to slip
... proposal is to open new issue if they are substantive
... please send new issue before Sept 18th
... just a way to try to focus on the schedule
Dug: ok with pushing but I'm not sure about Sept 18th
Yves: not a black-n-white thing
about opening new issue - will be a judgement call
... won't allow people to fight for hours just to open an issue - just used to push people to make progress
Gil: deadline after the F2F might
make more sense
... 2nd week of Oct
Yves: f2f's are different and the pace is much faster
Asir: At last f2f that we would go to LC on Oct 12
Yves: please raise issues ASAP
AI10 - on Geoff
proposal for 6549
AI11 - on Geoff - 6550
Asir: RT issues - Ram will scrub those issues - is dependent on ws-frag
AI67 - Yves - partial put - not done yet - week after next
AI81 - Ram/Dug proposal for ws-frag
Ram: still working on it - by next call
AI92 - proposal for 6568-6572 - Ram
Ram: those are about the
... proposals are in the email he sent
AI94 - pending ws-frag approval - Ram
AI97 - Yves- proposal for 7426 - done
<Zakim> gpilz, you wanted to discuss AI 99
AI99 - proposal on 7478
Gil: negotiation around
... want subscriber to be able to say: a) don't care, b) at least this amount of time, or c) don't expire
... in current spec expiration time can be a duration or a dateTime
... source can say "can't support duration" or "can't support dateTime". Asking for a profile.
... sink can't tell, in advance, which is supported
... could get into a situation where the two sides never agree
... seems we should get rid of one of the two options
<DaveS> Dave S. Joined the cal.
Yves: to mandate one and get rid of the other?
Gil: yes - how do people feel?
Ram: why shouldn't we have that flexibility?
Gil: multiple ways of doing the same thing will create an interop problem. We don't gain anything by having both. You can easily convert between the two.
Ram: would like more time to
think about it
... if they are interchangeable it would require clock-syncing
... duration starts from the time the source receives the msg
Gil: sink doesn't know when it really starts -it could take a long time for the request to get there
Yves: dateTime requires resolving
issues around timezones - duration doesn't have that
... would prefer duration
Ram: want more time to think
... if we can convert them it might not be a big deal
... acks Gil's issue
... what is the usecase that is driving the need?
... subscriber asks for 5 hrs, source only wants to allow for 30 mins
... subscriber could send a renew to ask for more
... want to understand why renew isn't good enough
Gil: subscriber can renew -
that's not the issue. But it might not want to do it that
... perhaps min amount of time between renew's is 30 mins - source could come back and say "renew every 5 mins"
... subscriber might not be happy with that
... resources could have been allocated in advance based on the assumption that the subscription would be longer-lived
... would like to check constraints in advance
Dug: renew might not be accepted
Ram: Gil's concern is valid
... if we allowed people to ask for "min amount of time" source will reject it
... subscriber would like to know what the source will accept
... subscriber has a choice - go with best attempt, or be willing to accept a rejection
... in the real world do we expect subscribers to put demands on the src? or accept what they get?
... most lean towards "best attempt"
Gil: there are cases where the
subscriber doesn't care or ok with the what the src
... but not everyone works this way
Li: this issue is trying to add a
level of guarantee by the src
... specifying finite vs infinite is already there - but guarantee isn't
Gil: "guarantee" is an orthogonal
... problem isn't the guarantee - its the inefficiency of the negotiation
Li: in proposal - ask for 5, if
src can't give at least 5 then fault
... that's a kind of guarantee
Gil: in the current spec, the SubscribeResponse contains the guarantee
Li: ask for 5 mins (or fault) - src gives back 5 min, can it send a SubscriptionEnd in less than 5?
Gil: yes - SubEnd is for
... this is about "normal" course of events
Li: src can still end
... distinction appears to be very small
Dave: subscription processing
needs to be crisp - not overloaded with discovery/negotiation
protocols - use policy
... "I didn't do what you wanted, is this ok instead?" kind of thing would be bad.
Gil: diff between expires and
other reasons to terminate is sort of like faulting
... could be lots of reasons to terminate early - but expiration time is about scheduled shutdown
... not "abnormal" - just normal lifecycle of subscription
Li: will take off-line
Dug: Ram already covered this - by next week
Dug: issue around what to do with optional elements during a Put
issue accepted w/o
Tom: related to 6401
... accomodated by 6401
resolution: close w/no action - accommodated by 6401
<gpilz> scribe: gpilz
Doug: (describes latest
... GetMetadataFactory to get an EPR that works with WS-T
... WS-T operations have additional attributes (@mex:Dialect, @mex:Identifier, @mex:Content)
... interesting is the use of wst:Create to create a brand-new metadata resource
... creates a brand-new resource and gives you back the EPR as well as updating the set of "all metadata" to inlcude the newly created metadata
Yves: you mean all the metadata that is specified as being an attribute?
Doug: you use the attributes to
tell the factory endpoint what it is that you want to
... I tried to create an example.
... the second example uses wst:Put
DaveS: why wouldn't you do this
with something like WS-Frag?
... you're trying to identify parts of the whole metadata document, why not just identify the part you want to modify?
... are you trying to do a similar kind of thing?
Doug: I don't think so. I don't
view this as a single, massive "metadata document". I view it
as a collection of separate resources.
... you may not have a separate resource per metadata document
DaveS: I need to go away and
think about this some more
... either there are separate documents, each with their own EPR, or there is one complete "metadata document"
... I need a picture
Asir: I'm as confused as Dave is
by the proposal
... my recollection from the F2F is that we agreed to add an operation that gets an EPR to the metadata factory
... this seems to go beyond that.
<dug> Agreement on direction. Add operations to MEX to expose factory EPR so that
<dug> TRANSFER optional operation may be used on the factory EPR to create/modify
<dug> Action on Doug to create proposal along these lines
<trackbot> Sorry, couldn't find user - on
Doug: it might be better to wait until the F2F to discuss this
Asir: based on the direction we agreed to it doesn't look like we need more that up to 6.2
Doug: for explanatory reasons we need 6.3?
<dug> yes sorry
<dug> Dug: no new proposal yet - still being worked on
<dug> scribe: Dug
Dug: no new proposal yet - still being worked on
Ram: want to go over the references
Ram: doc has all of the refs
across all the docs
... for each one - is this the latest?
... a number of them needed to be updated
... rfc2119 - added IETF to the anchor same for RFC 3986
... and some textual changes to the refs
... soap1.1 - needed to be more descriptive
Yves: could be good to look at
the impact this will have
... latest revision of some specs could impact our specs
Tom: ref to BP1.1 - why the ref to keith?
Yves: normal process for w3c
Ram: BP is just ref'd from
... do we need this reference?
<Ram> BP reference in RT:
<Ram> This specification intends to meet the following requirements:
"Define WSDL 1.1 portTypes, for the Web service methods described in this specification, compliant with WS-I Basic Profile 1.1 "
Yves: ref to policy could be an impact on our specs
Ram: already covered by a previous issue
Ram goes thru each ref
Ram: how do cross-refs work in w3c?
Yves: cross refs are handled on -
soap did this between part1 and part2
... only link to specs at the same level or one level below
<asir> Yves: can cross refs be automated?
PR level can point to CR but not WD - for normative refs
Yves: (to asir) yes can be
... should be - less issues that way
Asir: new issue for editors?
Yves: action to editors to automate the cross-links
<Tom_Rutt> with all the hard work in the industry to align the "v.Next" specs, lets be sure we have the correct references to the properly aligned V.Next ws* specs
<scribe> ACTION: editors to automate the cross-links [recorded in http://www.w3.org/2009/09/08-ws-ra-minutes.html#action01]
<trackbot> Sorry, couldn't find user - editors
<asir> ACTION: Doug to automate cross-links among WS-RA specs [recorded in http://www.w3.org/2009/09/08-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-100 - Automate cross-links among WS-RA specs [on Doug Davis - due 2009-09-15].
Tom: is worried that the automation might not work in all cases
Yves: should link to dated versions
Asir: we've done this before
Ram: will double check the
... any comments before the final proposal?
+1 to ending ;-)
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/quest/request/ Succeeded: s/then/them/ Succeeded: s/5724/6724/ Succeeded: s/like/link/ Found Scribe: Dug Inferring ScribeNick: dug Found Scribe: Dug Inferring ScribeNick: dug Found Scribe: gpilz Inferring ScribeNick: gpilz Found Scribe: Dug Inferring ScribeNick: dug Scribes: Dug, gpilz ScribeNicks: dug, gpilz WARNING: No "Present: ... " found! Possibly Present: Ashok Ashok_Malhotra Asir Dave DaveS Doug Doug_Davis Gil Microsoft Paul Ram Sreed Tom Tom_Rutt Vikas Wu Wu_Chou Yves aaaa aabb aadd aaee aaff aagg aahh aaii dug fmaciel gpilz joined 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/2009Sep/0015.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Sep 2009 Guessing minutes URL: http://www.w3.org/2009/09/08-ws-ra-minutes.html People with action items: doug editors[End of scribe.perl diagnostic output]