12:43:53 <RRSAgent> RRSAgent has joined #ws-ra
12:43:53 <RRSAgent> logging to http://www.w3.org/2009/03/11-ws-ra-irc
12:43:54 <trackbot> RRSAgent, make logs public
12:43:56 <trackbot> Zakim, this will be WSRA
12:43:56 <Zakim> ok, trackbot; I see WS_WSRA(F2F)9:00AM scheduled to start in 17 minutes
12:43:57 <trackbot> Meeting: Web Services Resource Access Working Group Teleconference
12:43:58 <trackbot> Date: 11 March 2009
12:51:07 <Bob> Bob has joined #ws-ra
12:51:16 <Bob> good morning
12:51:17 <Vikas> Vikas has joined #ws-ra
12:59:31 <li> li has joined #ws-ra
13:01:12 <Bob> We are working on the phone
13:01:16 <li> hi everyone
13:02:45 <Zakim> WS_WSRA(F2F)9:00AM has now started
13:02:46 <Zakim> +Yves
13:05:33 <Geoff> Geoff has joined #ws-ra
13:05:46 <Zakim> +Li
13:07:25 <Zakim> +[IBM]
13:07:38 <Bob> we have audio
13:08:23 <Wu> Wu has joined #ws-ra
13:09:55 <Bob> scribe: Vikas
13:10:27 <dug> dug has joined #ws-ra
13:10:43 <Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0058.html
13:11:09 <DaveS> DaveS has joined #ws-ra
13:11:24 <DaveS> Good morning
13:12:09 <Ashok> Ashok has joined #ws-ra
13:12:43 <Vikas> Topic: Agenda approval done
13:13:28 <asir> asir has joined #ws-ra
13:13:29 <Vikas> Topic: Editor's draft review
13:16:06 <Vikas> Asir: Use CVS notification for a checkin...to review.
13:16:31 <dug> for some reason why cvs won't send in my cvs update comments
13:16:43 <Yves> also I can make a snapshot at a specific location, easy to do
13:17:20 <dug> well, just doing a cvs diff by date works too
13:17:42 <Vikas> Asir: Use CVS labels and compute automatic diff.
13:20:54 <Vikas> Vikas has joined #ws-ra
13:20:55 <Yves> yes, we could do a "make snapshot" "make tags" etc...
13:21:59 <asir> what about a diff version
13:22:32 <Vikas> Vikas has joined #ws-ra
13:22:45 <Vikas> Bob: make a snapshort once a month.
13:23:25 <Katy> Katy has joined #ws-ra
13:23:35 <Vikas> s/snapshort/snapshot
13:24:12 <Vikas> Bob: Asir help the editors to compute the diffs
13:24:12 <Yves> there should be a diffspec.xsl as well
13:25:17 <Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access-notifications/ is indeed only for bugzilla now, I can make it extended to add cvs commits
13:25:33 <Vikas> Action: Yves, notification setups
13:25:33 <trackbot> Sorry, couldn't find user - Yves,
13:25:57 <Vikas> Action: Yves notification setups
13:25:57 <trackbot> Created ACTION-38 - Notification setups [on Yves Lafon - due 2009-03-18].
13:27:28 <Vikas> The working group agrees for monthly review of snapshots.
13:27:49 <asir> q+
13:28:06 <Sreed> Sreed has joined #ws-ra
13:28:19 <Bob> ack asir
13:30:55 <Vikas> Asir:  Sugegst to have summary  of change logged at bottom of spec.
13:31:08 <Vikas> s/sugegst/suggest
13:31:33 <Vikas> Resolution: Add change log at bottom of each spec.
13:31:44 <gpilz> gpilz has joined #ws-ra
13:32:34 <Vikas> Bob: Executive summary of changes log for public?
13:32:58 <Vikas> Dug: Who will maintain it?
13:33:45 <Vikas> Bob: Look into the executive summary option later.
13:34:17 <Vikas> Bob: First snapshot review - April 1st
13:34:37 <Vikas> Resolution: First snapshot review - April 1st.
13:35:01 <Vikas> Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6400
13:35:29 <Bob> Revisit 6400 due to request for overnight review
13:36:11 <Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0051.html
13:36:53 <TRutt> TRutt has joined #ws-ra
13:38:15 <Vikas> Li: Change subscription & port to Subscription & Porttype.
13:38:53 <li> change SubscriptionEndPort to SubscriptionEndPortTy;e
13:39:19 <Bob> s/Ty;e/Type
13:39:46 <gpilz> q+
13:40:19 <Wu> q+
13:40:30 <Bob> ack gp
13:41:37 <Vikas> Resolution: change SubscriptionEndPort to SubscriptionEndPortTye
13:43:16 <Bob> ack wu
13:44:14 <Vikas> 6400 resolved.
13:45:16 <Wu> s/SubscriptionEndPortTye/SubscriptionEndPortType
13:45:40 <Vikas> Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6500
13:46:08 <Vikas> Geoff: Proposed close with no action
13:48:19 <gpilz> q+
13:48:22 <Vikas> Dug: Want to keep GetMetadataResponse for consistency across spec.
13:50:14 <li> EndTo endpoint cannot use wrap interface to receive SubscriptionEnd message because it is a protocol message, not an event message
13:50:23 <dug> <mex:GetMetadataResponse ...>
13:50:25 <dug>   <mex:MetadataSection...> ... </mex:MetadataSection> *
13:50:27 <dug>   xs:any *
13:50:29 <dug> </mex:GetMetadataResponse>
13:50:50 <Bob> ack gp
13:52:26 <Bob> Fof minutes edit, move Li's comment above start of issue-6500 discussion
13:52:37 <Bob> s/Fof/For
13:53:41 <Vikas> Alternative proposal by Dug above
13:53:46 <asir> q+
13:53:54 <Bob> ack asir
13:54:40 <dug> q+
13:54:49 <Bob> ack dug
13:56:33 <Bob> It was noted that extensibility is already in the schema, but not in the text
13:57:53 <Bob> Dug: In that case it gets down to just re-naming the element
13:58:01 <Vikas> Vikas has joined #ws-ra
13:59:42 <Vikas> Daves, Aris asking for use cases.
13:59:50 <asir> s/Aris/Asir/
14:00:05 <Bob> Dave: What are the use-cases for extending the response?
14:01:57 <Vikas> Katy: Don't rename mex:metadata.
14:03:06 <dug> Katy: go back to original proposal
14:03:16 <Vikas> Bob: Any objection to the proposal.
14:03:51 <Vikas> Geoff: Object, 6398 need to be looked at first.
14:05:06 <gpilz> q+
14:05:30 <Bob> ack gp
14:06:20 <Vikas> Gil:  No need to add dependency on 6398.
14:09:51 <Vikas> Vikas has joined #ws-ra
14:10:06 <Zakim> +fmaciel
14:10:53 <Vikas> Bob: Any objection on the new proposal.
14:11:18 <dug> q?
14:11:32 <Vikas> Geoff, Asir object, asking for more time
14:11:38 <dug> q+
14:12:18 <Bob> ack dug
14:12:22 <Vikas> Doug Ashok : How much time is required.
14:14:59 <Vikas> Vikas has joined #ws-ra
14:15:01 <DaveS> q+
14:15:34 <gpilz> q+
14:16:05 <Bob> ack dave
14:16:47 <Vikas> Dug: Agains adding dependency of 6398 in 6500.
14:17:07 <Bob> q+
14:17:13 <Bob> ack gp
14:18:18 <Vikas> Gil: Time line to put forward formal objection for 6398?
14:18:32 <gpilz> q+
14:19:09 <Bob> ack bob
14:19:12 <Bob> ack gp
14:20:40 <dug> q+
14:21:06 <Bob> ack dug
14:23:14 <Vikas> Bob: Will look at 6500 later.
14:36:47 <Katy> http://www.soaphub.org/public/files/w3c/t-rt-merge-v2.doc 
14:37:34 <Vikas> Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413
14:39:43 <Yves> why defining Dialect as an attribute and not as a child element of wst:GET ?
14:40:04 <Katy> http://www.soaphub.org/public/files/w3c/t-rt-merge-v2.htm
14:41:26 <dug> yves - could be done that way - but there some concern from MSFT folks when we first worked on that they wanted to be able to detect an unknown dialect asap and an attribute was easier than going down one level.
14:41:43 <fmaciel> fmaciel has joined #ws-ra
14:42:49 <Yves> dug - what is the namespace of Dialect attribute then? having a wstr:dialect element sounds easier as an extension point than adding an attribute in wst: everytime you want to do such add-on
14:44:10 <Geoff> q+
14:44:28 <Bob> ack geo
14:44:30 <DaveS> q+
14:44:40 <dug> well, since we believe that RT will be fundamental to T's use it makes sense to have it part of the same namespace
14:44:42 <dug> q+
14:46:45 <Vikas> Geoff: Why are we doing it, as of now there are no issue raised regarding WS-Transfer and WS-RT complexity.
14:47:01 <Vikas> s/issue/issues
14:49:41 <asir> q+ to talk about the history
14:55:44 <Vikas> Dug: WS-RT only makes sense in presence of WS-Transfer.
14:56:44 <Bob> Dug argues (amongst other things), that RT reduces the need for transactional support, since it would reduce collisions
14:56:59 <Bob> ack dave
14:57:19 <Bob> q+
14:58:49 <Bob> Dave: If they were written together then the inconsistencies would be resolved, but then ought to be split
14:59:18 <Bob> ack dug
14:59:43 <DaveS> 1) Generally splitting is better.
14:59:43 <DaveS> But:
14:59:43 <DaveS> 2) Consistency is needed between Tx and RT. Merging will fix these.
14:59:43 <DaveS> 3) Prevention of rouge extensions that duplicate RT function.
14:59:43 <DaveS> 4) Interaction semantics between the two capabilities is more transparent.
14:59:44 <DaveS> 5) Encourage wider uptake of the full capability of Tx + RT.
14:59:46 <DaveS> - Develop together and the split
14:59:48 <DaveS> - Restrict transfer as we split them so as to capture semantic interaction,
14:59:51 <dug> q-
15:00:01 <Bob> ack Yve
15:00:52 <dug> q+
15:01:20 <Bob> ack asir
15:01:20 <Zakim> asir, you wanted to talk about the history
15:03:13 <Zakim> -fmaciel
15:03:40 <Katy> q+
15:03:58 <dug> q-
15:04:00 <dug> q+
15:06:37 <Wu> "<DaveS> - Develop together and the split" - Do you mean "Develop together and then split"
15:07:20 <Vikas> Asir: -Duplication,   overlap, needs to be handled on case-by-case bases.
15:07:37 <DaveS> yes: Develop the specs together to clarify semantics, overlap, common issues. Then split if the result really looks to complex.
15:09:05 <Vikas> Vikas has joined #ws-ra
15:09:39 <Vikas> Vikas has joined #ws-ra
15:14:22 <Bob> ack katy
15:14:27 <Bob> ac bob
15:14:49 <Bob> ack bob
15:15:07 <Geoff> q+
15:15:14 <Vikas> Bob: Against fully merging the two spec.
15:15:33 <Katy> Adding to Dave's list above
15:15:33 <Katy> 6) From Editorial and WG point of consolidating proposals across the 2 specs is far easier (wrt time and effort) when they are merged
15:15:46 <Bob> ack dug
15:16:30 <asir> q+ to respond to Doug
15:17:44 <Bob> q+
15:17:47 <Yves> is dialect fragment or conneg?
15:18:18 <Bob> ack geo
15:18:32 <dug> http has fragment support
15:18:49 <Bob> http frags are a user agent function
15:19:23 <Bob> ack asir
15:19:23 <Zakim> asir, you wanted to respond to Doug
15:20:10 <Katy> q+
15:20:50 <Bob> ack bob
15:20:57 <Bob> ack yves
15:20:57 <Zakim> Yves, you wanted to say is dialect fragment or conneg?
15:21:34 <Ashok> q+
15:21:40 <dug> +1 to yves - transfer is missing a ton of http features
15:22:06 <dug> q+
15:22:15 <dug> q-
15:22:30 <asir> +1 to Yves for using SOAP extensions
15:22:36 <asir> that is what Resource Transfer does today
15:22:53 <Bob> ack katy
15:24:05 <Vikas> Katy: IBM has implementation of WS-RT.
15:24:20 <Bob> ack ash
15:24:32 <Geoff> +1 to dug for RT not being as mature at T
15:25:07 <dug> bob - I was referring to the http range headers not the user-agent stuff
15:26:18 <Katy> My comment was: we were reluctant to implement rt due to bp compliance issues with the wst base spec
15:27:48 <DaveS> q+
15:28:32 <Bob> ack dave
15:30:19 <asir> q+
15:31:11 <Vikas> Daves: Obligation of smooth transpiration for present implementation. 
15:33:55 <Yves> if it is a fragment, should it be part of the EPR?
15:34:22 <Vikas> Bob: Important consideration
15:34:38 <Vikas> 1 - Common stuff should be commonly defined.
15:35:01 <Vikas> 2- RT Fragments, is an extension; is it a common operation; is it a optional operation.
15:36:26 <Vikas> 3- Some RT Features have questions, problems, unclear, broken
15:38:11 <asir> q+
15:40:37 <Bob> ack asir
15:46:52 <Geoff> q+
15:47:37 <Bob> ack geo
15:50:47 <Geoff> is the value of doing this work, greater than that amount of work required to achieve it?
15:51:08 <Geoff> s/that/the/
15:57:08 <Vikas> Vikas has joined #ws-ra
15:59:38 <Zakim> -Li
16:01:40 <Vikas> Bob: Do the working group consider frags as extension.
16:02:32 <Vikas> Action: Katy produce a document on frag support as an extension.
16:02:32 <trackbot> Created ACTION-39 - Produce a document on frag support as an extension. [on Katy Warr - due 2009-03-18].
16:04:37 <Zakim> +fmaciel
16:07:13 <Zakim> -[IBM]
16:07:17 <Zakim> -Yves
16:08:51 <fmaciel> ok
16:09:15 <Zakim> -fmaciel
16:09:16 <Zakim> WS_WSRA(F2F)9:00AM has ended
16:09:18 <Zakim> Attendees were Yves, Li, [IBM], fmaciel
16:26:50 <Bob> Bob has joined #ws-ra
16:59:29 <fmaciel> fmaciel has left #ws-ra
16:59:59 <Zakim> WS_WSRA(F2F)9:00AM has now started
17:00:05 <Zakim> +[IBM]
17:00:15 <Bob> we are re-starting
17:00:55 <Wu> Wu has joined #ws-ra
17:01:41 <Zakim> +Li
17:02:03 <asir> I promised to add my statements on 6413 to the IRC
17:02:06 <Zakim> +Yves
17:02:06 <asir> here it is
17:02:08 <asir> If there are any overlap between T and RT, those should be identified as separate issues and resolved
17:02:08 <asir> If there are any duplication between T and RT, those should be identified as separate issues and resolved
17:02:08 <asir> If there are any inconsitencies between T and RT, those should eb identified as separate isseus and resolved
17:02:08 <asir> if any of the current RT issues apply to Transfer, the WG will address them across specs
17:02:08 <asir> We acknowledge the 2 possible cases - simple use case and non-simple use case. We have seen umpteen impls of the simple use case and we have plenty of interop evidence. We do not not seen any implementations of the non-simple use case.
17:02:11 <asir> If any of the RT issues (filed by Microsoft) apply to Transfer then the WG would consider that and address it as well. This is similar to how the WG processed 6428 against Eventing whose resolution was applied to all 5 specifications
17:02:15 <asir> Re bunding specs will increase market adoption and interop - this is a myth. Market adopts value not required and optional features. Bundling is not the solution
17:02:18 <asir> Re WS-Man created a domain specific fragment transfer - RT was born in 2006. WS-Man was born in 2004. It is common for a feature to be born in a domain specific way and then promoted in a generic manner at a later date
17:02:21 <asir> RT did not carry the consensus of the authors during its dev and submission (only IBM and Intel submitted, Microsoft and HP did not). 
17:02:24 <asir> There wasn't consensus to add RT to the charter ...
17:02:26 <asir> RT frag transfer is an extension of Transfer (from the SOAP Processing Model point of view)
17:02:28 <asir> In order to not burden current dependant specs on Transfer we believe that the extension should be in a separate specification
17:02:33 <asir> s/born in 2004/born in 2002/
17:03:30 <li> li has joined #ws-ra
17:04:04 <DaveS> DaveS has joined #ws-ra
17:06:33 <Bob> scribe: Katy
17:06:42 <Katy> TOPIC: Follow up to Tag/Mex RT conversation
17:07:01 <Katy> Asir: Ashok polinted out may not get response for tag
17:07:13 <Katy> ... from tag
17:07:23 <Katy> .. Bob suggested waiting to last call 
17:07:47 <Katy> .. we are concerned about time and following the Tag discussion
17:08:08 <Ashok> q+
17:08:18 <Katy> ... What we could do is put each issue in bugzilla and consider proactively addressing each of the issues
17:08:39 <Katy> .. then Bob could take these issues to the tag
17:09:04 <Katy> .. We volunteer to get these issues out and propose draft resolutions
17:09:21 <gpilz> q+
17:09:38 <Bob> ack ashok
17:09:40 <Katy> Ashok: There are 2 issues 1) why WS use EPRs rather than URIs?  What answer should we give?
17:10:11 <Sreed> Sreed has joined #ws-ra
17:10:12 <Katy> ... 2) We could consider what does a naked HTTP GET on the URI return?
17:11:21 <Bob> ack gp
17:12:49 <DaveS> q+
17:13:08 <Bob> ack dave
17:13:25 <Katy> Gil: Think we should address any issues at LC and not pre-empt
17:14:06 <Katy> DaveS: Don't want unecessary energy spent on this. 
17:14:33 <Katy> Asir: Understood, concerned about potential blocking issue
17:15:18 <Katy> Bob: Being prepared is good.  I am hearing mixed discussions regarding how much preemptive work should be done
17:16:06 <DaveS> q+
17:16:11 <Katy> Bob: If we use the issue process (this is public and debated and requires closure before last call).  
17:16:29 <Bob> ack dave
17:16:32 <Katy> .. These are not proper issues - other ways to approach
17:17:01 <Katy> DaveS: We can prepare a document and discuss at next F2F
17:17:26 <Ashok> q+
17:17:36 <Katy> .. I will work with you on this.
17:17:41 <Bob> ack ashok
17:18:01 <Katy> Ashok: Issues in a WG are opened against documents, what would these issues be opened against
17:18:18 <Katy> Asir: WS-T (2) and WS-RT (1)
17:19:00 <Katy> Ashok: What could we say here
17:19:57 <Katy> Asir: We could say: for 1st issue: This has been considered by the ws-ra working group and this is what we have decieded (unified voice)
17:20:25 <Katy> Asir: for 2 propose: SOAP response pattern binding to HTTP GET
17:21:10 <Yves> see http://www.w3.org/TR/soap12-part2/#soapinhttp
17:21:19 <Katy> ACTION: Asir/Dave to collaborate on a discussion document about how to proceed
17:21:19 <trackbot> Sorry, couldn't find user - Asir/Dave
17:21:47 <Katy> ACTION: Asir and DaveS to collaborate on a discussion document about how to proceed
17:21:47 <trackbot> Created ACTION-40 - And DaveS to collaborate on a discussion document about how to proceed [on Asir Vedamuthu - due 2009-03-18].
17:22:50 <Katy> TOPIC: Issue 6399 Output only in WS-Enum
17:23:28 <Katy> Dug: Propose same solution that we accepted for WS-Eventing subscription end
17:23:35 <dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0054.html
17:23:50 <dug> and change EnumEndPort to EnumEndPortType
17:24:23 <Katy> Bob: no objects
17:24:45 <Katy> RESOLUTION: 6399 resolved
17:25:58 <Katy> TOPIC: 6595 WS-Eventing Specify behaviour for empty filters
17:26:30 <dug> proposal:  http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0055.html
17:26:52 <dug> an amendment: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0056.html
17:27:32 <Katy> Gil: described issue
17:29:06 <Katy> .. Dealing with filters that will never evaluate to true - event sources should try to indicate this
17:29:51 <Katy> Geoff: As Doug said, we need to ensure that it is clear that the generation of this fault is only at subscribe time
17:30:57 <Katy> Wu: Concerned that the client may use this to test what the event source supports - interop issues
17:31:24 <Katy> Gil: This is for simple situations where the filter is easily understood
17:32:57 <Bob> It is possible for the request to contain a filter that will not evaluate to true for the lifetime of the Subscription. Although this condition cannot be detected for all dialects, implementers are advised to check for it when possible and, in response, OPTIONALLY to a Subscribe request 
17:32:59 <Bob> message generate a wse:EmptyFilter fault.
17:33:58 <dug> s/in response/in response to the Subscribe request message/
17:34:41 <li> q+
17:35:49 <dug> It is possible for the Subscribe request to contain a filter that will not evaluate to true for the lifetime of the Subscription. Although this condition might not always be detectable, implementers are advised to check for it when possible and, in response to a Subscribe request message, OPTIONALLY, generate a wse:EmptyFilter fault.
17:36:26 <Katy> Wu: not sure about 'impls advised to check for this'
17:36:34 <Katy> Gil: It is just advice
17:36:58 <Katy> Wu: But this is not preferred
17:37:02 <Bob> ack li
17:37:50 <Katy> Li: I recognise that this is a very annoying situation but it's hard to imagine how implementations could check this - e.g. xpath
17:38:57 <Katy> Gil: This is intended for filter dialects with finite values.  Just when it's possible.  Impls could do basic checks
17:39:41 <Katy> .. A key thing is to advise subscribers that an extra fault could be gen'd when it is clear that there will never be notification messages
17:40:32 <Katy> Wu: I am concerned with wording still -  'advised' text
17:40:59 <Katy> ACTION: Gil work with Wu on text for 6595
17:40:59 <trackbot> Sorry, couldn't find user - Gil
17:41:17 <Katy> ACTION: gpilz work with Wu on text for 6595
17:41:17 <trackbot> Created ACTION-41 - Work with Wu on text for 6595 [on Gilbert Pilz - due 2009-03-18].
17:41:51 <Katy> TOPIC: Alternate proposal for 6429
17:42:44 <Katy> Gil: Outlined key aspects.  EventTypemsg in its own schema plus attribute extensibility
17:43:11 <Katy> .. in wsdl dfn notifyEventMessage has hdr notify verb and body notify element
17:43:39 <Katy> .. in soap binding hdr part is bound to soaphdr and body bound to soap body
17:45:26 <Katy> .. Motivation was to put metadata in header.  wse:NotifyVerb in header - tooling will expose this verb as a parameter
17:45:54 <Katy> .. for e.g. msg bus scenario
17:46:29 <dug> q+
17:47:15 <Bob> ack dug
17:47:43 <Katy> dug: This proposal splits the service level data between the body and the headers
17:48:03 <Katy> ... This concerns me and I would like some time to discuss with implementation teams
17:48:48 <Wu> q+
17:49:10 <Bob> ack wu
17:49:18 <Katy> ... 1 week's delay
17:50:08 <gpilz> q+
17:50:22 <Katy> Wu: I propose separate this into 2 issues: 1 agree to have standard interface and separate issue of where to put the action
17:50:51 <Katy> Geoff: Agreeing with Doug again! Would like time to consider also
17:50:52 <Bob> ack gpi
17:51:24 <Katy> gpi: we need crisp texts prior to closing this issue, this proposal is just the form
17:52:02 <Wu> q+
17:52:11 <Bob> ack wu
17:53:58 <Katy> Wu: Let's close what we have decided and separate out a new action in order to deal with the extended proposal
17:54:56 <li> q+
17:57:00 <Katy> Gil: The current proposal is not complete for incorporating into the document.  Would be nice to have text describing when wrapped would be good.
17:57:47 <Katy> Wu: Explanationary text should be in primer
17:58:04 <Katy> Gil: reference to format in appendix would help
17:58:52 <Katy> Wu: we can create text changes
17:59:59 <gpilz> other probs with current text for 6429: (a) text discusses including the "concrete WSDL" in wse:NotifyTo, how is this done?
18:00:10 <Bob> ack li
18:00:26 <Katy> ACTION: Wu to examine current spec and generate new text for group review
18:00:26 <trackbot> Created ACTION-42 - Examine current spec and generate new text for group review [on wu chou - due 2009-03-18].
18:01:10 <Katy> Li: Could the verb be a ref param?
18:01:33 <Katy> Gil: No because the notification type is a constant across the lifetime of the subscription
18:02:21 <gpilz> (b) text says "concrete WSDL can be retrieved by the Event Source use WS-MEX" how?
18:02:47 <Katy> Li: Agree with Wu that we should close this issue and treat the enhancement as a sep one
18:03:27 <Katy> TOPIC: 6428 
18:03:39 <dug> q+
18:04:01 <Katy> Li: This is the proposal that treats the format as an element (rather than an attribute)
18:04:38 <Bob> ack dug
18:05:15 <Wu> q+
18:05:19 <Katy> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0053.html
18:06:03 <Katy> Dug: Would like to see text describing processing order - filter should be on unformated event
18:06:20 <Wu> q+
18:06:38 <Vikasv> Vikasv has joined #ws-ra
18:07:08 <Bob> ack wu
18:07:08 <Katy> Wu: Agreed this is a good comment.  Another issue though.
18:07:37 <Katy> ACTION: Dug to open a new issue for this
18:07:37 <trackbot> Created ACTION-43 - Open a new issue for this [on Doug Davis - due 2009-03-18].
18:09:27 <Katy> Geoff: What if can't support format element 
18:09:44 <Katy> Dug: It is an optional element that must be understood
18:10:20 <Katy> ... text decribes that the implied value is unwrapped
18:11:05 <Katy> ... must process or send a fault - not just ignore
18:11:20 <Katy> Asir: It needs adding to migration path
18:11:31 <asir> migrationPathNeeded
18:12:57 <Yves> "The keyword migrationPathNeeded has been added."
18:13:07 <asir> All hail to the power of consensus!
18:13:14 <Katy> RESOLUTION: 6428 is resolved
18:15:38 <Katy> TOPIC: 6431 WS-Eventing add resume subscription
18:16:25 <Katy> Li: Subscribe has authentication and authorisation costs so overhead if you need to unsubscribe/resubscribe
18:16:35 <Katy> ... 3 way handshake required
18:16:51 <Katy> ... pause and resume will reduce this cost
18:16:55 <dug> q+
18:17:02 <Bob> ack dug
18:17:09 <Bob> Thanks, Yves!
18:17:51 <Katy> Dug: On overflow do you retain 1st 5 or last 5
18:18:02 <Katy> ... for interop should specify
18:18:38 <Katy> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0023.html
18:18:43 <Geoff> q+
18:18:59 <Bob> ack geo
18:19:15 <Katy> Dug: Consider adding a line one way and change it later if required?
18:20:14 <Wu> q+
18:20:16 <Katy> Geoff: Do we need to discuss the value of adding pause and resume? 
18:20:27 <Bob> ack wu
18:20:30 <dug> q+
18:21:23 <Katy> Wu: value of pause and resume is highlighted in web services roadmap document (item 5)
18:22:58 <Katy> ... We think this is useful.  I am sensitive to Geoff's comment so we could make this an optional feature
18:23:09 <Bob> ack dug
18:23:51 <Katy> Dug: 2 things that should add to proposal.  1) clarify whether buffering of msgs happens before/after filtering
18:24:25 <Katy> ... 2) Retain parameter on pause and response.  I would prefer the pause to fail if the request cannot be granted
18:24:55 <Ashok> q+
18:25:04 <Bob> ack ashok
18:25:06 <Katy> Geoff: would like time to consider
18:25:45 <Wu> q+
18:25:50 <asir> perhaps, in another specification
18:26:11 <Katy> Ashok: This is extra functionality, not fundamental to the core spec
18:26:54 <Bob> ack wu
18:27:02 <Katy> DaveS: If client does not have pause/resubscribe then can it attain same function by unsubscribe/subscribe
18:28:50 <Bob> k
18:28:58 <Katy> Wu: pause/resume is a short hand so does not break interop (as it's a shorthand for unsub/sub) but retain message number is not shorthand
18:29:05 <Zakim> -Yves
18:29:39 <Katy> gpilz: how would I know whether event source supported pause resume?
18:29:45 <Katy> Dug: policies
18:29:55 <Katy> Wu: this is optional
18:30:22 <Katy> More time for discussion requested
18:31:02 <Katy> s/discussion/decision
18:31:32 <Katy> ACTION: Li to address Doug's 3 concerns
18:31:32 <trackbot> Created ACTION-44 - Address Doug's 3 concerns [on Li Li - due 2009-03-18].
18:33:17 <Bob> break until 2:45 EDT
18:38:57 <dug> Li you there?
18:41:27 <jeffm> jeffm has joined #ws-ra
18:41:57 <Zakim> +[Oracle]
18:50:12 <li> msg dug yes
18:50:27 <dug> just saw your note - I'll reply to that
18:50:38 <li> msg dug thanks
18:50:49 <Katy> TOPIC: 6498 Define the fault action URI
18:51:13 <Katy> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6498
18:52:50 <Zakim> + +1.408.970.aaaa
18:53:51 <fmaciel> fmaciel has joined #ws-ra
18:54:02 <Katy> RESOLUTION: 6498 Resolved as defined in proposal (editors update uri name)
18:55:11 <Katy> TOPIC: 6404 Mex dialect
18:56:17 <Katy> Dug: Mex dialect=group of things that service should return to client to indicate what's needed for communication
18:56:50 <Katy> ... but what if the service has metadata that the client might need (but client doesn't know about)
18:56:56 <Geoff> q+
18:57:27 <Katy> ... At extensibility to enable service to add this 'extra' metadata stuff
18:57:41 <Katy> ... on top of that add 'all' dialect
18:57:46 <marklittle> marklittle has joined #ws-ra
18:57:47 <gpilz> q+
18:58:03 <Bob> ack geoff
18:58:11 <Katy> ... then worry about default
18:58:16 <dug> q+
18:58:47 <Katy> Geoff: Our 'whateverdialect' = Doug's Mex dialect
18:59:07 <dug> 'whateva' used to mean "random - even zero"
18:59:11 <Ashok> q+
18:59:16 <Katy> ... also think that there should be a just mex dialect
18:59:18 <Bob> q+
18:59:27 <Katy> ... mex=the mex dialects
18:59:28 <DaveS> q+
18:59:52 <Katy> ... whatever=the mex dialects plus optional extras
19:01:05 <asir> q+
19:01:44 <Bob> ack gp
19:02:48 <Katy> ... mex=mex defined dialects crucial=mex plus other stuff that need to talk to service
19:03:41 <Katy> gpilz: Should rename 'mex'
19:04:10 <gpilz> 'mex' should be renamed 'defined'
19:05:26 <Katy> q+
19:05:52 <Bob> ack dug
19:05:58 <Katy> gpilz: Confusion is when a bag of dialects is named the same as a dialect itself
19:07:21 <gpilz> from smallest to largest (schema | wsdl | policy | policyAttacment), defined (set of previous), crucial (defined plus sections requester may not know about), all (everything available to the provider)
19:07:52 <Ashok> Ashok has joined #ws-ra
19:08:26 <Ashok> Ashok has joined #ws-ra
19:08:32 <Katy> Dug: The 4 dialects in the metadata spec are fairly arbitrary.  Also they can be gotton by separate requests.  So the 'mex' (or 'defined') dialects is not much use.
19:09:02 <dug> none = mex = the stuff the services thinks the client needs to talk to it - minimum = tables in mex
19:09:04 <dug> all (new uri) = everything under the sun the client is allowed to see - ie. dialect=*
19:09:56 <Katy> asir: Interop testing refer to proposal for 6420 (closed as dup of this one).  This proposal talks about min
19:11:43 <Bob> ack ashok
19:11:58 <Bob> q-
19:12:38 <Bob> ack dave
19:13:06 <Katy> Dave: I like the idea that the service knows what you need to talk to it
19:13:29 <Katy> ... eg if I don't need policy documents - why would I return them?
19:13:59 <Zakim> + +20756aabb
19:14:30 <marklittle> Hi Bob
19:14:35 <Bob> Hi
19:14:50 <Bob> zakim, aabb is marklittle
19:14:50 <Zakim> +marklittle; got it
19:15:06 <Katy> Dug: There's a difference between returning anything and what's required by the client to talk
19:16:18 <Bob> ?
19:16:21 <Bob> q?
19:19:27 <Bob> ack katy
19:19:32 <Bob> ack asir
19:20:16 <DaveS> q+
19:20:18 <asir> q+ to answer Katy's q
19:21:32 <Bob> ack dave
19:21:50 <Bob> Katy requests time to conferr with the mothership
19:22:03 <Katy> Katy: Concerned about the overlap of these dialects - the same information may be passed back in policy and wsdl dialects - a huge amount of data in duplicate
19:22:26 <Ashok> q+
19:22:36 <Katy> Katy: Puts great requirements on service and large data transfer
19:22:42 <Bob> ack asir
19:22:42 <Zakim> asir, you wanted to answer Katy's q
19:23:45 <DaveS> If we had only all and default (meaning what the service thinks the client needs), what interop or migration problems does this raise?
19:27:58 <dug> q+
19:28:05 <Bob> q+
19:28:44 <Bob> ack ash
19:30:51 <gpilz> q+
19:31:06 <Katy> Ashok: Not clear where policy documents should be returned on receipt of policy dialect
19:31:22 <Katy> Katy: policy and policy attachment dialact not clearly defined
19:31:28 <gpilz> q-
19:31:50 <Katy> Asir: Policy references give the link to the policy documents
19:32:08 <Bob> ack dug
19:32:21 <Katy> ... policy dialect is not useful on its own but is useful in a wider exchange
19:33:18 <Katy> Dug: concerned that we are overengineering and will confuse people
19:33:30 <asir> well .. at the discretion of the provider .. you may or may not return duplicates
19:33:44 <asir> s/the provider/a provider/
19:34:22 <Katy> ... no longer a for-loop service needs to interpret
19:34:34 <Katy> q+
19:35:00 <asir> other specifications may define these dialects ..
19:35:07 <Katy> Geoff: Don't let us forget the key issue - the communication bootstrap 'what do I need to talk to you'
19:35:20 <asir> but for the standards that have already sailed and relevant to WS shuld be specified in this doc
19:35:37 <asir> s/shuld/should/
19:36:07 <Bob> ack bob
19:36:08 <Katy> gpilz: just two different things 1) individual dialacts and 2) bootstrap info
19:36:52 <Katy> bob: we need to write up and understand
19:37:25 <Katy> ... few primer words to describe expected usage
19:37:49 <Bob> ack kat
19:39:10 <Katy> ... (primer like - might be doesn't need to be in primer)
19:39:26 <Katy> katy: Issue for describing dialect uri's
19:39:36 <Katy> s/uris/uri's
19:40:28 <Katy> bob: The critical set is what the provider needs to communicate?
19:40:47 <Katy> consensus to this.
19:42:17 <Katy> bob: do we agree that 'all' is useful?
19:42:33 <Katy> dug: Use case metadata browser
19:43:03 <Katy> ashok: or another non-specified dialect (e.g. legal)
19:43:10 <Katy> consensus
19:43:32 <Katy> bob: is it true that a provider can provide optimisation?
19:43:42 <Katy> consensus to this.
19:44:34 <Katy> bob: Waht about the current 'mex' which is a subset of all?
19:45:14 <Katy> bob: do we need to define this piece called 'mex'?
19:45:41 <asir> that was awesome Bob!
19:46:09 <dug> none==critical, all=all, allow for list of dialects
19:50:44 <Bob> Agreement:
19:50:46 <Bob> no dialect == everything that the provider considers important with the ability to optimize
19:50:47 <Bob> dialect="ALL" == all known metadata with ability to optimize
19:50:49 <Bob> one can specify a dialect list on the getmetaadatarequest
19:59:13 <Katy> RESOLUTION: issue 6420 resolved
19:59:30 <dug> s/6420/6404/
19:59:49 <Zakim> +Yves
20:00:06 <Katy> TOPIC: Issue 6418
20:00:20 <Katy> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6418
20:01:28 <Katy> Geoff: This may no longer be valid now that we are specifying the format
20:03:16 <Katy> ... But clarifies if the (optional) content is not there, then the service decides
20:03:44 <Katy> Dug: Is this a duplicate?
20:04:26 <Katy> Asir: it's superceded by another issue
20:04:58 <Katy> RESOLUTION: superceded by 6405, no editorial action required.  Issue closed.
20:06:17 <Katy> TOPIC: Issue 6533 - safeness of operations
20:07:09 <asir> q+
20:07:13 <Katy> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0006.html
20:07:26 <Bob> ack asir
20:08:16 <Ashok> q+
20:08:31 <Katy> Yves: Part of semantic alignment between http and transfer.  Work out whether you can retry a request
20:09:06 <Katy> asir: concerned that the contents of the table is not there - i.e. for each operation state what is safe and what is not
20:09:07 <Bob> ack ash
20:10:20 <asir> also we need to see the wording from RFC 2616
20:10:28 <dug> q+
20:10:32 <Yves> proposal is getting inspiration from http://tools.ietf.org/html/rfc2616#section-9.1
20:10:42 <Bob> ack dug
20:10:53 <asir> agree .. suggest that we prep a concrete proposal prior to closing
20:11:04 <asir> q+
20:11:25 <Katy> Dug: clarification required.  Yves - is there something in the spec that would lead you to believe that the transfer get is not safe?
20:12:06 <Katy> Yves: The spec says nothing so it is not clear.  
20:12:32 <Katy> Bob: and proposal was inspired by RFC 2616
20:13:00 <Katy> Dug: The spec already implies to me that there is no side effects to a get.  What is broken?
20:13:24 <Katy> Yves: Nothing broken, would just like this explicitly stated
20:13:35 <asir> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Feb/0045.html
20:13:41 <Bob> ack asir
20:13:49 <Katy> Asir: proposal above
20:15:25 <Yves> after a first delete, you may have an error, but in both cases the resource won't be there ;)
20:16:02 <Yves> but it would be abusive to say that the second delete would result in an operation on a resource
20:17:17 <Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-06#section-7.1
20:17:45 <Katy> Asir: Should steal 2616 def - Get is idempotent and safe; put and delete are idempotent
20:18:14 <Yves> "A sequence that never has side effects is idempotent, by definition
20:18:26 <Yves> so doing nothing on a second delete is idempotent
20:18:50 <Bob> +1 Yves
20:19:17 <Katy> Dug: I agree that we should have the table and as an editor would like the whole text so can just cut-and-paste
20:19:32 <Katy> ACTION: Yves to create red-line text for this issue
20:19:33 <trackbot> Created ACTION-45 - Create red-line text for this issue [on Yves Lafon - due 2009-03-18].
20:20:30 <Geoff> thanks everyone, thanks Bob and host IBM, signing off now...
20:20:36 <asir> +1
20:22:34 <Katy> TOPIC: 6594
20:23:53 <Katy> Geoff and Asir request time to think.
20:24:55 <Bob> short break
20:27:16 <Zakim> -[Oracle]
20:36:10 <dug> http://www.dannysbarbque.com/html/morrisville.html
20:38:27 <Katy> TOPIC: 6641 Where we get the XSD
20:38:39 <Katy> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6641
20:43:54 <Ashok> This document is also available in these non-normative formats: XML, XHTML with visible change markup, Independent copy of the schema for schema documents, A schema for built-in datatypes only, in a separate namespace, and Independent copy of the DTD for schema documents. See also translations.
20:45:03 <Zakim> -marklittle
20:45:14 <Ashok> http://www.w3.org/TR/xmlschema-2/
20:50:28 <Yves> http://www.w3.org/2003/Editors/
20:50:32 <Yves> is the best play to find out
20:51:59 <Katy> Dug: propose namespace still points to rddl, rddl points to everything, end of spec reference to xsd is a direct uri
20:53:19 <Katy> ... (as in proposal above)
20:55:07 <Katy> RESOLUTION: Resolved 6641 as described
20:56:03 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/11-ws-ra-minutes.html Yves
20:56:05 <Katy> bob: Request everyone checks IRC minutes for corrections/modifications/ommissions
20:56:14 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/11-ws-ra-minutes.html Yves
20:56:36 <Bob> http://www.w3.org/2009/03/11-ws-ra-irc
21:03:45 <Zakim> -Yves
21:03:47 <gpilz> gpilz has left #ws-ra
21:03:52 <Zakim> - +1.408.970.aaaa
21:03:57 <Bob> recessed until Tomorrow at 9:00
21:04:03 <Katy> RESOLUTION: Minutes accepted subject Tx->T
21:04:09 <TRutt> TRutt has left #ws-ra
21:04:37 <Katy> Katy has left #ws-ra
21:05:57 <dug> http://hkentcraig.com/BBQ57.html
21:09:24 <Zakim> -[IBM]
21:11:19 <li> bye
21:11:31 <Zakim> -Li
21:11:33 <Zakim> WS_WSRA(F2F)9:00AM has ended
21:11:34 <Zakim> Attendees were [IBM], Li, Yves, [Oracle], +1.408.970.aaaa, +20756aabb, marklittle
22:33:21 <Zakim> Zakim has left #ws-ra
23:40:29 <dug> dug has joined #ws-ra