See also: IRC log
<trackbot> Date: 16 November 2010
<Bob> proposals in http://www.w3.org/Bugs/Public/show_bug.cgi?id=11189
Ashok: would it be possible to
separate out the inlining from the dialect attribute
... make it oorthogonal to dialect
Doug: Depends whether they are always orthogonal. Prop 1 restricts to one content for all metadata
Tom: Concerned that prop 1 would remove function at this point. Preference for 3
<dug> I'm leaning towards 3 too
<Zakim> asir, you wanted to ask a question
Asir: There is a similar content attribute on the delete message
Doug: I don't think that this is an issue as we don't have a notion of deleting all the metadata, hence tying content attribute to dialect is ok for delete
RESOLUTION: Proposal 3
<scribe> ACTION: Katy to write up text for proposal 3 [recorded in http://www.w3.org/2010/11/16-ws-ra-irc]
<trackbot> Created ACTION-171 - Write up text for proposal 3 [on Katy Warr - due 2010-11-23].
Issue accepted, no objection
<asir> I vaguely recollect that this was requested by WSO2/Paul Freemantle
RESOLUTION: 11202 is resolved as proposed in issue
Resolution: 11210 is resolved as proposed in issue
Gil: Have sent email containing new issue in eventing
Bob: I will use your proposal as potential resolution to 10960
Bob: Is there any more known work
required for these feature lists?
... as no more known work will use these as base
... I will pull all the feature lists from emails and organise on page so people have a uniform place to find
<scribe> ACTION: rfreund to pull feature list info together [recorded in http://www.w3.org/2010/11/16-ws-ra-irc]
<trackbot> Created ACTION-172 - Pull feature list info together [on Bob Freund - due 2010-11-23].
Bob: Make primers documents so we can start raising issues etc
Doug: Some text in transfer/frag is
same for others
... so could consolidate
<scribe> ACTION: rfreund to organise documents in central location on our web page [recorded in http://www.w3.org/2010/11/16-ws-ra-irc]
<trackbot> Created ACTION-173 - Organise documents in central location on our web page [on Bob Freund - due 2010-11-23].
Bob: would like to pick a date so that we get some testing started
Asir: Ram said that February (mid) would be provisionally ok but would like a checkpoint in early Jan prior to committing
Bob: A checkpoint a month before the
scheduled date would seem resonable before commit
... suggest Jan 11th checkpoint for Feb 14th meeting
<dug> Anyone care about valentine's day?
Gil: need to check availability of conference centre
Bob: Tues 15th, Wed 16th, Thurs 17th Feb? Objections?
Bob: Gil please check that you can host
Resolution: F2F provisionally set for 15-17th Feb, focus interop testing, will perform checkpoint to confirm date one month before.
Bob: WS-I BP are final so we can add the final URIs
<asir> is there a specific text that we should be looking at
<Bob> original proposal http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0142.html
Bob: How is it best to wrap this into our wsdl references
Asir: there is a proposal from Gil dated Nov 13th 2009
<Bob> The version of WSDL 1.1 at http://www.w3.org/TR/2001/NOTE-wsdl-20010315 has
<Bob> known problems and inconsistencies. These were addressed in BasicProfile
<Bob> Version 1.1. The WS-RA specs should reference the BP-corrected-version of WSDL
<Bob> 1.1 via ISO IEC 29361:2008:
<Yves> but it's not a freely available copy
<asir> of course we need to replace ISO link to BP 12 and 20
asir: Whereever link to wsdl 1.1 with a note saying that there are issues to wsdl 1.1 that are addressed in latest BP 1.2 and 2.0 plus linke. In normative reference section.
Bob: Annotate references
Resolution: existing wsdl references (in bibliographies) should be annotated with appropriate links to BP 1.2 and 2.0
<Bob> Doug and I have put together the following proposal to address the WS-Eventing issues we have raised: http://www.w3.org/2002/ws/ra/10/10/wseventing-expires.doc
<Bob> To highlight the major changes:
<Bob> * The wse:Subscribe/wse:Expires element is no longer receiver-optional, but it remains sender-optional; an implementation of an Event Source MUST support the wse:Expires element, but a Subscriber is not required to include it. If the Subscriber does not include it, the Event Source/Subscription Manager is required to pick some expiration value ("PT0S" meaning infinite is a valid choice)...
<Bob> ...and communicate this using wse:SubscribeResponse/wse:GrantedExpires.
<Bob> * The ExpiresNotSupported fault has been removed.
<Bob> * The wse:SubscribeResponse/wse:GrantedExpires and wse:RenewResponse/wse:GrantedExpires elements are no longer optional.
<Bob> * The ExpiresSupported policy parameter has been removed.
<Bob> * The MaxExpires policy parameter has been renamed "Expires" and now supports both min and max supported expiration times.
<Bob> ~ gp
Bob: this has been available for
comment for a while
... any objection to accepting the combined proposal in the word document as a resolution to this issue?
Resolution: Issue 10960 resolved based on proposal
Gil: REfered to message on public comment list from Anish - link above
Doug: Basically looking for
EventDescription spec to have a file extension for event
description files (like .wsdl)
... is this just a de-facto 'standard'
Asir: Other specs specify a MIME type. This is probably what Anish is refering to.
<asir> Additional Information / File Extension
Asir: there is a process for getting the mime type
Bob: Do folk think this might be an appropriate solution - think about for next time
<Yves> I would note http://www.w3.org/2002/06/registering-mediatype.html
Bob: Also reviewing of primers for
... I would like to get to CR status
... Any objections to end of 2nd week of December for CR
... Will open a bug for Anish's comment
... CR is formal step saying we think we are done and call for implementations
... any formal objections that exist need to be presented
Tom: will all the at-risk stuff be done during CR?
Bob: yes in order to promote to cr at
risk needs to be identified, we think we have 2 implementations for
each spec (except enum)
... I will be asking between now and CR to check whether implementors will be covering optional apsects of the spec in order to establish the at risk features.
Yves: We can progress to CR and then indicate that we require additional implementations
Doug: Gil recently sent a scenario doc for WS-Eventing, I think it would be good to extend this scenario to all specifications
Katy: this will also illustrate how specs compose together
Bob: This suggestion may have an impact of the maintenence independence of the specs but as scenarios are not normatively referenced, this should not cause a problem
<asir> Asir: apologies - we have not yet considered this one
Bob: consider this and make a
decision asap in order to move along
... Next week intend to have a very brief call
... This does not suit all so next meeting on 30th November (no meeting next week)