Web Services Resource Access Working Group Teleconference -- 11 Jun 2009

<trackbot> Date: 11 June 2009

<Bob> trackbot, start teleconference

<trackbot> Meeting: Web Services Resource Access Working Group Teleconference

<trackbot> Date: 11 June 2009

<Ram> Scribe Ram

<Bob> scribe: Ram

Doug: Yesterday, when we talked about 6712, we removed the implied value. But we need to define an implied/default value for interop.

<dug> This specification defines one ContentDescription URI, http://.../ContentDescription/Representation, to indicate that the child element is the literal representation of the resource.

Gil: Should this be another issue?

Dug: If this can be handled editorially, no need to open a new issue.
... It is encumbent upon us to define an default URI, if the contentDescription hint is used.

Geoff: I need a little time to think about this.

Bob: OK. We will give Geoff more time and come back to this later.

Issue 6401 discussion.

Gil: One of points of consensus yesterday was that existing WSDL tools be able to handle writing event sinks.
... Recap: It is important to advertise notification types. As a developer, I should be able to look at a event source and identify the notifications. It is important to do this using existing WSDL based tools. It becomes murky when we talked about wrapped vs raw.
... We need to re-examine the approach of wrapped notifications and think it over.

Geoff: Is the definition of notification a subset of message types?

Gil: Notification is defined to a SOAP message. Section 5 says notification can be ANY message. A subset of all notifications that exist out there can be described using a type.
... Two notifications can have different wire contents and yet still have the same type. For example, one of them could be raw and the other wrapped.

Geoff: Is your description language describing any possible notification?

Gil: No.

Geoff: Is that a problem?

Gil: By describing a large subset of things you want to do, we can accomplish what is reasonable.
... Are there any important use cases that cannot be handled by my approach?

Doug: Can anything that appears in a WSDL can appear as a notification?

Gil: This proposal has the effect of constraining which WSDL operations can appear as a notification.
... With my approach, we cannot have application content in a SOAP header.

Dug: That is not correct. Your thing is not about wire presentation and hence it does not constrain.

Gil: Yes.

Geoff: I understand that. It appeared that the description language could not describe all things I could do in the WSDL.
... Can the WSDLs that are generated in your approach capable of generating WSDL as it would be produced by the raw approach.
... Would it cover all possible cases of WSDL usage?

Dug: The notification description describes the events, just like Schema describes data, and WSDL describes what is sent on the wire.
... It is not meant to replace WSDL.
... It is used as part of the WSDL.

Wu: There is a lot of commonality between the two approaches.
... One question I have: How can an event sink know what service the source can offer from the notification type?

Gil: That is a separate issue. That is, how we are going to express this via policy. More work needs to be done.
... I am an event source. I support raw/wrapped, format/filters, etc. The purpose of this issue is to decouple the policy issue from the notification type. We should tackle them separately.

Wu: My point is very simple. An endpoint has a WSDL and I can tell by looking at the WSDL I can tell what notifications that service supports.

Gil: Without policy how do you know where to find the notification WSDL?

Dug: How does the event source describe the various formats, filters, it supports. That is a separate issue.

Wu: Event source today publishes event source and notification WSDL.

Gil: There is no notification WSDL.

Wu: Why can't we attach a notification WSDL to the source WSDL.

Gil: Via policy.

Wu: May be.

Li: My sense is that the difference between the proposals is the event source publishes the service description and how the sink consumes it.
... It would help me if we understand in Gil's approach we can understand the steps from publication of Notification WSDL to the subscriber finding out about the Notification WSDL.
... The event source and sink would take the Notification WSDL and generate their own WSDLs. Are the generated WSDL on different sides communicated to the other side?
... Are they in sync? what is their purpose? It is just code generation?

Gil: I as a sink do not know what all notifications I may receive. The only way I can support this is via wrapped.
... Let us say that I can handle a set of notification types (wrapped). I want to know about the raw notifications that are contained in the wrapped form.

I would do a Mex.GetMetadata call to get a description of the raw notifications.

Gil: The generated WSDL from the raw notification information may contain only the raw notifications that the sink is interested in.
... This issue about WSDL compatibility is a funny one. It is possible to have different WSDL produce wire compatible messages.
... Section F of my proposal says how the portype and other associated data is generated.
... It is not important that the event sink and source WSDLs match exactly. At a minimum, the Action URI and GED must match. My approach relies on doc-literal binding.

Asir: Gil: Notification WSDLs describes only the notification types.
... I saw that you are mapping the independent notification types to a wrapped or a raw notification. How do you generate wrapped Notification WSDL?

Gil: The whole point about the wrapped Notification WSDL is that not all operations/notifications need to be described.
... I may want to filter messages based on wrapped notification types, such as using XPath.

Dug: Gil's proposal provides a mechanism to provide additional data that may not be present in the WSDL.
... This also includes information that may not appear on the wire. For example, topics and queues for notifications.

Li: The major difference in the proposal is why do we need a new metadata construct?

<asir> I am still hazy on why we need a new metadata language, notification description

Li: Why can't we use the existing WSDL as UDDI does?
... Why do we need the notification description? WSDL can already do that!

Gil: You are correct that you don't need all the notification description. But at least we need the port type.
... The qname of the GED and the Action URI associated with the port types are essential.

Li: In the notification description approach, the WSDL needs to be generated.

Gil: If you use only the wrapped notification, no need for WSDL generation.

Li: I am talking about raw event notifications.
... How do you do the serialization/deserialization of raw events? Don't you need a WSDL anyway for raw events?
... My question really is that I have problem understanding the critication advantage of notification description mechanism as opposed to simple WSDL approach.

Gil: It is hard to use the WSDL approach to do this.
... What about typing?
... Sorry what about topics? Notification descriptions provides us a nice mechanism to do the same.

Li: There are shortcomings where information cannot be captured in notification description.

Gil: Notifications map to one-way application message.

Li: The shortcoming is when you want to capture notification with acknowledgements.

<dug> Notification

<dug> A one-way message sent to indicate that an event, or events, have occurred.

Li: WS-Eventing is a protocol establishes the channel. What flows on the channel should remain unconstrained.

Wu: How about we present our proposal?

<asir> I think what Li is saying is that any proposals for 6401 should not interfere with the delivery model in Eventing

Dug: When the event source sends out only wrapped notifications, should the WSDL include the message descriptions for the raw notifications?

Li: No.

Dug: How does the sink get information about what the source supports?

Li: I will replace the notification description with a WSDL. The subscriber will use the WSDL to get that extra information.

Dug: Technically, you may be able to put the notification description into a WSDL. But are we not overloading the WSDL mechanism?
... In both cases, I need to write custom code. Which is better?
... There are pros and cons either way.

Back from break.

<PrasadY> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401

Issue 6401 discussion continuation.

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/att-0029/Web_Services_Eventing__WS-Eventing_.htm

Li to discuss his proposal.

<li> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/att-0029/Web_Services_Eventing__WS-Eventing_.htm

Li: Go to Appendix A in the proposal.

Wu: This approach does not have any changes except Appendix A.

Asir: Can Li describe what problem he is trying to solve and what is the motivation.

Li: The motivation is to address the BP R2303 restriction about WSDL output-only operations.
... and to make WS-Eventing BP compliant.

Gil: I would like to know when you step through the linkages between the event notifications and notification description.

Li: This proposal is based on Gil's original idea.
... Go to Appendix A in the proposal.

<Bob> ack asir, gpi

Li: Take the ouput-only operations in the source WSDL and put them in the Notification WSDL.
... The idea is to replace offending operations.

Dug: Why do we need two WSDLs.

Li: The first WSDL is for the subscriber. The other is for the event source to have a normal request-response operations.
... The second WSDL is defined by the event source from the perspective of the event sink.
... The subscriber can only choose what the event source can support.

Gil: Is the explicit goal of your proposal to make WSDLs Basic Profile (BP) compliant?

Li: Yes, Appendix A describes how to acheive that goal.
... If the event source conforms to Appendix A it can be BP compliant.
... The source published the Notification WSDL.
... Policy relates the Event WSDL to the Notification WSDL.

<gpilz> state: correction: Is it an explicit goal of your proposal to support the migration of old-style, member submission WSDLs into WSDLs that are BP compliant?

Li: The event sink can use the policy to know about the linkage between the WSDLs.
... We have a policy wrapper, we have a policy assertion. The parameter serves as the link between the source and notification WSDLs.
... Would this work with policy intersection?

Correction: Dug: Would this work with policy intersection?

Asir: One the qname matching is done and there is no domain specific processing.
... The proposal has one policy assertion whose name is out:outbound. That is the only qname used for policy intersection. The parameters are not used in the intersection.

Dug: The out:outbound qname is a single element and is static. Does this mean everything will match?

<gpilz> the pseudo-schema in A.1 is incorrect - no big deal as we've figured out what was intended, but it shold be fixed to prevent later re-confusion

Asir: out:out-bound is the advertised behavior. When the behavior is engaged, there is a bag of additional information you can use that in in the policy parameters contained inside the policy assertion.

Gil: Li needs to write a psuedo schema to clarify this.

<asir> Li - you may want to look at other psuedo schema examples in the eventing doc

Li: For the event source, it has to generate an event as described in the Notification WSDL.
... For the subscriber, it has to subscribe to a specific Notification WSDL via the use of policy.
... The event sink has to implement the subscribe operation indicated by the policy parameter.

Gil: What are the attachment points? WSDL portype, binding, port element of a WSDL service.
... We are looking at A.1.2.

Li: Binding is not an attachment point, we do not see a case for it yet,.

Dug: Why is the interace and binding element names different?

Li: If the WSDL has mixed inbound and outbound operations in a porttype, this process separates them into two port types. The policy links the two port types.
... A binding links to a port in WSDL and we use the same approach.

Dug: If you follow the binding link in the WSDL file, would you not end up in the same port type?

Li: You are quite right!
... Let me explain why we added this port type.
... If another standards body defines new event types, the policy can be used to link them. The implementation can use the policy link.
... We do not define binding, but only the port types.
... This proposal simply refactors the offending WSDL into Event WSDL and Notification WSDL without any binding information in them,

<Wu> In this approach, policy assertions with Endpoint Subject with the ability to describe the outbound operations in abstract WSDL to facilitate late binding.

Dug: The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy.
... The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy.

The association between the port types in the event WSDL and notification WSDL is not via the binding. The linkage is done via policy.

Wu: Let us press on with the description.

Gil: How do you check linkage consistency?

Li: We use the tools to traverse the linkages.

Asir: Any consistency check needs to be done by the policy implementor.

Tom: This is incredibly inventive. Anything that is processing this will need to handle this in a specialized way.
... This seems like we are using policy in place of WSDL documentation.

<asir> SAWSDL

provides a way to describe as well.

Wu: Policy is expressive and does what we want (linkage).
... Policy is supported by tools. We followed Gil's proposal and extended it.

Dug: Is policy being actually used here or is it just for syntax?
... It seems that you are not establishing the link via policy but the linkage is done outside.

<Wu> The basic idea is to reverse the outbound operations in an event source WSDL to inbound operations in a separate WSDL called notification WSDL, and use WS-Policy assertions to link these operations.

Dug: The policy is really a carrier and contains domain specific information.

<Zakim> asir, you wanted to answer Doug's q

Asir: Look at section A1. That explains the behavior.

Dug: What does the subscriber need to do?

Li: The subscriber needs to subscribe to the port based on the policy information.

Geoff: Dug mentioned the need to searching on notifications. It seems that requirements and design have gone beyond the original Appendix A replacement. It is good to have the set of requirements well defined.

Bob: The WG should not extend the issue beyond the original requirements/intent.

Li: Moving on to A.1.4. WSDL examples. I suggest looking at second example source. The notification WSDL is short.

Li is reviewing / describing the WSDL examples.

Dug: I think I understand how when you are in an environment when the event source only sends notifications in one particular format, how the WSDL files can be traversed to reach the Notification WSDL.
... If the event source supports two wrapped notifications (wrapped1 and wrapped2), how do I know which WSDL to pick up?

Li: You start with the binding as you suggested. I will create two ports each corresponding to wrapped1 and wrapped2.

Dug: How do I know the association? What inside the WSDL tells me?
... I have to know what I am looking for to know what I am looking for. If I already know what am I seaching for?

Li: You traverse the policy and then indirect.

Gil: What if the outbinding has a qname that uniquely defined a notification format?

<gpilz> state: correction: What if the out:Binding element had an additional attribute that had the value of the Format QName?

Li: In WS-Eventing, we have two formats: Wrapped and Unwrapped.
... We need to provide a link between the URI and WSDL; it is currently missing.

Dug: Subscriptions allow number of search types such as bookmarks, etc. How do I know which WSDL to grab. If it is just an URI I may have many WSDLs.
... We need a linkage mechanism so the subscriber can find the right WSDL that matches.
... The WSDL was there to advertise which events are sent. It is not just about BP compliant.

<Tom_Rutt> the notification wsdl is constrained to have one binding per port. what did you mean when you talked about "surrogate" port which supports multiple bindings? Are you trying to get at a notification endpoint address which supports multiple notification service ports?

Gil: Issue 6661 deals with this. It is separate. But it is hard to separate doing the proposal for without touching it.
... Can the surrogate port support the raw format as well?

Li: Each port can support only one binding.

Correction: Li: Each binding can support only one port.

Asir: 6402 describes policy for event notifications.

<Bob> time warning

Dug: These issue are different.

Geoff: In the proposal we had an appendix I. It is not broken. Just that it is not BP compliant. The core issue on the table was to turn what was in Appendix I BP complient. But I am seeing new things like format, etc. While these are important, it is not clear why we are mixing all these things together.

Gil: Issue 6661 describes the problem. I claim that both my and Avaya's proposal addresses 6661 as it turns out.
... Issue 6401 is different in scope.

Recess until 12:45PM PT. The meeting will reconvene at 12:45PM PT.

<asir> [Resuming]

<asir> ScribeNick asir

<asir> Scribe: Asir S Vedamuthu

<asir> ScribeNick: asir

Continuing 6401

Back to traditional engineering

Define problem, determine requirements, propose solutions, prove reqs covered and consider cost

<Wu> issue 6401: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401

Bob: appropriate to merge 6401 and 6661?

Wu: scope of 6661 is not clear

<Wu> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6661

Wu: someone should clearly articulate what needs to be addressed for 6661

Bob: suggests that we merge 6401 and 6661, then march down the list (define problem, determine reqs, ...

Wu: wants to ensure group consensus on what is the scope for 6661

Bob: lets identify reqs
... some of the reqs now
... are there any objections to merge?

Wu: want to know what is 6661 all about, then merge

Gil: the drill that Geoff and I plan to go through will describe the scope of the problem

Bob: should we defer the engineering exercise to taskforce 6401
... should we use the F2F
... okay with using the F2F, but like to reserve some time for the formal objection

[Gil jumped to the board]

Bob: any objections to consolidating these issues?

Wu: we need to decide on the boundary first

only two hours designated for this

<dug> http://assets.comics.com/dyn/str_strip/000000000/00000000/0000000/200000/80000/6000/200/286254/286254.full.gif

[Talking about a possible Aug F2F]

Bob: how about the first week of Aug

Geoff: week of Aug 4th is fine with us

Bob: we inadvertently scheduled Sep F2F because it conflicts with a religious holiday
... Paul - can we do Sep 30- Oct 2nd?

<scribe> ACTION: Paul Nolan to check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd [recorded in http://www.w3.org/2009/06/11-ws-ra-minutes.html#action01]

<trackbot> Sorry, amibiguous username (more than one match) - Paul

<trackbot> Try using a different identifier, such as family name or username (eg. pnolan, pfremant2)

<scribe> ACTION: pnolan to check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd [recorded in http://www.w3.org/2009/06/11-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-71 - Check if IBM could accomodate Hursley F2F from Sep 30-Oct 2nd [on Paul Nolan - due 2009-06-18].

<scribe> ACTION: Geoff to check if MSFT could host a F2F meeting in the first week of August [recorded in http://www.w3.org/2009/06/11-ws-ra-minutes.html#action03]

<trackbot> Created ACTION-72 - Check if MSFT could host a F2F meeting in the first week of August [on Geoff Bullen - due 2009-06-18].

tentative location is Redmond, Aug 4-6th

Hursley is also tentative from Sep 30-Oct 2

back to 6401

Trascribing the white board

I. Developer of Event Sink generates code to dispatch and marshal Notifications using current WSDL tools a) raw notifications b) wrapped notifications

II. Subscriber searches for a set of potential Notifications for elements that match a specific criteria

III. Subscriber retrieves schema (s) for potential notification set for purposes for authoring appropriate filter expression (s).

IV. Service designer describes abstract interface such that all implementations thereof will be Event Sources

Amending I. c) Extension that impact on-the-wire mesages

Extensions - subscription, formats, filter

Gil: send bookmarks

Bob: we have extension points
... delivery, subscription, filter, format, endTo, notifyTo
... and any future extension points
... need to be feature-wise backward compatibility

Geoff: shouldn't boil the ocean, are we trying to find one solution that solves all problems

Gil: not so

Geoff: may not be able solve for every possible extension
... boil the ocean | set of things that definable and implementable

Gil: add a non-functional requirement
... I.c make these easy

Bob: may be we can't do wrapped notifications, general extension points

Geoff: there are 10 different dimensions of easiness

<Bob> My point was that general extensibility points that affect the appearance of messages of the wire is not a new, unique, or unsolved concept

Geoff: II sounds like brand new
... not part of Eventing
... how can a subscriber pick one and subscribe?

Wu: do we have to define II in the Eventing spec?

Gil: am interested in weather notifications?

Asir: what do you need for II in the protocol?

Gil: linkage between the event source and something that describes the set of notification types
... want to know what that set of info would look like

II. Subcriber can see a set of potential notifications that may be emitted by an event source

the above sentence replaces II

Li: who is the target for these use cases, people or machines

Bob: struck search from the whiteboard

Prasad: what about security? Subsriber may not have the authority to see all notifications

Add a non-functional use case - II 'screened' based on authz

Bob: more or less okay with I, okay with II

Annotate II with schema

effectively

II. Subcriber can see a set of potential notifications (including schemas) that may be emitted by an event source

II. Subcriber can see a set of potential Events (including schemas) that may be emitted by an event source

<dug> q

Ashok: why don't we say metadata instead of schemas

II. Subcriber can see metadata about a set of potential Events (including schemas) that may be emitted by an event source

<scribe> Dropped III

lots of confusion about IV

Li is summoned

Li: walk through a use case from ECMA/348/CSTA
... we want to be able say .. make that WSDL BP compliant
... want to separate those outbound operations to inbound operations
... this is useful for other standard bodies, abstract event services, let the impl take care of details

Doug: should we describe, providing a mechanism by which service designer can be handed an abstract interfaces that can be implemented as an Event Source

Asir: based on what I heard it appears that ...
... A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source

Doug: agrees

Li: sounds okay

III. A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source

IV. Realize I, II and III without metadata

Doug: source supports sends out multiple variations of notifications
... that is
... source can support mutliple variations of notifications

V.Event Source can transmit multiple variations of Notifications (Raw, Wrapped, *)

<Wu> source can support any combination of A&B in I

talking about stars on the sky

okay with V

VI Proide Subscriber with metadata that describes the variations of Notifications

Geoff: Non-fuctional Requirement - all use case must have a 'reasonable' solution for constrained environments

Bob: accepted

Wu: are we going to dispose this in one short or incremental
... divide and conquer

Bob: premature q

Wu: want to ask the question

Bob: An adquate spec ought to deal with these use cases

<Bob> state: Correction: An adquate spec ought to deal with these use cases

Doug: a mechanism by which a subscriber can determine the shape of the WSDL based on how it subscribed to an event source

Asir: don't understand the usecase, what mechanism?

<dug> A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source.

Bob wants to add a non-functional req

Bob: we need to finish the work, we started with a charter, to make it reasonable, need to limit invention
... non:functional req: limit inventions to application of well known technologies

Bob's non-functional req: limit inventions to application of well known technologies (such as WSDL, MEX)

Bob: we have a limited scope problem, solutions should play within

<dug> 7: A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source.

Bob: want to get to a draft that is more right than wrong

here is the summary ....

I. Developer of Event Sink generates code to dispatch and marshal Notifications using current WSDL tools a) raw notifications b) wrapped notifications c) Extension that impact on-the-wire mesages (example, new formats)

Non-functional requirement - make it easy

II. Subcriber can see metadata about a set of potential Events (including schemas) that may be emitted by an event source

Non-functional requirement - II 'screened' based on authZ

III. A service designer can take metadata about a set of potential Event Types that may be emitted by an Event Source and implement the Event Source

IV. Realize ALL USECASCES without metadata

V.Event Source can transmit multiple variations of Notifications (Raw, Wrapped, *)

VI. Proide Subscriber with metadata that describes the variations of Notifications (eg supported formats)

VII. A mechanism by which a subscriber can determine the WSDL based on how it subscribed to an event source

Non-fuctional Requirement - all use case must have a 'reasonable' solution for constrained environments

Non-functional requirement - limit inventions to application of well known technologies (such as WSDL, Poliy, MEX).

Bob: gil to pick up the summary and turn this into a doc
... in the next meeting, we should review the draft reqs and deal with amendments

<li> i have another requirement to add the next time

Bob's picture is non-normative

Sep F2F

Scheduled for Wed Sep 30-Oct 2

Hursley confirmed

<scribe> ACTION: Bob to send out a notice about the Sep F2F and other F2F meetings [recorded in http://www.w3.org/2009/06/11-ws-ra-minutes.html#action04]

<trackbot> Created ACTION-73 - Send out a notice about the Sep F2F and other F2F meetings [on Bob Natale - due 2009-06-18].

<scribe> ACTION: Gil to transcribe the draft reqs from the minutes into a doc for review [recorded in http://www.w3.org/2009/06/11-ws-ra-minutes.html#action05]

<trackbot> Sorry, couldn't find user - Gil

<Bob> my camera may be non-normative, but it is very literal

<Bob> ACTION: Gilbert to transcribe the draft reqs from the minutes into a doc for review [recorded in http://www.w3.org/2009/06/11-ws-ra-minutes.html#action06]

<trackbot> Created ACTION-74 - Transcribe the draft reqs from the minutes into a doc for review [on Gilbert Pilz - due 2009-06-18].

<li> bye folks be nice

Resolution: Agreed to merge 6401 and 6661

6924

Gil introduces his proposal

Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0035.html

Geoff: perhaps, change update denied to put denied (fault)

Bob: any objections

None

s/UpdateDenied/PutDenied/

Tom: is all or nothing on put?

Gil: all or nothing

<Bob> A successful Put operation updates the current representation associated

<Bob> with the targeted resource. An unsuccessful Put operation does not affect the resource.

Doug: am okay with the issue/proposal
... it is important that a client knows what the server would do
... include a flag that indicates what the server would do when it encounters read-only data

Bob: where should we put that

Doug: wiki :-)

Bob: move to wiki

Two amendments

a) s/updatedenied/putdenied/

b) A successful Put operation updates the current representation associated with the targeted resource. An unsuccessful Put operation does not affect the resource.

<PrasadY> Could what the server would do with read-only data vary based on the specific resource, and may not be a generic one applicable across the board to all resources

Resolution: accept http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0035.html + the above two amendments to resolve issue 6924

<scribe> ACTION: Doug to add the 6924 related metadata possibility to the wiki [recorded in http://www.w3.org/2009/06/11-ws-ra-minutes.html#action07]

<trackbot> Created ACTION-75 - Add the 6924 related metadata possibility to the wiki [on Doug Davis - due 2009-06-18].

<dug> metadata == things to advertize

6956

Geoff walks through the updated proposal

Proposal

http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0033.html

Resolution: proposal accepted to resolve issue 6956

Thank you Ram!

<Ram> Thank you Asir.

<Ram> Bob: Discuss formal objection.

<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0014.html

<Ram> Geoff: Microsoft submitted a formal objection to issue 6398.

<Ram> It is not about the process it is about a technical objection.

<Ram> Geoff describes the technical objection.

<Ram> Geoff: There are other possibilities to address the technical objection. We should open up that issue and arrive at a mutually satisfactory solution for the problem at hand.

<Ram> Ashok: You said that this is NOT a process objection.

<Ram> Ashok: We had an issue and we closed it. So, are you reopening the issue?

<Ram> Bob: The process allows for re-opening issues if new information is provided.

<Ram> Bob: Anyone wants to discuss the technical objections raised by Geoff?

<Ram> No comments from the WG.

<Ram> Bob: Do Web service messages use well-known wrappers and actions?

<Ram> Dug: Yes, many do, including the WS-RA specifications.

<Ram> Bob: Why is this issue different? Anyone?

<Ram> Yves: The current specification has Get wrapper and GetResponse wrapper. The specification is silent on what happens when the Get message is not wrappered but the GetResponse is wrappered.

<Ram> Yves: If the wsa:Action is used to distinguish the message, then this problem should go away.

<Ram> Geoff: WS-Transfer supported wsa:Action as the only way to dispatch. The issue (6398) resolution has changed that dispatch mechanism.

<Ram> Yves: When you have two ways of expressing the same thing, there is room for contradiction. That is the real problem.

<Ram> Yves: I propose using an anonymous wrapper or a single wrapper for all WS-Transfer operations.

<Ram> Dug: The right solution is to throw a fault if the wsa:Action and the wrapper does not match. I suggest opening a separate action.

<Ram> Dug: The information that is claimed to be new is not actually new.

<Ram> Bob: That information was in a snippet of email but not raised or discussed on the floor. Maybe the sentence flew by but never teased out or discussed.

<Ram> Bob: Is the point of it about a mismatch. That is, between the wsa:Action and the wrapper? Is that the problem?

<Ram> Geoff: We have another problem. The WS-Transfer specification originally had wsa:Action as the only mechanism. That has been changed by the issue. This is the fundamental split. We need to continue to support wsa:Action as a mechanism to dispatch messages.

<Ram> Bob: There are two points. One is in terms of dispatch (use of wsa:Action). Two is what happens if the wsa:Action and wrapper do not match.

<Ram> Bob: Let us talk about dispatch mechanism.

<Ram> Bob: WS-Addressing specifies wsa:Action as a mechanism to dispatch.

<Ram> Asir: There have been other mechanisms in the past as well.

<Ram> Bob: I do beleive we have a technical issue here. It is about dispatch relating to use of wsa:Action.

<Ram> Geoff: Our objection is NOT about adding a wrapper.

<jeffm> q

<jeffm> _q

<jeffm> +q

<Ram> Bob: What I would like to do at this time is to leave the resolution as is at this time and open two new issues. One issue would be about the wrapper name and wsa:Action and what happens if the wrapper name and wsa:Action are different. The second issue is about should the wrapper be the source of dispatch.

<Ram> Gil: I would like to object to opening the issues.

<Ram> Bob: I suggest opening the new issues.

<Ram> Gil: Have we not formally accepted issues in the past?

<Ram> Bob: We can either re-open the issue and deal with these two new issues or simply open only the two new issues.

<Ram> Doug: Yves and Geoff can open separate issues and follow the normal process.

<Ram> Bob: I want these issues to be opened.

<Ram> Jeff: Where does that process say that the chair can open new issues at his/her own discretion?

<Bob> http://www.w3.org/2005/10/Process-20051014/

<Ram> Under 3.3.4 is the relevant section.

<Ram> Asir: The situation was due to the 6398 resolution and we did not have sufficient information.

<Ram> Bob: We just ran through a wrappering issue and we agreed to have the wrapper. Here we have a case where the charter says BP compliance. We had two proposals on the table one from Doug Davis and another from Geoff Bullen.

<Ram> Bob: The chair conducted the vote and the issue was resolved in favor of Doug's proposal.

<Ram> Dug: There is no new information. I just question the notion of new information being brough forth.

<Ram> Bob: Simply because something was on the mailing list does not constitute new information.

<Ram> Wu: We had thought that the issue was about BP compliance. But we never understood that the mismatch between wrapper and wsa:Action is a problem. I agree with Yves.

<Ram> Wu: I support opening the new issue to deal with the mismatch between the wrapper and wsa:Action.

<Ram> Jeff: Oracle objects to the way this is being handled.

<dug> IBM agrees with Oracle

<Ram> Dug: You said that email does not constitute new information.

<Ram> Bob: Yes, the information was not discussed.

<Ram> Dug: At that time, Geoff did not discuss that. How does that then become new information?

<Ram> Bob: Wu asked for more time at that time. Wu please clarify.

<Ram> Wu: We never discussed how the wrapper should be designed.

<Ram> Bob: I like to open an narrowly scoped issue that deals with the technical component of the prior issue relating to wrappering and discuss it.

<Ram> Tom: What happens if the message does not obey the WSDL?

<Ram> Tom: WS-I BP tools could do compliance. I suggest opening new issues just like any other new issues.

<Ram> Geoff is in the process of opening new issues.

<Ram> Yves: There are people who use Web services who do not use WSDL.

<Ram> Dug: The WSDL is normative and defines the contract.

<Ram> Dug: If the Subscribe message has wrong format, what happens?

<Bob> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7015

<Ram> Asir: Our objection is on the outcome of the issue resolution. We will defer to you whether you want to reopen or process the technical objections as new issues.

<Ram> Jeff: All bets are off, if you violate the specification.

<Ram> Tom: I have a confusion about what 'dispatch' means.

<Ram> Tom: I object to this issue.

<Ram> Gil: I need more time to process this issue.

<Ram> Gil: Can we discuss accepting the issue at the next meeting?

<Ram> Dug: I need more time too.

<Ram> Bob: I don't want to rush anyone.

<Tom_Rutt> ws addressing core states: "The [destination] and [action] properties indicate the target processing location and the verb or intent of the message respectively. The values of these properties can be used to facilitate the dispatch of messages." that is the only use of the word "dispatch" in the spec

<Ram> Dug: The issue says: "Replication of information reduces interoperability". I don't understand that.

<Tom_Rutt> this is a non normative statement, the concept of dispatch is implmentation dependant

<Ram> Dug: WS-Addressing replicates information.

<Ram> Dug: Interoperability problems occur due to ambiguities in the specification.

<Ram> Dug: I need more information.

<Ram> Wu: I want to make a constructive suggestion. I think the issue proposal is very clear. I suggest we open issue and discuss it.

<Ram> Gil: I would like to make sure that the issue is well described. My intent is not to reject this issue.

Not sure why RM comes into play all the time!

<dug> its a lovely spec

interesting

<Ram> Dug: The premise of the new issue is in question or incorrect. Therefore, we should not accept this issue. Therefore, we need to discuss whether we need to open this issue.

I think you wanted to use MC

<dug> I thought about it

<Ram> Bob: The new issue in an unopened/unaccepted state. Comments can be made to amend the issue.

<Ram> Bob: IBM confirms that the new dates for the September F2F. I will send a confirmation email to the WG.

- DRAFT -

Web Services Resource Access Working Group Teleconference

11 Jun 2009

Attendees

Contents

Sep F2F

6924

6956

Summary of Action Items

Scribe.perl diagnostic output