IRC log of ws-ra on 2009-03-11
Timestamps are in UTC.
- 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:55 [Zakim]
- Zakim has joined #ws-ra
- 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