W3C

Web Services Resource Access Working Group Teleconference

14 Apr 2009

Agenda

See also: IRC log

Attendees

Present
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.
Jeff Mischkinsky, Oracle Corp.
Katy Warr, IBM
Li Li, Avaya Communications
Mark Little, Red Hat
Sumeet Vij, Software AG
Tom Rutt, Fujitsu, Ltd.
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
Absent
Bob Natale, MITRE Corp.
Paul Fremantle, WSO2
Prasad Yendluri, Software AG
Ram Jeyaraman, Microsoft Corp.
Ranga Reddy Makireddy, CA
Sreedhara Narayanaswamy, CA
Vikas Varma, Software AG
Regrets
Vikas Varma, Software AG
Chair
Bob Freund, Hitachi, Ltd.
Scribe
Li Li

Contents


<trackbot> Date: 14 April 2009

<Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0084.html

<Bob> scribe: Li Li

<Bob> scribenick: li

approval of agenda

no objection to agenda

approval of minutes

no objection to minutes

bob: no new issues at this point
... please review fpwd of 5 specs in 1 week and publish comments to mailing list

discuss use of wiki for proposal refinement and primers

making progress

bob: this group is contentious and not moving toward concensus
... hope to work in more friendly fashion

issues with proposals

Issue-6730 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6730

geoff: ok with ram's proposal

RESOLUTION: proposal in comment #5 accepted with no objection to resolve Issue-6730

6594

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

geoff: 6594 and others are joined together, would like to propose some wording changes to existing proposal

<Bob> ACTION: Geoff to prepare new proposal for 6594, 6672, and 6673 [recorded in http://www.w3.org/2009/04/14-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-57 - Prepare new proposals for 6594, 6672, and 6673 [on Geoff Bullen - due 2009-04-21].

dug: 6594 are related to others

<Bob> last AI is due before next call

dug: 6594, 6672, and 6673 are somewhat different

daves: 6594 3rd comment links three proposal already
... dug already finish them

<Bob> email at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0088.html

geoff: looked the joint proposal and to provide more comments by next week

Issue-6413 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413

geoff: raised issues and katy responded them, need to look at her response
... request clarifications from katy

katy: explains her response
... merge part of rt into t (only fragment feature)

AI: bob to retitle the proposal to "move fragment from rt to t"

wu: like to see the concrete proposal

katy: the proposal is already available from the issue

<Yves> fragments in T seems to not be the ideal place. (like URI fragments are not in HTTP)

geoff: is this merge confusion? we need to discuss this decision: why only part of it instead of all?

daves: basic fragment vs. complex fragment, take basic fragment into T, which is clear

bob: difference between ws-rt fragment and ws-man fragment

daves: not sure, but think ws-rt fragment addresses ws-man requirement

and grid community as well

dug: too much to move all rt into t, take a phase based approach
... only frag id in difference places

<Yves> how about creating a ws-frag spec? (if you want to extract it from RT)

geoff: still not sure if the use cases can be solved separately by two specs, instead of using the merged one
... use cases can't be solved by rt alone?

katy: single spec (merged) will cover all cases, except a few, which can be addressed by extending merge t

<Geoff> that would be fine by us

yves: separating fragment is more reusable for ws-man and grid

katy: fragment is not in the core of t, but in a appendix

daves: fragment is separated in the appendix

geoff: don't think appendix is a good idea
... many usages of t don't need fragment, 80% don't need, 20% may need it

wu: yves's idea is good, making it its own standard is more valuable than appendix

dug: if fragment not in t, it may result ad-hoc solution

<asir> too much noise on the line

jeffM: our goal is not just to make ws-man work, but to make ws-* work
... we need to make decision on our goal
... packaging is not that important, but operations are

<Yves> fragment is relative to a resource, so it fits better alog the EPR definition, but editing ws-addr-core is close to impossible now, otherwise I agree that the content is what matters

geoff: basic functions in base class, more functions in subclass, not sure why changing this design decision

daves: merging frag into t is to eliminate ad-hoc solutions to frag with t
... don't want ws-man to redo frag with t

<Geoff> dave's thought is worth investigation...

<gpilz> +1 to daves

<Katy> +1 Dave

dug: frag in t is optional, what is the pain?

geoff: it's not completely optional, force people to reprofile ws-t in light of frag merge

dug: we can make sure it's completely optional, people has to change ws-t anyway

geoff: changing namespace does not justify greater changes

<asir> There are such examples in W3C

<asir> For instance SOAP Part 1 and Part 2

bob: daves' proposal is to make ws-t optional but normative

<asir> Part 1 carries an ad for Part 2

bob: any objection to daves' direction?

ashok: puting in appendix is better to avoid confusion

wu: 3 specs or 2 specs

bob: current proposal is 3

dug: changes to ws-t is necessary, like to see mroe detail

asir: frag in a separate doc means all about frag in one doc, not just appendix
... advertisement is ok but how to formulate the normative language

<asir> We are okay with the precedents set by SOAP, WSDL and WS-A

daves: ws-security may help us with the normative languages

wu: if we can ask other standards using ws-t to make this connection, instead of link frag to ws-t

daves: ws-man using ws-t may not aware frag if frag not in the appendix

<gpilz> how can we tell WSMAN what do do?

<DaveS> +1

<asir2> Gil - are you a member of WS-Man WG?

<gpilz> yes I am

wu: ws-man can specify requirement for ws-t and frag

<asir2> Gil .. you are a powerful voice!

wu: we should let users to decide which to use

<gpilz> asir: loud doesn't help

daves: worry ws-man may choose other way, creating problems

katy: separate specs looses the context of frag spec, we need to make contexts for both ws-t and frag clear

<Geoff> +1 to Bob

bob: ws-addressing is a model we can use

dug: having free choices is not good for ws-*
... we need to restrict composition choices

asir: ws-addressing and soap 1.2 are good models for multiple documents of one spec
... ws-ra can influence ws-man with good values
... we should respect other bodies choice

gil: ws-man may use ws-ra, but the schedule is up in the air
... ws-man is just one case that may invent its own frag

yves: thers is a link from frag to ws-t, not the opposite, we need to make requirement of frag clearer

bob: more time to decide direction?

<gpilz> +1 to doug

<gpilz> let's look at the changes to WS-T as stand-alone changes

dug: taking stepwise change to ws-t leading to merge

<Katy> +q

asir: refine requirements for frag

katy: puting appendix on hold, but do changes on the core ws-t, is asir ok with this?

asir: we have issues on those changes too

katy: is it ok to incorporate dialect support, for example?

geoff: why dialect attribute is required?

katy: it provides a simple extension point to add frag and others

dug: 6712 show dialect is more than ext point

asir: ambiguity can be resolved without 6712

dug: element under <create> is ambiguous

asir: one->data, more->data, any particle

<asir> and zero->null

bob: Any volunteers to prepare frag issue direction in wiki?

geoff and katy volunteered

<Bob> As folks were hanging up they were asked to review the IRC

bye

<Bob> Li, thanks for scribing

Summary of Action Items

[NEW] ACTION: Geoff to prepare new proposal for 6594, 6672, and 6673 [recorded in http://www.w3.org/2009/04/14-ws-ra-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/04/27 12:44:38 $