RE: [wsrf] [WSRF 4] continued discussion

["Murray, Bryan P." <bryan.murray@hp.com>]

I think it helps a lot to change "defined as" to something like "that
is" so
you don't get the impression that it is a schema thing. I also think the
addition
of the operation we added on the previous call to
GetAllResourceProperties helps
a client to know what proeprties can be queried.

This is a good solution for this issue.

Bryan

-----Original Message-----
From: Tom Maguire [mailto:tmaguire@us.ibm.com] 
Sent: Tuesday, September 21, 2004 1:08 AM
To: Steve Graham
Cc: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] [WSRF 4] continued discussion





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