Re: [wsrf] [WSRF 4] continued discussion

[Tom Maguire <tmaguire@us.ibm.com>]

+1 to the clarified normative language for Get and GetMutltiple

Tom


Steve Graham/Raleigh/IBM@IBMUS wrote on 09/20/2004 08:44:37 AM:

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