Re: [wsrf] New Issue: Need a facility to handle collections ofResourceProperties.

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

So the quandry as I understand it is that SetResourceProperties (and its
kin) have very limited semantics.  Obviously, this is intentional.
WS-ResourceProperties restricts itself to dealing with setting resource
properties by the RP element names.  This is a reasonable assertion since
the hallmark of a ResourcePropertyElement is its name, every RPE must have
one.  That being said, the TC could have opted to allow for extensibility
in the area of SetRP (I am uncertain whether the TC discussed and dismissed
this in the past).

If the TC goes down the extensibility path we would need a couple of
things:
      some sort of SetExpression encapsulating element with a URI attribute
      a required RPElement SetExpressionDialect
      defintion of SetByName dialect definition (what we already have)

So what does this buy us?  It allows others to define language and
semantics of operations over a logical XML document  (as in XQuery).  The
WS-ResourceProperties document would not normatively define such a thing,
nor would it require it's usage.  WSRP might not even mention the URI.

So why discuss this.  IMO this is the appropriate mechanism for dealing
with the problem that Tim is bringing up.  Surely this TC would not
prescribe a mechanism for fine grained pathing and selective updating of an
XML document.  Certainly this TC would seek to leverage the work of other
standards (XQuery...).

As an orthogonal discussion the removal of the Member service requirement
from a ServiceGroup seems worthy of discussion in and of itself.

Tom

Tim Banks <tim_banks@uk.ibm.com> wrote on 06/27/2005 07:56:32 AM:

>
>
>
>
> 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.
>