Re: [wsrf] use case that I think needs to be addressed in the RP section ofthe spec

[Steve Graham <sggraham@us.ibm.com>]

Hi Ian:
This looks very similar to the situation
described for WSRF issue 4:

Issue WSRF4: GetResourceProperty on property document with xsd:any

When a property document schema contains an xsd:any element and a GetResourceProperty message is received for a property QName for which there is currently no instance, what should be the response?

One possibility is that a fault message is returned. This behavior results in some requests for a QName will fail at one time and succeed at some later time if the property has been subsequently been inserted.

Another possibility is that an empty message is returned. This behavior results in all QNames returning successful messages, some empty, others contain values. This behavior is also consistent with the Set/Insert behavior where all QNames are accepted.

GetMultipleResourceProperties has this same issue.

Specifications

·        WS-ResourceProperties, Version 1.1, March 5, 2004; sections 5.1 and 5.2, WSDL

Notes

sgg: The "any" case is a very interesting one. My gut tells me that the insert should succeed (as you suggest). My feel is that the Get and the GetMultiple should fault, as there is no QName defined either in the instance document or (not explicitly) in the RP document's type definition.

Doug: I'm leaning more towards the Get and GetMultiple should not fault however. When talking about the other case (the "foo" one), those shouldn't have faulted (to me) because the query was valid relative to the schema. In this case (the "any" one) it would be valid for the same reason - relative to the schema it is valid. If it were not the case then you would either get back data or a Fault depending on the value of the instance data and that just feels wrong. A Fault should be returned due to invalid input not due to the specific value of the instance data. That just leads to inconsistent processing rules.

sgg: although it is true that the "foo" is valid wrt to the any appearing in the schema, I believe this would be a surprising result. With the "any", certain mis-spellings like fou instead of foo would not result in a fault. This is too surprising.

Proposed Recommendations

Add statement to sections 5.1 and 5.2 indicating that a request to get a property that is not explicitly defined in the schema for a property document containing an xsd:any element will result in a InvalidResourcePropertyQName fault.

Another alternative is to return no child elements in the GetResourcePropertiesResponse element.

Resolution: http://www.oasis-open.org/archives/wsrf/200410/msg00053.html.

Status: Resolved since October 18, 2004

Contact: Steve Graham, Bryan Murray, Doug Davis

Cross Reference:

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

"Springer, Ian P." <ian.springer@hp.com>

12/09/2004 06:29 PM

To	<wsrf@lists.oasis-open.org>
cc
Subject	[wsrf] use case that I think needs to be addressed in the RP section of the spec

If a resource's props doc schema permits open content (i.e.: xsd:any),
and a GetRP or GetMultipleRPs request is received with a QName that
a) that does not correspond to a prop that the schema explicitly
defines, and
b) does not currently exist in the RP doc,
what form of response should be returned:

A) an empty GetResourcePropertyResponseElement

or

B) an InvalidResourcePropertyQName fault

?

I would think A) is more logical, since if the RP doc schema permits
open content, than any prop QName is valid according to the schema. It
just happens to be that there are currently no elements with the
specified QName in the RP doc.

I think the spec needs to address this case for both GetRP and
GetMultiRPs. I think open content use cases need to be better addressed
for SetRPs Insert/Delete/Update too.

On a separate note, I find the definition of the
InvalidResourcePropertyQName fault under SetRPs/Delete ("A resource
property QName does not identify a proper number of resource
properties.") to be unclear. What exactly does this mean? That the RP is
not defined with minOccurs=0 ? If so, why not just say that?

Regards,
Ian