IRC log of ws-ra on 2010-05-12

Timestamps are in UTC.

16:01:10 [RRSAgent]
RRSAgent has joined #ws-ra
16:01:10 [RRSAgent]
logging to http://www.w3.org/2010/05/12-ws-ra-irc
16:01:12 [trackbot]
RRSAgent, make logs public
16:01:12 [Zakim]
Zakim has joined #ws-ra
16:01:14 [trackbot]
Zakim, this will be WSRA
16:01:14 [Zakim]
ok, trackbot, I see WS_WSRA()11:00AM already started
16:01:15 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
16:01:15 [trackbot]
Date: 12 May 2010
16:01:31 [Bob]
rrsagent, this meeting spans midnight
16:01:54 [Bob]
scribenick: Tom_Rutt
16:03:06 [Bob]
agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0028.html
16:03:57 [Vikas]
Vikas has joined #ws-ra
16:04:09 [Tom_Rutt]
Topic: Agenda
16:04:10 [Tom_Rutt]
agenda accepted
16:04:26 [Zakim]
+ +1.571.262.aaaa
16:04:29 [Zakim]
-[Microsoft]
16:04:30 [Zakim]
+[Microsoft]
16:04:35 [Wu]
Wu has joined #ws-ra
16:04:41 [Zakim]
- +1.571.262.aaaa
16:05:06 [Zakim]
+ +1.571.262.aabb
16:05:53 [Tom_Rutt]
Topic: New issues
16:05:54 [Tom_Rutt]
All three new issues were accepted unanamously
16:06:12 [Vikas]
Zakim, aabb is Vikas
16:06:12 [Zakim]
+Vikas; got it
16:06:14 [Zakim]
+asoldano
16:07:09 [Tom_Rutt]
Topic: Issue 9712
16:07:10 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9712
16:08:03 [Tom_Rutt]
No objection to accept proposal
16:08:05 [Tom_Rutt]
Resolution: close 9712 by resolving as proposed
16:08:36 [Tom_Rutt]
Topic: Issue 9713
16:08:37 [Tom_Rutt]
-Issue-9713 GetStatusOperationSupported and UnsubscribeOperationSupported parameters not needed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9713 -Pilz
16:10:23 [Tom_Rutt]
Gil: they must be supported by all subscription managers. There is no optionality.
16:10:41 [Tom_Rutt]
Wu: when did we decide to make these madatory?
16:11:14 [Tom_Rutt]
Ram: the definitions of the operations state they must be supported.
16:11:48 [asoldano]
Zakim, who is here?
16:11:48 [Zakim]
On the phone I see [Microsoft], Vikas, asoldano (muted)
16:11:50 [Zakim]
On IRC I see Wu, Vikas, Zakim, RRSAgent, Bob, asoldano, Tom_Rutt, Ram, Yves, trackbot
16:12:04 [Tom_Rutt]
Ram: we decided to do this two face to face meetings ago, in Santa Clara
16:12:52 [Tom_Rutt]
No objections to accepting resolution..
16:12:54 [Tom_Rutt]
Resolution: Issue 9713 resolve by accepting proposal
16:12:56 [Zakim]
+Yves
16:13:17 [Tom_Rutt]
Topic: Issue 9717
16:13:19 [Tom_Rutt]
-Issue-9717 Frag: Add pre-defined dialect for Xpath 2.0 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9717 -Freund
16:13:23 [Dug]
Dug has joined #ws-ra
16:13:26 [Dug]
q+
16:13:45 [Bob]
ack dug
16:14:06 [Tom_Rutt]
Dug: Is this only for Frag. We define Xpath 1.0 in eventing as well.
16:14:19 [Tom_Rutt]
Bob: It is intended for all three specs.
16:14:24 [gpilz]
gpilz has joined #ws-ra
16:15:12 [Tom_Rutt]
Dug: should the new section be written just like the 1.0 section of these documents.
16:15:31 [Tom_Rutt]
No objection to applying to eventing, enum, and frag
16:15:39 [Zakim]
-Vikas
16:15:51 [Tom_Rutt]
Resolution: Issue 9717 resolved as proposed
16:17:44 [Tom_Rutt]
Topic: Issue 9700
16:18:09 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700
16:19:20 [Tom_Rutt]
Dug: he is looking for info in get metadata response as to what supported types are
16:19:31 [Wu]
Wu has joined #ws-ra
16:19:35 [Tom_Rutt]
Dug: He does not want to rely on policy
16:20:17 [Ram]
q+
16:20:45 [Tom_Rutt]
Gil: I do not understand why a get client who asked for a type, would be interested in other types.
16:21:26 [Bob]
ack ram
16:21:49 [Tom_Rutt]
Dug: If the client can deal with other types, they can use an "all" in the get metadata. He did not seem happy with this suggestion
16:22:41 [Tom_Rutt]
Ram: It seems that a fault, with the additional information, would satisfy him
16:23:21 [Tom_Rutt]
Dug: a fault is not appropriate, since there might be multiple metadata types in a single request, to fault all of them is not useful
16:23:30 [gpilz]
q+
16:23:47 [Tom_Rutt]
Dug: I think relying on interrogating policy is the best approach.
16:24:11 [Bob]
ack gp
16:24:21 [Tom_Rutt]
Dug: I would not like to tweek the protocol, when policy can meet the need
16:24:42 [Ashok]
Ashok has joined #ws-ra
16:25:27 [Tom_Rutt]
Gil: I agree with Dug. Policy is the way to do this. If this a problem that people want to profile out, why not just remove the content attribute?
16:25:48 [Tom_Rutt]
Dug: we need to give the client a way to select which types it wants
16:26:15 [Ram]
q+
16:26:24 [Tom_Rutt]
Dug: I cannot accept removing the attribute. Let them rely on policy
16:26:34 [Bob]
ack ram
16:27:12 [Tom_Rutt]
Dug: for each dialect you support, you can list the type and format you support. In section 12
16:31:25 [Tom_Rutt]
Gil: content attribute is optional, they can just say conformant profile clients cannot send the optional attribute. However, the server must be able to accept the attribute.
16:32:32 [gpilz]
we don't like using the mics
16:32:35 [Tom_Rutt]
Bob: I am hearing that the mechanisms are available, and their profile can require that clients not send the content attribute.
16:32:37 [gpilz]
we're shy
16:32:42 [Tom_Rutt]
No objection to close with no action
16:32:45 [Yves]
gil :)
16:32:56 [Tom_Rutt]
Resolution: Issue 9700 closed with no action
16:33:36 [Tom_Rutt]
Action: Ram will write the response to the originator of issue 9700
16:33:36 [trackbot]
Created ACTION-157 - Will write the response to the originator of issue 9700 [on Ram Jeyaraman - due 2010-05-19].
16:35:15 [Tom_Rutt]
Topic: Issue 9709
16:35:17 [Dug]
http://www.w3.org/Bugs/Public/attachment.cgi?id=876
16:35:17 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9709
16:37:03 [Tom_Rutt]
Dug: I modified the text around the getWSDLResponse/xs:any to allow references as well as the wsdl itself
16:37:03 [li]
li has joined #ws-ra
16:37:54 [Tom_Rutt]
added text description
16:37:56 [Tom_Rutt]
[Body]/mex:GetWSDLResponse/xs:any
16:37:58 [Tom_Rutt]
When the GetWSDLResponse element contains any child elements, the first element MUST either be the WSDL metadata document, or a reference to the WSDL metadata document, of the endpoint. Any extension elements MUST appear after the WSDL document/reference. The absence of any child elements indicates that the endpoint does not have any WSDL document, or additional metadata, associated with it.
16:38:20 [Yves]
How can a small device gain something by retrieving the same data using a new request/response insted of having the data inline. the mex env is not that big
16:39:47 [Tom_Rutt]
Dug: the use case is that the endpoint does not have the entire copy of the wsdl, however they have a pointer to where the wsdl can be obtained
16:39:49 [Zakim]
+li
16:40:33 [Tom_Rutt]
His third sentence seems to imply he is concerned about the server's requirements, not the client's
16:41:50 [Yves]
returning a reference might help caching as well
16:42:03 [Tom_Rutt]
Dug: we could suggest that the first choice is the raw data itself, only sendting the location or reference is the data is not available
16:43:00 [Tom_Rutt]
Gil: If we are concerned about the client requirements, we may need an attribute on the request, like the content attribute
16:44:21 [Tom_Rutt]
Gil: Antoine's concern is for the server. The client can do get metadata. Leave it to the service to decide. The client would use whatever means it is presented with in the response.
16:45:08 [Ram]
q+
16:45:45 [Bob]
ack ram
16:46:29 [Tom_Rutt]
Tom: what if the server wants to decide not to send the data for a short period, say due to network load. I think a mandate as to the preferred way to respond is untestable anyway
16:46:42 [Tom_Rutt]
Dug: I can live with it being totally up to the server
16:49:16 [Tom_Rutt]
Bob: is accepting the proposal acceptable to everyone?
16:49:35 [Tom_Rutt]
No objections raised
16:49:50 [Tom_Rutt]
Resolution: Issue 9709 resolved as proposed
16:50:14 [Tom_Rutt]
Action: Dug to write the response to the reviewer Antoine
16:50:14 [trackbot]
Created ACTION-158 - Write the response to the reviewer Antoine [on Doug Davis - due 2010-05-19].
16:51:09 [Tom_Rutt]
Topic: Issue 9610
16:51:39 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9610
16:53:07 [Tom_Rutt]
Dug: why call it a pseudo event?
16:53:30 [Tom_Rutt]
Bob: also correct the spelling
16:54:45 [Tom_Rutt]
Gil: I would think that a reasonable implementation would try to poke the event source before it returns the success response to the verify, otherwise a fault could be sent.
16:54:54 [Tom_Rutt]
Tom: did you define a specific fault?
16:55:11 [Tom_Rutt]
gil: in soap 12 speak it would be a receiver fault.
16:56:26 [Tom_Rutt]
Tom: could we add a note on the intent of the success reponse
16:57:55 [gpilz]
Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted.
16:58:51 [gpilz]
This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request.
16:59:34 [li]
q+
17:00:50 [Tom_Rutt]
Dug: what fault would you send?
17:01:28 [Tom_Rutt]
Gil: a receiver fault indicating an internal error would suffice
17:02:11 [Tom_Rutt]
Dug: what is the difference between this fault, and the sequenceEnd with an EndTo present
17:02:35 [Bob]
ack li
17:02:53 [Tom_Rutt]
Gil you can get this fault to the verify, but still consider the subscription as being active. It could be a short term error condition
17:04:15 [Tom_Rutt]
Li: would would be the infoset for the verification event. There is no parts for the message.
17:04:49 [Tom_Rutt]
Gil: an empty soap:Body is ok, since the information is in the WSA:Action value
17:05:12 [Tom_Rutt]
Gil I do not understand the relevance of InfoSet in this matter
17:05:50 [Zakim]
-asoldano
17:06:40 [Dug]
q+
17:07:19 [Tom_Rutt]
Wu: the verification event could contain information about the subscription
17:07:20 [li]
q?
17:07:47 [Tom_Rutt]
Gil: the verify event is the same as any other event which can be sent from the event source, other than the fact that is is never filtered
17:08:31 [Tom_Rutt]
Wu: carry in the verify event which particular verify request invocation is being responded to
17:09:06 [gpilz]
q+
17:09:24 [Tom_Rutt]
Tom: he seems to be asking that the verify event report carry the message id for the verify request that stimulated it
17:09:33 [Tom_Rutt]
Dug: why would we need that
17:10:32 [Tom_Rutt]
Wu: It could give information on the delay between the request and the event emission. It would also allow detection of verify requests which never resulted in a verify event. More diagnostic information is available
17:11:55 [Tom_Rutt]
Dug: Wu's proposal requires more complexity in the communication between the subscription Manager and the event source. Also it implies a complicated set of analysis by the event sync
17:12:00 [Bob]
ack d
17:12:04 [Bob]
ack g
17:12:09 [Tom_Rutt]
Wu: I would prefer that we have time to think about this further
17:13:29 [Tom_Rutt]
Gil: This extension to correlate verify event with the verify request is going beyond the requirements behind this issue. Timing aspects of the path verification are not required for the use case.
17:14:28 [Tom_Rutt]
Gil: I do not see the relevance of the infoset problem.
17:14:36 [Dug]
q+
17:14:55 [Bob]
ack d
17:15:00 [Wu]
q+
17:15:06 [Wu]
q+
17:15:35 [gpilz]
Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted. This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request.
17:17:02 [Tom_Rutt]
Dug: I can live with the implementation note. However, I would like to see more information on the types of fault that may be returned. When would that fault not be bad enough to kill the subscription?
17:17:36 [Tom_Rutt]
Tom: there might be a temporary condition causing the lack of communication between the sub manager and its event source.
17:17:43 [Ram]
q+
17:18:06 [Bob]
ack w
17:18:32 [gpilz]
q+
17:18:36 [Tom_Rutt]
Gil: The client receiving this fault without a subscription end would tell the client it can try the verify again at a later time, with the potential of success
17:19:25 [Bob]
ack r
17:20:11 [Tom_Rutt]
Wu: we would like time to consider extension to the simple proposal, which may make it more useful for other use cases
17:22:08 [Wu]
q+
17:22:23 [Bob]
ack g
17:22:24 [gpilz]
ws-man v1.1 says this about the heartbeat event: "The heartbeat event itself is simply an event message with no body and is identified by its wsa:Action URI as follows: . . ."
17:22:36 [Tom_Rutt]
Ram: we could modify the get status semantics to require that the sub manager only return a success if it knows the event source is alive. That would cover this requirment
17:23:13 [Bob]
ack wu
17:23:37 [gpilz]
q
17:23:46 [gpilz]
q+
17:23:51 [Bob]
q+ gp
17:23:57 [Bob]
q- gp
17:24:04 [Tom_Rutt]
Tom: Ram's suggestion covers have of the requirement for heartbeat, It would not also verify the communication path between an event source and its event sync, in the case where the event source is at a different sending port than the port used by the subscription manager get status response
17:24:22 [Tom_Rutt]
s/covers have/covers half/
17:24:41 [Ram]
q+
17:25:19 [Ram]
q-
17:26:00 [Bob]
ack gp
17:26:04 [Ram]
q+
17:26:22 [Tom_Rutt]
Gil: it is not possible for the event source to verify its link to the event sink.
17:26:36 [Yves]
do we need to check everything, from the path between the sub manager to event generator, to the even generator and receiver?
17:27:02 [Tom_Rutt]
Bob: to turn this into a network diagnostic would require a lot of additional mechanisms to be in place.
17:27:21 [Tom_Rutt]
Dug: there may be proxies between the event source and the event sink
17:27:28 [Ram]
q-
17:28:11 [gpilz]
q+
17:29:04 [Tom_Rutt]
Bob: it is difficult to think of all the possible failure modes in this kind of a "ping" mechanism. We need to restrict our discussion to finding a proposal to meet the needs that issue originator brought forward, with sufficient widespread use to make it part of the base eventing spec.
17:29:15 [Wu]
q+
17:29:58 [Tom_Rutt]
Bob: they are asking for a heartbeat mechanism to figure that both the event source is alive, and also that the communication channel between source and sink is functioning.
17:30:27 [Bob]
ack g
17:30:55 [Bob]
ack w
17:31:01 [Tom_Rutt]
Gil: I would hate to see this issue hold up our specs. If we cannot agree to a simple solution that meets there needs, I would prefer to close with not action
17:32:26 [Tom_Rutt]
Wu: how about modifying the get status operation to have the get status response be returned from the event source to the event sync
17:33:05 [Tom_Rutt]
Gil: That would cause more problems than it solves. The get status requester may not be the same as the event sink
17:33:30 [Ram]
q+
17:34:38 [Yves]
get status through the event sink is a bad solution, even delivery and status checking are two different things
17:35:03 [Tom_Rutt]
Gil: perhaps the verify feature could be triggered by an extra parameter to the get status.
17:35:20 [Bob]
ack ram
17:36:21 [Tom_Rutt]
Dug: I think that it makes sense to have the information on the get status response to be returned in the verify response. Why do we need two operation types, if an option on get status could add the triggering of verify event
17:37:45 [Bob]
zakim, who is here?
17:37:45 [Zakim]
On the phone I see [Microsoft], Yves, li
17:37:47 [Zakim]
On IRC I see li, Ashok, Wu, gpilz, Dug, Vikas, Zakim, RRSAgent, Bob, Tom_Rutt, Ram, Yves, trackbot
17:38:13 [Bob]
ack r
17:40:10 [Tom_Rutt]
Bob: who in in favor of changing the proposal to adding an optional verify element to get status to also do the verify event trigger.
17:40:46 [Tom_Rutt]
Several indicate that if we do anything for the verify, we should merge it as a feature of get status.
17:41:35 [Tom_Rutt]
Only Fujitsu and Oracle indicated that this new verify feature be added to get status.
17:42:05 [Tom_Rutt]
Wu: I could accept such an addition if if did more than the simple proposal.
17:42:53 [Tom_Rutt]
Bob: can we have a decision by Thursday morning?
17:42:54 [Tom_Rutt]
Agreed that we will schedule decision for Thursday morning of F2F.
17:51:37 [Zakim]
+Vikas
18:01:26 [Tom_Rutt]
Topic: Issue 9675
18:01:28 [Dug]
http://www.w3.org/Bugs/Public/attachment.cgi?id=875
18:01:28 [Tom_Rutt]
-Issue-9675 Eventing: Clarify attachment of NotificationWSDLs to the EventSource policy assertion http://www.w3.org/Bugs/Public/show_bug.cgi?id=9675 -Mensch
18:02:13 [Zakim]
-Yves
18:02:24 [Zakim]
-Vikas
18:02:38 [Zakim]
+Vikas
18:02:50 [gpilz]
q+
18:04:23 [Tom_Rutt]
Dug: I did what we agreed to yesterday.
18:04:41 [Zakim]
-Vikas
18:04:48 [Tom_Rutt]
Gil: I would like to remove the word "only" in the second line of the explanation for the example.
18:06:51 [Tom_Rutt]
Dug: I can live with removing the word "only", it is true but I agree not necessary
18:07:16 [Tom_Rutt]
No objection to accepting amended proposal
18:08:03 [Tom_Rutt]
Resolution: Resolve Issue 9675 with proposal as amended by striking word "only"
18:08:25 [Tom_Rutt]
Topic: Issue 9701
18:08:27 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9701
18:09:21 [gpilz]
q+
18:10:28 [Tom_Rutt]
dug: there is no requirement for event source to understand anything other than NotifyTo element. He wants a fault when the event source cannot accept an extension
18:11:50 [Tom_Rutt]
Bob: we had this discussion at past F2F regarding the usual soap extension model.
18:12:07 [Zakim]
+Vikas
18:12:27 [Tom_Rutt]
Bob: why do we need a fault, why not just eliminate the sub manager epr from the response?
18:13:59 [Tom_Rutt]
Dug: we are really trying to say that there must be some delivery mechanism present. However the wording puts it in xml speak. He would rather have a fault, rather than just creating the subscription after ignoring extensions
18:14:56 [Bob]
ack gp
18:15:29 [Tom_Rutt]
Gil: they want new fault, "I recognize there is something extra in the request, but I do not know what to do with it"
18:17:18 [Tom_Rutt]
Dug: define "no delivery mechanism fault" when there are not children elements, or not elements which are understood by the event source
18:17:41 [Tom_Rutt]
s/not elements/no elements/
18:18:05 [Tom_Rutt]
Gil: but I might understand, but do not want to support the mechanism.
18:18:29 [Tom_Rutt]
Bob: Fault when no delivery mechanism has been established.
18:18:47 [Dug]
NoDeliveryMechanismEstablished
18:18:52 [Tom_Rutt]
Agreed to have Dug write a full proposal which reflects the discussion above.
18:19:43 [Tom_Rutt]
Resolution: Resolve Issue 9701 by adding new Fault "NoDeliveryMechanismEstablished" with appropriate explanatory text
18:20:42 [Tom_Rutt]
Action: Dug to write response to issue 9701 reviewer explaining our solution to his issue
18:20:42 [trackbot]
Created ACTION-159 - Write response to issue 9701 reviewer explaining our solution to his issue [on Doug Davis - due 2010-05-19].
18:21:16 [Tom_Rutt]
Topic: Issue 9702
18:21:18 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702
18:21:50 [Tom_Rutt]
Gil: Antoine seems to assume you can profile out features that the base spec states you MUST support
18:22:47 [Tom_Rutt]
Dug: you have to understand these attributes, while you do not have to support all the values
18:24:26 [Tom_Rutt]
Gil: this is a sender optional feature, thus the service must be capable of handling it when present. They could profile as "conforming clients in this profile MUST NOT include this in the request message
18:26:27 [Tom_Rutt]
Gil: they seem to be worried about clients which do not conform to the profile. The only way to give him what he wants is to change the definition of this feature being both client and server optional
18:27:04 [Tom_Rutt]
Gil: you would have to add a policy parameter for this, and also add a fault to indicate the server does not support it.
18:31:35 [Tom_Rutt]
Dug: what if the server supports the syntax, however it never can satisfy any value in the expires. It can send the existing fault all the time
18:38:20 [Tom_Rutt]
Gil: we could make the entire expiry mechanism to be server optional. The policy and fault would be indicating non-support of entire expiry mechanism. The other alternative resolution is close No Action
18:41:00 [Tom_Rutt]
Dug: another alternative is only allow a duration for expiry. Get rid of min and max
18:41:55 [Dug]
and exact
18:44:58 [Ram]
q+
18:47:06 [Tom_Rutt]
Bob: for servers that do not support ranges of time, they will simply respond to the max value
18:47:48 [Tom_Rutt]
Gil: the server can just pick the max and give it to the subsription
18:48:48 [Tom_Rutt]
Dug: they want to have the server to be able to pick the expiry time, irregardless of what the client requests
18:50:14 [Bob]
ack ram
18:50:33 [Tom_Rutt]
Dug: the spec requires that the server check that min is smaller than the max, otherwise fault the request
18:52:05 [Tom_Rutt]
Dug: how about "no expires element -> server choice" , "Exact time, if present must be honored to create subscription"
18:53:36 [Tom_Rutt]
Dug: also have expires be server optional
18:54:55 [Tom_Rutt]
Gil: I would like to get rid of date/time, and rely on duration only
18:56:05 [Dug]
Expires is server optional, add a fault for when its not, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault
18:56:38 [Dug]
s/its not/its not supported/
19:02:40 [Tom_Rutt]
No object to the above a directional resolution
19:02:59 [Tom_Rutt]
Agree to finalize decision on Thursday morning
19:03:48 [Tom_Rutt]
s/above a directional/above as a directional/
19:34:59 [Zakim]
-li
19:39:19 [Zakim]
-Vikas
20:08:50 [Tom_Rutt]
Reconvene at 1:08 PM
20:11:45 [Tom_Rutt]
Topic: Issue 9700 Response
20:15:22 [Tom_Rutt]
Dug: if the content attribute is not present, the default is any format. However, they cannot profile out the server behaviour when the content attribute is present but not supported.
20:16:28 [Tom_Rutt]
Dug: when the content attribute is present, the server must support it or not accept the request.
20:17:12 [Tom_Rutt]
Topic: Issue 9703
20:17:13 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9703
20:17:15 [Tom_Rutt]
Review event descriptions and their attachment mechanisms
20:17:19 [Zakim]
+Yves
20:18:04 [Dug]
http://www.w3.org/Bugs/Public/attachment.cgi?id=878
20:21:22 [Tom_Rutt]
Dug: one thing Antoine is concerned about is the potential duplication when the same event type is associated with more than one wsp:Policy assertion type
20:23:17 [Tom_Rutt]
Dug: he wants an element in the wsdl descriptions doc which has list of event types. This element is referred to in the wsp:Policy.
20:24:18 [Tom_Rutt]
Dug: he is adding the wse:Notification element to policy eventSource which has an attribute pointing at that element in the descriptions doc.
20:25:00 [Tom_Rutt]
Dug: He wants to be able to have everything in a single document, and also have reuse of the definitions in that single document.
20:26:47 [Tom_Rutt]
Dug: rather than adding this notifications element to the policy assertion, have the mex:Location to have a relative URL so it can point to EVDs that are embedded within the same doc.
20:27:56 [li]
li has joined #ws-ra
20:28:20 [Tom_Rutt]
Dug: this would be a change to the mex spec to allow relative url, and also to the event spec to allow multiple event description elements within the event source assertion.
20:28:46 [Zakim]
+li
20:30:40 [Tom_Rutt]
Dug: I have some concerns about the relative URL. we would have to use the wsu:Id attribute
20:31:34 [Tom_Rutt]
Gil BP does not allow wsdl description extensions to be required.
20:32:15 [Tom_Rutt]
Dug: I like this relative URL better than using a QName pointer mechanism
20:34:28 [Tom_Rutt]
Dug: my proposal would still put the event description in the wsdl, but changes the way it is pointed at.
20:35:23 [Tom_Rutt]
Dug: for the Notification WSDL , his QName points to a port type
20:38:45 [Tom_Rutt]
Dug: my proposal again allows mex:Location to be relative. the mex:Location would have a Type attribute.
20:40:12 [Tom_Rutt]
Dug: notion of relative URI for mex:Location is a change which can be justified on its own right. The change is allowing more than one event description to appear, and a reference for the wsdl element.
20:41:53 [Tom_Rutt]
Dug: our event source assertion needs to describe what happens when there are multiple instances appearing inside it.
20:43:13 [Tom_Rutt]
Gil: I would like some time to think about this one.
20:43:30 [Tom_Rutt]
Agreed to defer decision until Thursday at this F2F
20:44:09 [Tom_Rutt]
Topic: Issue 9671 resolution incorporation into spec
20:44:11 [Dug]
http://www.w3.org/2002/ws/ra/edcopies/wsmex.html
20:44:35 [Dug]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0024.html
20:45:10 [Wu]
Wu has joined #ws-ra
20:47:20 [Tom_Rutt]
In addition to the edits in Katy's
20:47:22 [Tom_Rutt]
proposal, the following additional things were changed:
20:47:24 [Tom_Rutt]
- Updated xsd
20:47:25 [Tom_Rutt]
- Updated wsdl
20:47:27 [Tom_Rutt]
- Added Content to DeleteMetadata request (more below)
20:47:29 [Tom_Rutt]
- Added the Fault boilerplate text to the new "Faults" section
20:47:30 [Tom_Rutt]
- Added the boilerplate text to the Notational Conventions section about
20:47:32 [Tom_Rutt]
"generate"
20:47:33 [Tom_Rutt]
- Added a ref to the WSA SOAP Binding spec - due to the new faults section
20:47:35 [Tom_Rutt]
- Added ... to GetMetadataResponse pseudo-schema
20:47:36 [Tom_Rutt]
Dug:
20:49:37 [Tom_Rutt]
Dug: I want everyone to be aware of the changes I made, and to ensure that I did not make any mistakes during editing
20:50:08 [Dug]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0024.html
20:50:14 [Tom_Rutt]
I've included two word docs - one is a diff of the final mex spec against
20:50:16 [Tom_Rutt]
the mex spec prior to these edits, and one is a diff of the mex spec
20:50:17 [Tom_Rutt]
against Katy's proposal. This will allow people to see the edits from two
20:50:19 [Tom_Rutt]
different perspectives. FYI - some of the diffs in the *-katy-diff.doc
20:50:21 [Tom_Rutt]
are due to the other issues we resolved today not being part of Katy's
20:50:22 [Tom_Rutt]
version - so you can ignore those change bars.
20:50:24 [Tom_Rutt]
http://www.w3.org/2002/ws/ra/10/05/wsmex-9671-diff.doc
20:50:25 [Tom_Rutt]
http://www.w3.org/2002/ws/ra/10/05/wsmex-9671-katy-diff.doc
20:52:37 [Tom_Rutt]
Topic: Issue 8284 References to wsdl 1.1 corrected version of schems
20:53:36 [Tom_Rutt]
Gil: We have a proposal on the table of the BP group on this topic, and are working hard to partitioning the section on wsdl into two sections: Changes to Wsdl spec vs Profiling of WSDL requirements.
20:54:43 [Tom_Rutt]
Bob: open issues include 8284, Heartbeat/verify, Expiration time not supported, Event descriptions attachment mechanisms
20:55:03 [Tom_Rutt]
All but 8824 are scheduled for decision Thursday of this F2F
20:55:26 [Tom_Rutt]
Topic: At Risk Determination and Testing
20:55:57 [Tom_Rutt]
Bob: our charter requires for each feature in spec, in order to exit CR we need to have two independent implementations that implement those features
20:55:59 [Zakim]
-Yves
20:56:51 [Tom_Rutt]
Bob: we need to get an Idea of which parts of the spec companies are not planning to implement
21:10:00 [Zakim]
-[Microsoft]
21:16:00 [Tom_Rutt]
Company, Enum, Event, EVD, Trans, Frag, SA, Mex
21:16:01 [Tom_Rutt]
IBM, ?, I, I, I, I, I, I
21:16:03 [Tom_Rutt]
MS, I, I, ?, I, I, ? I
21:16:04 [Tom_Rutt]
ORCL, ?, I, I, ?, ?, I, ?
21:16:06 [Tom_Rutt]
Avaya, X, I, X, X, X, X, X
21:16:07 [Tom_Rutt]
Fujitsu, I, I, ?, ?, ?, ?, ?
21:16:09 [Tom_Rutt]
Hitachi, I, I, ?, I, I, ?, ?
21:16:34 [Tom_Rutt]
Bob: we need to poll CA, SAG, and Red Hat
21:19:49 [Tom_Rutt]
Key: ? Thinking, X Won't, I Intend date TBD
21:27:49 [Tom_Rutt]
Bob: I propose to all to look at SoapUI as a tool to employ for testing
21:29:53 [Tom_Rutt]
Bob: we need to get the people from each company who will be doing the test implementations together
21:30:41 [Tom_Rutt]
Bob: we will be testing the spec in a behavioral sense. Not a man in the middle network sniffing based approach (such as done in WS-I)
21:34:39 [Tom_Rutt]
Bob: for each of these specs we have to determine on a feature by feature basis which features will be implemented by at least two implementations
21:36:17 [Tom_Rutt]
s/\? I/\?, I/
21:37:39 [Tom_Rutt]
Bob: we need to convert all the Intentions into a specific date . What is the Date that we have Dates ready by?
21:41:15 [Tom_Rutt]
Dates for the Date
21:41:17 [Tom_Rutt]
IBM 7/ Begin
21:41:18 [Tom_Rutt]
MS 9/Begin
21:41:20 [Tom_Rutt]
ORCL 7/ Begin
21:41:21 [Tom_Rutt]
Avaya 9/ B
21:41:23 [Tom_Rutt]
Fujitsu 9 / B
21:41:46 [Tom_Rutt]
Hitachi 9/ B
21:46:01 [Tom_Rutt]
ACTION: Gill to catalogue eventing with an eye to which features might be at risk
21:46:01 [trackbot]
Sorry, couldn't find user - Gill
21:47:17 [Tom_Rutt]
ACTION: Gil to catalogue eventing with an eye to which features might be at risk
21:47:17 [trackbot]
Sorry, couldn't find user - Gil
21:48:01 [Tom_Rutt]
ACTION: gpilz to catalogue eventing with an eye to which features might be at risk
21:48:01 [trackbot]
Created ACTION-160 - Catalogue eventing with an eye to which features might be at risk [on Gilbert Pilz - due 2010-05-19].
21:56:14 [Tom_Rutt]
Bob: Features in the CR marked at risk, will not be included in the Final Rec, if they have not met the implementation bar. Features that have not been marked at Risk in CR, will prevent the spec from reaching Rec status until those features reach the implementation bar
22:01:13 [Tom_Rutt]
Bob: how can we distribute out the specs to people to define the test scenarios and methods to test each feature in the feature catalogue
22:02:04 [Tom_Rutt]
Dug: can the scenario doc be the same template for each ws-ra spec?
22:02:29 [Tom_Rutt]
Gil: can we agree to basic principles for each scenario.
22:03:07 [Tom_Rutt]
Gil: E.G. any person who is not a member of the WG should be able to understand the contents of each test scenario
22:03:49 [Tom_Rutt]
ACTION: Dug to create a template for test scenario Doc to use for all of the WS-RA specs
22:03:49 [trackbot]
Created ACTION-161 - Create a template for test scenario Doc to use for all of the WS-RA specs [on Doug Davis - due 2010-05-19].
22:03:50 [Zakim]
-li
22:03:52 [Zakim]
WS_WSRA()11:00AM has ended
22:03:54 [Zakim]
Attendees were [Microsoft], +1.571.262.aaaa, +1.571.262.aabb, Vikas, asoldano, Yves, li
22:35:29 [Zakim]
Zakim has left #ws-ra
22:37:27 [Tom_Rutt]
Gil: Mex needs a primer.
22:37:29 [Tom_Rutt]
Bob: Katy has volunteered to write the primer on MEX
22:39:24 [Tom_Rutt]
Topic: Next F2F
22:42:00 [Tom_Rutt]
Feature Catalog volunteers:
22:42:02 [Tom_Rutt]
Gil: Eventing, EVD
22:42:39 [Tom_Rutt]
Katy - MEX
22:42:54 [Tom_Rutt]
Ram - Transfer
22:43:29 [Tom_Rutt]
Dug - Frag, SA
22:44:11 [Tom_Rutt]
Dave S - possibly for Enum
22:49:43 [Bob]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9607
22:50:52 [Tom_Rutt]
Topic: review Responses to reviewers
22:51:16 [Wu]
Wu has joined #ws-ra
22:51:29 [Bob]
Please indicate your agreement or disagreement to this resolution by a reply to this email
22:51:58 [Tom_Rutt]
Agreed we need to add above sentence to each response
22:52:40 [Tom_Rutt]
Agreed to send response on 9607 to Gil with the added sentence
22:53:28 [Tom_Rutt]
Topic: Response to Issue 9608 reviewer
22:53:30 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9608
22:55:03 [Tom_Rutt]
agreed to add the additional para to Tom's suggestion: "the WG
22:55:05 [Tom_Rutt]
believes that the number of potential items in the enumeration, while
22:55:07 [Tom_Rutt]
interesting, isn't nearly as valuable as the total size of the
22:55:09 [Tom_Rutt]
enumeration (total byte count of the data, not just the # of items).
22:55:10 [Tom_Rutt]
This would allow for better pre-allocation of resources than simply
22:55:12 [Tom_Rutt]
knowing the number of items. However, since calculating the total
22:55:13 [Tom_Rutt]
size of the entire enumerated data set could be very expensive, the
22:55:15 [Tom_Rutt]
cost of doing this at Enumerate() time didn't seem to be worth the
22:55:16 [Tom_Rutt]
additional cost." as well as the boilerplate last sentence
22:56:09 [Tom_Rutt]
Also make the bug number correct in the response (9608)
22:57:00 [Tom_Rutt]
Topic Response to issue 9609
22:57:26 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9609
22:57:28 [Tom_Rutt]
Agreed to send proposal from Gil on response
22:57:56 [Tom_Rutt]
Topic Response to issue 9611
22:57:57 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9611
22:59:41 [Wu]
Wu has joined #ws-ra
23:00:44 [Tom_Rutt]
Dug: I an not happy with the first paragraph, since there is nothing in the spec which states you can put multiple event reports in a wrapped format (even if they have the same action value)
23:01:33 [gpilz]
q+
23:01:47 [Tom_Rutt]
Wu: however we can do this today, without violating the ws eventing spec
23:03:11 [Tom_Rutt]
Gil: I would not accept this unless we had a paragraph in the spec regarding whether the order is significant (e.g., switch open/ switch close / switch open). It would be dangerous to imply you can do this unless you have text stating the assumptions on ordering in time
23:04:03 [Tom_Rutt]
Dug: we also have to be concerned about the faulting of specific event reports in the batch. We have not thought about this in the spec, so I do not like us implying this as a possibility in our response
23:04:52 [Tom_Rutt]
Bob: how about removing the second sentence of first para
23:06:05 [Tom_Rutt]
Also, remove "Beyond that, the group feels:" as the second para intro
23:06:19 [Tom_Rutt]
Add the boilerplate last sentence
23:12:30 [Tom_Rutt]
Wu: why cannot we add text to the spec regarding using wrapped to do some form of batching?
23:13:16 [Tom_Rutt]
Bob: that would have to be raised as a new issue, it is not available at this time to put in a response to the ws-management group
23:14:58 [Tom_Rutt]
Topic: Response to Reviewer of Issue 9612
23:15:00 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9612
23:16:59 [Tom_Rutt]
agreed to send with additional boiler plate last sentence
23:18:07 [Wu]
Wu has joined #ws-ra
23:18:26 [Tom_Rutt]
Topic: Response to Reviewer of Issue 9613
23:18:28 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9613
23:18:47 [Tom_Rutt]
Agreed to send as is with addition of final boiler plate sentence
23:19:39 [Ram]
Proposed response: The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support
23:19:41 [Tom_Rutt]
Topic: Response to Reviewer of Issue 9700
23:19:43 [Tom_Rutt]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9700
23:20:47 [Tom_Rutt]
Ram: I posted my proposed response just above
23:23:34 [Ram]
The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support a particular conten
23:23:42 [Tom_Rutt]
Dug: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server otion
23:23:49 [Ram]
of Content attribute allowing a service to return any content type.
23:26:10 [Ram]
The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type.
23:26:21 [Ram]
This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format.
23:26:30 [Ram]
Hence, there is no need for a fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type.
23:27:07 [Ram]
[1] “When not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".”
23:29:26 [Bob]
The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states [1] that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a...
23:29:27 [Bob]
...fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type by a client. [1] “When not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".
23:34:07 [Tom_Rutt]
Add first para: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server option
23:36:08 [Ram]
Further, if the client wants a particular content type or format, it can request that by specifying that in the GetMetadata request.
23:47:43 [Bob]
public-ws-resource-access-comments@w3.org
23:49:12 [Tom_Rutt]
Topic: Response to reviewer of Issue 9558
23:49:14 [Tom_Rutt]
Bob responded to Fred on this
23:52:38 [Bob]
recessed until tomorrow at 9:00
23:52:48 [Bob]
rrsagent, generate minutes
23:52:48 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/05/12-ws-ra-minutes.html Bob
23:55:19 [Tom_Rutt]
http://www.w3.org/TR/ws-policy/#Policy_References
23:57:07 [gpilz]
gpilz has left #ws-ra