Web Services Resource Access Working Group Teleconference -- 05 Jan 2010

<trackbot> Date: 05 January 2010

<Yves> trackbot, start telcon

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

<trackbot> Date: 05 January 2010

<Katy> april2nd

<Katy> whoops :o)

picts we need picts!

Dec 15: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0060.html

bob u on skype ?

<Bob> hi

<scribe> scribe: Dug

8176 - new issue

Dug discusses the issue and says there is new info: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0029.html

Gil: it would be a mistake to not talk about this fault
... there is something to clarify

Ram: ok with it being accepted as an issue
... to Dug's points - he mentions two options
... ok with either option
... transport level faults could be hard to deal with in the spec

Gil: this is why we specify a particular fault
... only 2 states: active or unknown

Bob: any objection to accepting the issue?
... no objection - its accepted
... discuss now?

Dug: I'd prefer to wait until we have a formal proposal

Gil: words on paper would be good

Ram: I like option 2's direction

Bob: close today?

Ram: let's discuss some more

Bob: what do other's think?

Dug: I like option 2 as well, but I'd like it to apply to ws-transfer too

6463

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

katy: just got proposal - need time to review

8283

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

Gil: we're coming to an agreement on generating vs transmitting fault

Dug: I think we need a firm list of textual changes - it might go beyond just the list of faults at the end

Ram: agree with the general direction

Bob: does the soap processing model provide any guidance?
... we have a proposal from ram

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

is that it ram?

<gpilz> to which I replied: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0077.html

<gpilz> then Ram replied: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0086.html

<gpilz> then I replied: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0018.html

<gpilz> to which Ram replied: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0019.html

Dug: 8176 might need to be addressed first. Also, does this apply to other specs too?

Gil: thought he opened up other issues for other specs - but can't find them

Transfer has a MAY generate

8283 has a dependency on 8176

8165

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

<MartinC> ?

<Ram> http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0000.html

Dug: discusses the issue

Ram: if we don't define the mechanism then how do we interop?

Dug: the creator the EPR will figure it out

Ram: we should probably say using ref-params is one way to do it

Dug: I'd be ok with some text that say ref-p's would be ok for this purpose, but didn't we remove text like this already?

Gil: we used to have text that talked about using ref-p's to do correlation to subscriptions

Tom: we should only add text if we're constraining WSA
... is it

<gpilz> this is still in WS-Eventing "Note, subscribers wishing to correlate SubscriptionEnd messages with the subscription to which they apply MAY wish to add a distinguishing reference parameter to the EndTo EPR. "

Dug: no

current text: "however, the full subscription manager EPR (Address and Reference Parameters)

must be unique for each subscription. "

Dug: perhaps modify the Note Gil pasted to talk about ref-p's

Bob: any reason we're embedding a user's guide?

Gil: all specs seem to want to do it

Ram: wants something similar to the Note about submgr epr

Dug: I can take a stab at some non-normative text if people want

<gpilz> In some cases, it is convenient for all EPRs issued by a single event source to address a single Web service and use a reference parameter to distinguish among the active subscriptions.

Bob: moves to remove the sentence Gil pasted above

Dave: 2nds

Ram: why is this text a problem?

Bob: it provides no new info for this spec or WSA

Ram: there's nothing wrong with providing some guidance
... EndTo has this text

Tom: ref-p's should not be used for identification

Dave: its this kind of non-normative advice that is not necessary today - perhaps 3 years ago,but not today

Katy: +1 to Dave

Ram: lots of way to do subscription correlation

Dug: the examples use ref-params and talk about - that should be enough

Tom: +1 to Dug - EPR minters have the choice

Li: if we remove the text the one EPR could identify two subscriptions - will this be conformant?

Dug: conformant yes, but a bug

note that this particular response uses the x:SubID element as a reference parameter to distinguish this subscription EPR from other subscription EPRs.

Ram: make the example text explicit

Dug: does the text I pasted address it?

Ram: that looks fine

no objection to remove the text Gil pasted

proposal:

remove: however, the full subscription manager EPR (Address and Reference Parameters) must be unique for each subscription. "

and

In some cases, it is convenient for all EPRs issued by a single event source to address a single Web service and use a reference parameter to distinguish among the active subscriptions.

from the SubscibeResponse section

1st bit of text is from top of 2.4

2nd text is from subscribeResponse

Dug: moves to remove both

Bob: any objection?

Resolution: remove ref-p text as discussed above

<asir> :-)

8183

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

<Ram> Ram's proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0025.html

Ram: discussed his proposal

Dug: don't need the last sentence on the Put any more right?

existing para:

Implementations MAY use the fault code wst:InvalidRepresentation if the

presented representation is invalid for the target resource. The replacement

representation could be considered to be invalid if it does not conform to the

schema(s) for the target resource or otherwise violates some cardinality or

type constraint. If an implementation detects that the presented representation

is invalid it MUST generate a wst:InvalidRepresentation fault.

<scribe> new para:

Implementations MUST use the fault code wst:InvalidRepresentation if they detect that the presented representation is invalid for the target resource. The replacement representation could be considered to be invalid if it does not conform to the schema(s) for the target resource or otherwise violates some cardinality or type constraint.

<DaveS> If an implementation that performs schema validation on a presented representation detects that the presented representation is invalid for the target resource it MUST use the fault code wst:InvalidRepresentation.

That's for Put

And Create

Proposal: modify 1st sentence of Put text with Dave's text. Remove last sentence of Put para. Remove the WSA text from delete.

Plus: modify Create text with Dave's text - see Ram's note.

<Ram> If an implementation that performs schema validation on a presented representation detects that the presented representation is invalid for the target resource, then the implementation MUST use the fault code wst:InvalidRepresentation.

Proposal: modify 1st sentence of Put text, and Create text, with Ram's text above. Remove last sentence of Put para. Remove the WSA text from delete.

Bob: any objection?

Resolution: resolved with above proposal

8275

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

<Bob> ack dug'

Dug: might be too big of a requirement - full XPath is expensive and it means everyone must support filtering
... IBM would like more time

<li> +1

Bob: any issue ?
... anything else to discuss?

Dave: has everyone sent me their name/country for the f2f?

Bob: will set up a WBS

Need: name, company and nationality

Fred: where is the logistics email?

Bob: will update the web page in the morning
... any other business?

Meeting adjourned

- DRAFT -

Web Services Resource Access Working Group Teleconference

05 Jan 2010

Attendees

Contents