Web Services Resource Access Working Group Teleconference

02 Jun 2009


See also: IRC log


Ashok Malhotra, Oracle Corp.
Asir Vedamuthu, Microsoft Corp.
Bob Freund, Hitachi, Ltd.
David Snelling, Fujitsu, Ltd.
Doug Davis, IBM
Geoff Bullen, Microsoft Corp.
Gilbert Pilz, Oracle Corp.
Jeff Mischkinsky, Oracle Corp.
Li Li, Avaya Communications
Paul Nolan, IBM
Ram Jeyaraman, Microsoft Corp.
Tom Rutt, Fujitsu, Ltd.
Vikas Varma, Software AG
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
Bob Natale, MITRE Corp.
Fred Maciel, Hitachi, Ltd.
Katy Warr, IBM
Mark Little, Red Hat
Paul Fremantle, WSO2
Prasad Yendluri, Software AG
Ranga Reddy Makireddy, CA
Sreedhara Narayanaswamy, CA
Fred Maciel, Hitachi, Ltd.
Bob Freund, Hitachi, Ltd.
Ram Jeyaraman


<trackbot> Date: 02 June 2009

<Bob> scribe: Ram Jeyaraman

<Bob> scribenick: Ram

Agenda approved with the addition of a discussion of 6429 and 6401 at the end.

The minutes from last meeting has been updated to reflect late attendees.

<Bob> http://www.w3.org/2002/ws/ra/9/05/2009-05-26.html

RESOLUTION: No objections. The minutes from May 26th, 2009 has been approved.


F2F is next week. Jeff Mischinsky has provide the logistics to WG email list.

We will work on key issues and close others as well.

Gil: Will look into head count information and do the necessary.

No further discussion on F2F logistics.

Bob will post the link to the logistics email to the Administration site for the WG.

Task team progress:

Team 6401:

Gil has provided an updated proposal.

<dug> +1 to a new closing issue :-)

Gil: We can discuss this at the end of this call.

Wu: I have posted an email responding to Gil's proposal. I am not sure if we can discuss this issue this week.

Bob: I would like to see progress on 6401 since there are a number of issues behind it.
... Please make progress on 6401.

Dependent issues: 6430, 6661

<asir> Probably 6401, 6430 and 6661 are all the same!

Gil: There is a lack of clarity on some use cases in Wu's comment.
... BP says don't do solicit-response MEP.

Next discussion item: Preparation for issues on delivery mode cluster.

Geoff: We will be ready by end of this week.

Bob: How about T/RT merger?

Geoff: Geoff and Doug are working on an assessment/analysis due before end of this week.

New Issues

Issue-6955 (from Geoff Bullen)

<dug> just s/create/manage/ right ?

Geoff: The proposal is to change the description for SubscriptionManager.

The change is just about s/change/create in the description.

RESOLUTION: New issue-6955 is accepted w/o>

RESOLUTION: Issue-6955 resolved as proposed w/o

<asir> Clean bowled!

<Wu> wow, record speed

Issue-6956 (from Geoff)

<dug> bob - I'd like more time on this one

Geoff: Ambiguity on what is expected when enumeration context expires and can one tell if the context has expired.
... The state may not be store in the server.
... It is not clear when the enumeration context will expire.
... Section 3.2 needs clarification.

RESOLUTION: New Issue-6956 accepted. No objections.

Bob: We will discuss this further on the mailing list.

Issue-6975 (from Gil Pilz)

RESOLUTION: Issue-6975 accepted. No objections.
... Issues-6980 and 6986 are accepted. No objections.

6986 has a proposal.

Doug Davis: WS-Eventing does not define a Topic based filter. Change the specification to use XPATH based filter.

Refer to Example 4.1 line 43 WS-Eventing.

<li> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table4

Also refer to example 5.1.

<li> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table13

RESOLUTION: Issue-6986 is resolved as proposed without objection

<Wu> Wow, another good progress on 6986

Discussion on issue 6429.

Wu: This WSDL is defined by Event Source and used by Event Sink.

Dug: The challenge is how to get the separate WSDL (if it is made separate).

Wu: It is OK to close with issue,

Li: This is dependent of 6401.

<asir> we are dialing back in

<dug> LOL its all Geoff's fault - minute that!

Geoff is button challenged!

Apologies accepted :)

Bob: We need a new issue here.

<li> +1 gil

<dug> well, it is in the spec as of now

Bob: This is right now in the WSDL doc.

<DaveS> Snelling back

<dug> zakim who is making noise?

<scribe> ACTION: Gil to file a new issue (relating to 6429) to move the wrapped events and put in a separate WSDL. [recorded in http://www.w3.org/2009/06/02-ws-ra-minutes.html#action01]

<li> thanks gil


Dug: I have provided a proposal today.

Gil: kind of generating a fault is misleading.
... Generating provides no guarantee what the endpoint does with the generated fault. It is essentially unverifiable.
... No need to transmit the generated fault.

Li: If the server generates a fault but does not transmit a fault what does the client see?

Bob: The service may not transmit a fault if it does not trust the client.

<gpilz> or if there is no mechanism for transmitting the fault

<gpilz> e.g. one-way operation with the HTTP back-channel closed

<dug> +1 any kind of fault isn't ok with security folks - even letting them know that something went wrong is too much info

Dave: What we are trying to say is if a fault is transmitted then a specific fault MUST be transmitted.

Gil: MUST generate a specific fault is sufficient. This is independent of the decision to transmit.

<DaveS> I support unifying the specs.

<DaveS> I might raise a separate issue tom clean up the ambiguity around "generate" vresus "transmit"

Geoff: There are a couple of other specific cases as well.

In WS-Enumeration section 3.2

what do we do with this? Does this need any clarification?

There is also ambiguity relating to 6956 in the WS-Enumeration specification.

Geoff: I take back my comment. I am fine.

RESOLUTION: Issue-6916 is RESOLVED with latest proposal. No objections.

Issue 6712 discussion.

Dave: The implementation and presentation layer need some close coupling to process this.

Geoff: I gave two examples. It seems to me that a wrapper does the same thing and has the same problems.
... The choice between what is a literal value and what is an instruction is complicated.

<Geoff> that is correct

Bob: HTTP PUT operation does not have any expectation on the content/payload. Why do we need to define the content?

Dug: To me why this is different is because WS-Transfer talks about two things: One is XML representation and the other is the instruction.
... If the WS-Transfer were to remove this distinction, then we don't need this.

<asir> modeled after HTTP

Dug: WS-Transfer does NOT say that it is modeled after HTTP.

Bob: It may be in the charter though.

<DaveS> Interesting note: The iPhone text correction function corrects 'WSRA" to "WARS" :-)

<asir> ws-transfer does not talk about Doug's use case

Dug: There is nothing in the WS-Transfer spec that GET must return a wrapper response.

Gil: How can I do anything useful if cannot interpret the XML?\
... How do I interpret the blob?

<dug> Ram - he's saying the opposite - he's saying there _are_ cases where you don't want to interpret it

Gil: We should stay away from defining what the instruction is without any interpretation. We want the service to do the interpreration.

Geoff: It is a very specific use case. A DB client and DB service. The DB service takes a BLOB and stuffs it in the DB.
... There is a tight coupling between the DB client and DB service.
... By creating a dialect we are forcing a service to interpret it.
... How do I know if my BLOB is going to be interpreted or not?
... How does the client know what the service expects?

<asir> just like HTTP!

Geoff: The service is the one that defines the XML representation / instruction.

<asir> Server is in control!

Dug: I am asking for a mechanism for the service to distinguish what the client is sending in.

Dave: We can find a compromise.

<dug> dave - my default was NO ATTRIBUTE

<asir> this is nothing to do with existing impl

Dave: Define a default that is closer to current mechanism.

Bob: Let us pause on this issue and move on to 6401.


Gil: Once i have a dialect, i can know what nofication types are supported.
... By adverstising notification types, it is easy to filter based on notification types.

Geoff: Your proposal has a strong reliance on MEX. Maybe you could placate my concern.
... Do I need to have a running service to issue a MEX call against?

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

<li> composition vs. geneative approach

<li> wu: composition would support generative

Summary of Action Items

[NEW] ACTION: Gil to file a new issue (relating to 6429) to move the wrapped events and put in a separate WSDL. [recorded in http://www.w3.org/2009/06/02-ws-ra-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/06/21 13:18:55 $