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

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
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] On Behalf 
Of bugzilla@wiggum.w3.org
Sent: Wednesday, November 04, 2009 10:32 AM
To: 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
        ReportedBy: gilbert.pilz@oracle.com
         QAContact: 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.