See also: IRC log
<trackbot> Date: 08 September 2009
<Yves> 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 questionnaire
... 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
... 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
AI99 - proposal on 7478
Gil: negotiation around expiration
... 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
... 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 concern
... would prefer duration
Ram: want more time to think about
... 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 frequently
... 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 offers
... 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 "unexpected"
... this is about "normal" course of events
Li: src can still end prematurely
... distinction appears to be very small
Dave: subscription processing needs
to be crisp - not overloaded with discovery/negotiation protocols -
... "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 behavior
... 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 profile)
... 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 create
... 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
... 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> 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 RT
... 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 ;-)