See also: IRC log
<trackbot> Date: 05 January 2010
<scribe> scribe: Dug
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
... 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
... only 2 states: active or unknown
Bob: any objection to accepting the
... 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
katy: just got proposal - need time to review
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
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
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
... 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. "
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
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
remove: however, the full subscription manager EPR (Address and Reference Parameters) must be unique for each subscription. "
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
<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?
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
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
<Bob> ack dug'
Dug: might be too big of a
requirement - full XPath is expensive and it means everyone must
... IBM would like more time
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
... any other business?