Web Services Resource Access Working Group Teleconference

14 Jul 2009


See also: IRC log


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


<trackbot> Date: 14 July 2009

<Bob> scribe: Sreedhara Narayanaswamy

<Bob> scribenick: Sreed

<DaveS> Note to chair: Bob I will need to go mobile about half way through the call, but will stay on as long as I have connectivity.

Bob: Posted agend is it acceptable
... Any objects in accepting the Minutes of 7th July

Team 6401

Gil: Non functional reqs specific to 6401

<gpilz> D. Support Migration It should facilitate a migration path of eliminating the offending outbound operations in existing web service implementations.

Bob: Migration with no functional take-aways; improvements & changes are permissible

gpliz: speicifc to as how the notifications would look like, a particular of construction of WS Eventing
... Other implementations related to migration

Bob: Particular to older specs what is the point in the migration path

Li: Migration web services WSDL out bound operations 6401 is trying to develop solution for out bound operations WS Eventing will propose solution
... If these web services spec is this current will allow to migrate specific to out bound operations

Bob: Are you suggesting existing implementations migrated without code change

Li: Web services specification from other standard - in these WSDL the out bound operations. These WSDL specs to be BP compliant
... Migrate from un-compatible state to compatilble state

Dug: Previous F2F discussed in migration doc need to address this

Bob: Other specs will not be BP compliant?

Wu: it should be relatively to change the BP compliance as required

<dug> what's the point of this discussion? we're all agreed it not going into the spec so what are we arguing about?

<dug> each company will figure out how much of a migration process there is for each feature - vote (make proposals) appropriately

gpilz: Alternative proposal disucssing with the working groups. Reqs should be relatively easy to migrate
... Migration chosen in particular specs that been discussing using the WS Eventing

Bob: Migration path information in the document Geoff did this. Why is there further requirement on migration?

Wu: Solution we developed presented other web services vendor to compse with us - particular requirement

Bob: Providing the information (paragraph) related to this

Wu: Can provide this paragraph

<dug> on firm mud

<scribe> ACTION: Wu will work on information related to the migration (paragraph) [recorded in http://www.w3.org/2009/07/14-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-82 - Will work on information related to the migration (paragraph) [on wu chou - due 2009-07-21].

Geoff: We need Wu & Gpliz to do with the specifications related to this

Bob: New issue Issue-7088
... Need to have the information related to 7088 before the F2F
... We have working document then we can close 7088 - also issues can be opened to this
... Issue-6720
... http://www.w3.org/Bugs/Public/show_bug.cgi?id=6720
... We had a proposal for the 6720

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0027.html

Ashok: checking in bugzilla
... Problem was we didnt know exactly second paragraph any document XML Schema: Structures], [XML Schema: ]

Dug: support transfer

Ashok: will get the XML or policy

Dug: Meta section identifier attribute

Geoff: I don't get what is going on in this
... Get operation can return many things including multiple documents interms of Dug was saying it is really not correct
... Get request single representation of the spec any metadata can return policy, not the get metadata itself
... As what we are arguing in this

Ashok: Original question spec can get all of these things

Geoff: What is actually get is the meta data resource may return any of those - metadata resource many things meta data elements itselt

Dug: Meta you get back could be next meta data element
... different data comming back so what I wrote is correct

Asir: It is confusing

<dug> Asir you're going too far

Dug: Single meta data unit with particular identifier

<Zakim> asir, you wanted to point out that the term 'dialect' is overloaded in this conversation

Asir: Confusing conversation word dialect

Dug: Using the word dialect - modifying

Asir: particular statement is not correct
... Why more than one dialect

Dug: One queue name

Asir: I agree metadata queue name it can have children can have more metadata section

Dug: Meta data wrapper

Asir: confusing the terminology

Bob: Asir, could you suggest alternative text?

Ashok: Not completely I didn't now the intent as some clarification required

Asir: It has the variable as wants to return not sure about specific information to put forward

Ashok: One metadata section which can different dialects which we need to spellout this

Asir: I understand & can work out on this

Bob: Asir & Ashok will produce alternative text

<asir> we signed up for clarification text

<scribe> ACTION: Asir & Ashok needs to work on the text [recorded in http://www.w3.org/2009/07/14-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-83 - & Ashok needs to work on the text [on Asir Vedamuthu - due 2009-07-21].

<dug> I'd like 6680 added to the agenda then - sorry I misread the #'s

<dug> 6680 should be a no-brainer

<dug> ie. close w/no action


Bob: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6803

Geoff: Discussion to take place WS Fragment, some time needs to have discussions what we need to do
... Is any issue related to this

<Bob> scribenick: Ashok

Bob: Recommended closing 6803 w/o prejudice

RESOLUTION: Issue-6803 closed with no action and without prejudice w/o


Dug: Strictly editorial. Opened by Gil
... no longer applies. We shd close

Bob: Any objection to close 6680 woth no action

Geoff: I need a minute
... ok no objection to closing

Gil: No objection

RESOLUTION: Issue 6680 closed with no action.

Geoff: We would like option to open a related issue related to or subsequent to 6803

<dug> When the Delivery Format feature is engaged the formatting of the going events occurs after any filtering.

Bob: Yes. That's what I meant by 'close with no prejudice'


Dug: Explains issue

<dug> not Body, its the Event XML

Geoff: Implication is if we only filter over the content and if we have a header that influences the body we have a problem
... this is possible
... don't want to rule out something that may be impt for someone

Dug: We are filtering on event XML
... if they want to filter on envelope they need a different mechanism

<Bob> ack [Micro

Wu: This is good if it does not disrupt existing apps
... we shd double-check apps

<dug> bob - I can answer that

Gil: What is 'raw eveny XML'? Does it include action URIs

Dug: Does not include action URIs

<dug> Actually, ws-e says: Context Node: the SOAP Envelope containing the notification.

Li: Xpath filtering is missing the context
... what if the msg has multiple parts

Dug: There can only be 1 part
... we may need a separate issue about the the shape of an event
... filtering has to happen before the binding

Li: If we have 2 parts we don't know which part is bound to body

Bob: Do you need more time?
... 1 weeks?

<dug> +1 to gil

Gil: The issue that Li just raised is related to issue 6401
... problem is how events are described
... what do you do with a wrapped notification
... my proposal for 6401 and Dug's proposal for this issue meshes very well

Tom: I need a usecase why anyone would filetr on anything other than the first child

<Tom_Rutt> ws bp requirments (both for rpc/lit and doc/lit) allow only one child of soap:body. I see no reason to filter on anything other than first child of soap body

Bob: I don't hear a lot of disagreement but folks seems to want a bit more time. Let's revisit next week

<li> one man's trash is another's gold

Bob: Proposes we deal with 6980 and then 6692a

Dug: Could we get a concrete proposal for 6692a?

Geoff: You have talked abt 4 issues.

<dug> LOL Geoff - you're a dreamer

Geoff: I am working on d.

a, b, c could be dealt with as separate issues

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0015.html

Bob: That's a good idea!

<gpilz> bring me the blue pages!

Bob: We will await proposal


Dug: CNA?

No objections heard

RESOLUTION: 6421 closed with no action


Summary of Action Items

[NEW] ACTION: Asir & Ashok needs to work on the text [recorded in http://www.w3.org/2009/07/14-ws-ra-minutes.html#action02]
[NEW] ACTION: Wu will work on information related to the migration (paragraph) [recorded in http://www.w3.org/2009/07/14-ws-ra-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/07/22 11:25:49 $