New Issue: Need a facility to handle collections of ResourceProperties.

[Tim Banks <tim_banks@uk.ibm.com>]

Currently the WSRF specs deal with the following kinds of collection:

o A repeatable child element (MaxOccurs >1) of the ResourceProperties
Document. The collection can be updated as a unit using
UpdateResourceProperties or SetResourceProperties; this works well for
small collections.

o A ServiceGroup containing a collection of ServiceGroupEntry WS Resources.
The ServiceGroupEntries represent the membership in the group of
independently addressable Member Services. Each SGEntry must contain an EPR
to the Member Service and may also contain summary
description/extract/other information about the Member Service.   The
ServiceGroupEntries can be independently updated and ServiceGroup works
well for distributed collections

A facility is needed to handle larger collections of ResourceProperties
within a ResourceProperties document without replacing the whole collection
and without the complexities of MemberServices inherent in ServiceGroup.

Examples:

Examples 1:

<ShoppingCart>
 <TotalCartCost/>
  [<Item>
   <ItemNumber>
   <ProductCode/>
   <Description/>
   <Quantity/>
   <ItemCost>
   </Item>]*
</ShoppingCart>

The update Operation is to Change the Quantity of an item.

Example 2:

<Printer>
  <Job_Queue_count/>
  [<Job>
     <Job_Id/>
     <OriginatingUser/>
     <Job_state/>
  </Job> ]*
</Printer>

The update operation is to cancel a job.


Proposal: One possible resolution, discussed on the TC telecon on June
13th, is to relax the constraints on ServiceGroupEntries so that the
MemberServiceEPR is optional. Changes may also be required to the meaning
of the MembershipContentRule which currently constrains interfaces
referenced by the MemberServiceEPR, and to the meaning of wsrf-sg:RPDoc
which refers to RPdoc of the Member Service.