See also: IRC log
<trackbot> Date: 19 January 2010
<dug> ah, never got the agenda email
<Bob> scribe: Vikas
<Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0090.html
<dug> wow, 30! :-)
<dug> such the optimist
<scribe> AGENDA: Agenda accepted without any objection in the working group.
RESOLUTION: The minutes
from Dec 15 2009 meeting has been approved without
objection
... The minutes from Jan 05 2010 meeting has been approved without
objection
<dug> do we have the logistic for the f2f? street address? times?
<asir> it appears that the W3C list archive is not (or slow in) pushing out mails to list subscribers
RESOLUTION: The minutes from Jan 12 2010 meeting has been approved without objection
<Bob> f2f logistics http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Dec/0010.html
<Ram> Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0065.html
<Ram> Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0065.html
RESOLUTION: Resolved as proposed above.
<dug> Latest proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0086.html
<Yves> what is the analogy of empty string there? do we ned at least an xml decl?
<gpilz> The term "generate" is used in relation to the various faults defined by this specification to imply that a fault is produced, no further processing SHOULD be performed, and the fault SHOULD be transmitted.
<Vikas1> Bob, can you make Vikas1 as scribe
<Ashok> scribenick: Vikas1
<Vikas2> Bob, can you please mark Vikas2 as scribe.
<Bob> scribenick: Vikas2
<dug> ... no further processing SHOULD be performed. In these cases the fault SHOULD be transmitted.
<Ram> Basic Profile says: "Both SOAP and this Profile use the term 'generate' to denote the creation of a SOAP Fault. It is important to realize that generation of a Fault is distinct from its transmission, which in some cases is not required. "
<dug> The term "generate" is used in relation to the various faults defined by this specification to imply that a fault is produced and no futher processing SHOULD be performed. In these cases the fault SHOULD be transmitted. However, there might be reasons when a compliant implementation might choose not to transmit the fault - for example, security concerns - in these situations the fault MAY NOT be...
<dug> ...transmitted.
<dug> Wu, better?
Gil: There will be very few cases where fault is not propagated, if its generate the fault should be send back to the consumer.
<dug> The term "generate" is used in relation to the various faults defined by this specification to imply that a fault is produced and no futher processing SHOULD be performed. In these cases the fault SHOULD be transmitted. However, there might be reasons when a compliant implementation can choose not to transmit the fault - for example, security concerns - in these situations the fault MAY NOT...
<dug> ...be transmitted.
RESOLUTION: Resolved 8283 with proposed text above.
<dug> proposal: The term "generate" is used in relation to the various faults defined by this specification to imply that a fault is produced and no futher processing SHOULD be performed. In these cases the fault SHOULD be transmitted. However, there might be when a compliant implementation might choose not to transmit the fault - for example, security concerns - in these situations the fault MAY NOT be
<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0084.html
RESOLUTION: 8286 resolved with above propsal, proposed in message nos. 84
<dug> proposal: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8301#c1
<Ram> Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0091.html
<dug> proposal: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8301#c1
<Ram> Proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0091.html
<dug> FaultOnPutDenied: When present, this OPTIONAL parameter indicates that attempts to change portions of the representation that are read-only will generate a wst:PutDenied fault. If this parameter is not present, attempts to modify read-only portions of the resource representation will be ignored without any fault being generated.
<Yves> I would note that adding something to receive an error is a bit awkward, adding something to explicitely _ignore_ the error would make more sense
RESOLUTION: 8301 resolved with comment#1
<dug> ok with fixing "it" :-)
<gpilz> scribe: gpilz
ram: need more time to consider this
proposal
... discuss at F2F
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7774
yves: last time I said this could
wait for the F2F
... during the previous F2F we discussed that is was not addressing
something
... if WS-T Delete == WS-Frag Delete why does WS-T Put != WS-Frag
Put
doug: Put is really an update of the
resource rep
... in the base case you get a whole new rep
... in WS-Frag, Put with mode is an instruction, not a complete
rep
... WS-Frag Put is what you want, it's just not called "Patch"
(Yves & Doug): back and forth about semantics of "replace", "instructions", etc.
<scribe> ACTION: doug - add clarifying text as a potential resolution to 7774 [recorded in http://www.w3.org/2010/01/19-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-136 - - add clarifying text as a potential resolution to 7774 [on Doug Davis - due 2010-01-26].
<asir> +1 to Gil!!!
tom: would like to clarify this issue
<asir> I agree with Bob's statement
<dug> I'd like to defer 8292
<dug> its a big proposal - haven't had time to fully review it yet - sorry
bob: would like to have all issues have proposals by F2F
<dug> 2119 on the spot sounds good
<dug> +1
<dug> I think 8185 isn't really related
<asir> Bob - that would be lovely!