[WSRF 4] continued discussion

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

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/>
++++++++