[WSRF 4] continued discussion

Following up on my AI (that is grossly
overdue).  I need to propose some text to resolve Issue wsrf 4.

Here is the text of the issue:

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.

This essentially discusses what to "standardize"
in the situation where the RP Document schema has element extensibility
(xsd:any). 

The WSRF-RP spec currently reads: (section
5.1, defining GetResourceProperty message exchange):

The components of the GetResourceProperty
request message are further described as follows:

/wsrp:GetResourceProperty/QName

This MUST correspond to the QName of a resource
property element defined as a child of the root of the WS-Resource’s resource
properties document.

So lets consider the case where the RP
Doc schema looks like (slightly simplified from the example in the WSRF-RP
spec):

    <!-- Resource properties
document declaration -->

    <xsd:element name="GenericDiskDriveProperties">

      <xsd:complexType>

         <xsd:sequence>

         
 <xsd:element ref="tns:NumberOfBlocks"/>

         
 <xsd:element ref="tns:BlockSize" />

         
 <xsd:element ref="tns:Manufacturer" />

         
 <xsd:any minOccurs="0" maxOccurs="unbounded"
/>

        </xsd:sequence>

      </xsd:complexType>

    </xsd:element>

And consider two instance documents.
 

WS-Resource 1 (no extensibility):

<GenericDiskDriveProperties ...>

   <tns:NumberOfBlocks>22</tns:NumberOfBlocks>

   <tns:BlockSize>1024</tns:BlockSize>

   <tns:Manufacturer>DrivesRUs</tns:Manufacturer>

</GenericDiskDriveProperties>

WS-Resource 2 (uses extensibility):

   <GenericDiskDriveProperties
...>

   <tns:NumberOfBlocks>22</tns:NumberOfBlocks>

   <tns:BlockSize>1024</tns:BlockSize>

   <tns:Manufacturer>DrivesRUs</tns:Manufacturer>

   <foo:bar>mumble-mumble</foo:bar>

</GenericDiskDriveProperties>

If a requestor sent <GetResourceProperty>foo:bar</GetResourceProperty>
to WS-Resource 1, the response would be an InvalidResourcePropertyQName
fault.  Why? Look back at the constraint on the QName component of
the message:  This MUST correspond
to the QName of a resource property element defined as a child of the root
of the WS-Resource’s resource properties document.
 In this case, foo:bar does not correspond to a QName of an rp element
child of the root GenericDiskDriveProperties.

Now, the same message <GetResourceProperty>foo:bar</GetResourceProperty>
to WS-Resource 2, results in a valid response: <GetResourcePropertiesResponse><foo:bar>mumble-mumble</foo:bar></GetResourcePropertiesResponse>
because the QName foo:bar corresponds to an rp element defined as child
of the root in this case.

So, how to tighten the text in the spec?
 One might claim there is nothing to do.  Others might quibble
on the definition of "define".  So perhaps something more
clear might be:

/wsrp:GetResourceProperty/QName

This MUST correspond to the QName of a resource
property element child of the root of the WS-Resource’s resource properties
document.

 Removing the word "defined"
eliminates the possible interpretation that the QName must be defined in
the schema of the RP document.

Similarly, removing the word "defined"
in the corresponding component in the definition of GetMultipleResourceProperties
should also be sufficient.

We should consider adding a section in
the app notes to clarify the xsd:any case, but I don't see the need for
additional non-normative explanation in the spec.

sgg

++++++++

Steve Graham

(919)254-0615 (T/L 444)

STSM, On Demand Architecture

Member, IBM Academy of Technology

<Soli Deo Gloria/>

++++++++