[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue: Need a facility to handle collections of ResourceProperties.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]