Web Services Resource Access Working Group Teleconference -- 14 Apr 2009

<trackbot> Date: 14 April 2009

<DaveS> dave S here

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

<Bob> scribenick: li

approval of agenda

<marklittle> do the dogs get a vote ;-) ?

<marklittle> rofl

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 & proposals

geoff: ok with ram's proposal

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

6730

6730 accepted with no objection

6594

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

geoff: 6594 and others are joined together

<Bob> ai: Geoff to prepare new proposals for 6594, 6672, and 6673

<Bob> ACTION: Geoff to prepare new proposals 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

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

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

katy: explain the reponses
... 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

<asir> Doug - your phone is noisy

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

<Katy> My phone keeps breaking up - I need to drop off an re-dial

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

<Katy> Sorry - my phone breaking up again

<Katy> will try to fix

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: volunteers to discuss frag issue in wiki

geoff and katy volunteered

bye

<Bob> Li, thanks for scribing

- DRAFT -

Web Services Resource Access Working Group Teleconference

14 Apr 2009

Attendees

Contents