Web Services Resource Access Working Group Teleconference -- 08 Sep 2009

<trackbot> Date: 08 September 2009

<dug> (Paul - is that right?)

<Yves> Scribe: Dug

<scribe> scribe: Dug

<Yves> Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0015.html

approval of agenda

approved w/o

approve minutes from last week

<Yves> http://www.w3.org/2002/ws/ra/9/09/2009-09-01.html

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

UK F2F Logistics

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

2009-09-02 Snapshot review

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

Schedule

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

AI review

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

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 references
... 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 expiration time
... 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 concern
... would prefer duration

Ram: want more time to think about it
... 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 issue
... 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" failure
... 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 - 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 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

progress on ws-frag

Dug: Ram already covered this - by next week

new issues

7486: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7486

Dug: issue around what to do with optional elements during a Put

issue accepted w/o

Issues with proposals

7127: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7127

Tom: related to 6401
... accomodated by 6401

resolution: close w/no action - accommodated by 6401

<Wu> +1

6411

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6411

http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Aug/att-0063/wsmex-6411-08-24-09.doc

<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 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> 2009-08-06:

<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> metadata.

<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?

5724

6724

<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

<asir> :-)

Ram: want to go over the references

discuss references update

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

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/att-0022/References_update.doc

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> http://www.w3.org/2002/ws/ra/edcopies/wsrt.html#reqs

<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 automated
... 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 refs/authors...
... any comments before the final proposal?

+1 to ending ;-)

Adjourned

- DRAFT -

Web Services Resource Access Working Group Teleconference

08 Sep 2009

Attendees

Contents