Re: [Bug 8182] New: unclear if/when result of a fragment Put is XSD validated

My point is that the two violations you present are of a different 
nature/order. Let's look at your second violation first. It's not that 
hard for the client that sent the Put in the second case to "know" or 
"discover" that what it did was wrong. It can do this w/out knowing the 
current state of the resource; all it needs to know is the schema for 
urn:a. That Put operation will always be invalid no matter what. The 
same is not true of your first example. It could be that the resource 
does not contain any urn:foo children of urn:a, in which case the 
request would succeed. Maybe my head has been warped by too much child 
rearing, but it seems strange to conflate these two statements: "what 
you just did was wrong under every cirumstance" and "what you just did 
was wrong *in given the context*".

- gp

On 1/5/2010 5:56 PM, Doug Davis wrote:
>
> In general it seems like any fault of this type could just as easily 
> happen with WS-Transfer too.  For example, given a resource that looks 
> like:
> <urn:a>
>   <urn:foo/>
> </urn:a>
> Let's say that the fragment we're inserting, as another child of <a>, 
>  is<urn:foo/> and that would cause a cardinality violation because, 
> per the schema, <a> only allows one child.  If we remove ws-frag from 
> the picture then we're talking about a situation where the 
> Transfer.Put looks like:
> <t:Put>
>   <urn:a>
>     <urn:foo/>
>     <urn:foo/>
>   </urn:a>
> </t:Put>
>
> What would the fault be in this case? It could be something about 
> violating the xsd, or it could be a cardinality violation.  Unless we 
> want to define all possible faults/reasons for why the data could be 
> bad then it seems like something generic would be better - which 
> wst:InvalidRepresentation seems to do.
>
> Back to the original issue since it feels like this thread has 
> deviated a bit from the original purpose... first, if this new flag is 
> needed then this isn't a ws-frag issue but rather a ws-transfer issue 
> since it could easily apply to normal ws-transfer ops too.  Second, 
> I'm not sure I understand the usecase where the client would like to 
> explicitly violate the xsd of the resource and NOT want the service to 
> reject it.  If that's really what the client wants then it seems like 
> they should ask for an xs:any type of resource since the scope of the 
> xsd violation could be so severe that they replace the entire 
> structure and not just one small bit of it.  I agree that its really 
> up to the service to decide whether or not to do xsd validation - the 
> client should be prepared for a really anal service that checks it on 
> all updates - anything else feels like asking for trouble.
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Gilbert Pilz <gilbert.pilz@oracle.com>*
> Sent by: public-ws-resource-access-request@w3.org
>
> 01/05/2010 06:16 PM
>
> 	
> To
> 	Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
> cc
> 	"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> Subject
> 	Re: [Bug 8182] New: unclear if/when result of a fragment Put is XSD 
>  validated
>
>
>
> 	
>
>
>
>
>
> I think using wst:InvalidRepresentation is incorrect because there is 
> no way for the client to distinguish between the case where is simply 
> supplied a bad representation (e.g. the lack of a required element) 
> and the case where the representation it supplied was valid, but would 
> cause the resource itself to become invalid (e.g. violation of a 
> cardinality constraint).
>
> - gp
>
> On 1/5/2010 3:00 PM, Ram Jeyaraman wrote:
> Based on the resolution to 8183 today [1], I suggest we use the fault 
> wst:InvalidRepresentation to handle the case where the resource 
> manager detects that the supplied partial representation in the 
> WS-Fragment Put operation resulted in an invalid update. Perhaps, the 
> WS-Fragment specification can include a statement about this.
>  
> Thanks.
>  
> [1] Resolution of 8183
>  
> 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 generate a 
> wst:InvalidRepresentation fault.
>  
> *From:* Gilbert Pilz [_mailto:gilbert.pilz@oracle.com_] *
> Sent:* Tuesday, January 05, 2010 2:06 PM*
> To:* Ram Jeyaraman*
> Cc:* _public-ws-resource-access@w3.org_ 
> <mailto:public-ws-resource-access@w3.org>*
> Subject:* Re: [Bug 8182] New: unclear if/when result of a fragment Put 
> is XSD validated
>  
> It's not clear to me whether the statement in WS-Transfer to which you 
> refer is sufficient to cover all the cases that might arise. The 
> problem is that we are talking about fragments of representation. It 
> could be that the supplied /wst:Put/wsf:Fragment/wsf:Value is, in the 
> abstract, a perfectly valid value for the target fragment but, in the 
> context of the particular resource in question, putting that value in 
> would cause the resource to become invalid.
>
> I'm OK with the idea of leaving a check for such conditions in the 
> hands of the resource manager, but I think we may need to define a new 
> fault.
>
> - gp
>
> On 1/2/2010 8:55 AM, Ram Jeyaraman wrote:
> It seems the resource manager may decide to schema validate the 
> updates based on a number of internal and external triggers. For 
> example, it may do consistency checks based on isolation / validation 
> policies in place. It seems best to leave the choice to the resource 
> manager on whether to schema validate upates.
>  
> WS-Transfer says "implementations MAY use the fault code 
> wst:InvalidRepresentation if the presented representation is invalid 
> for the target resource". This allows the resource manager to throw a 
> fault if it detects an update is schema invalid.
>  
> -----Original Message-----
> From: _public-ws-resource-access-notifications-request@w3.org_ 
> <mailto:public-ws-resource-access-notifications-request@w3.org> 
> [_mailto:public-ws-resource-access-notifications-request@w3.org_] On 
> Behalf Of _bugzilla@wiggum.w3.org_ <mailto:bugzilla@wiggum.w3.org>
> Sent: Wednesday, November 04, 2009 10:32 AM
> To: _public-ws-resource-access-notifications@w3.org_ 
> <mailto:public-ws-resource-access-notifications@w3.org>
> Subject: [Bug 8182] New: unclear if/when result of a fragment Put is 
> XSD validated
>  
> _http://www.w3.org/Bugs/Public/show_bug.cgi?id=8182_
>  
>            Summary: unclear if/when result of a fragment Put is XSD
>                     validated
>            Product: WS-Resource Access
>            Version: PR
>           Platform: All
>         OS/Version: All
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: Fragment
>         AssignedTo: _public-ws-resource-access-notifications@w3.org_ 
> <mailto:public-ws-resource-access-notifications@w3.org>
>         ReportedBy: _gilbert.pilz@oracle.com_ 
> <mailto:gilbert.pilz@oracle.com>
>          QAContact: _public-ws-resource-access-notifications@w3.org_ 
> <mailto:public-ws-resource-access-notifications@w3.org>
>  
>  
> When performing a WS-Fragment Put it is possible for the resulting 
> document to be invalid against the schema that defines that document. 
> There are cases where you would like the resource manager to check 
> this and fault. There are other cases where you might not.
>  
> Strawman Proposal: Add a boolean attribute to /wsrt:Put/Fragment that 
> indicates whether schema validation of the resulting document should 
> be performed as part of the Put operation. Define a new fault for when 
> schema validation is requested and fails.
>  
>  
> -- 
> Configure bugmail: 
> _http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email_
> ------- You are receiving this mail because: ------- You are the QA 
> contact for the bug.
> You are the assignee for the bug.
>  
>  
>  
>  

Received on Friday, 8 January 2010 23:20:30 UTC