- From: Doug Davis <dug@us.ibm.com>
- Date: Fri, 8 Jan 2010 18:42:18 -0500
- To: public-ws-resource-access@w3.org
- Message-ID: <OF8EB9BD28.3E2EAB19-ON852576A5.00812258-852576A5.00823C16@us.ibm.com>
I didn't think this issue was about what kind of fault to generate - I
thought this issue was about whether or not schema checking should happen.
And to me schema checking should happen (or not) irrespective of whether
you're doing a Transfer Put or a Fragment Put since you can end up with
the same bogus end result with both operations. The notion of saying
that a client (or service) is ok with an invalid xml representation when
using Fragment Put but not when doing a Transfer Put is something I can't
get my head around.
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>
01/08/2010 06:19 PM
To
Doug Davis/Raleigh/IBM@IBMUS
cc
public-ws-resource-access@w3.org
Subject
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
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.
Received on Friday, 8 January 2010 23:43:12 UTC