ServiceGroup comments

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

Hello,

These are comments HP has against the WS-ServiceGroup spec. I apologise
for their late arrival, I thought they had been sent to nthe list
earlier.

Bryan


To make QueryResourceProperty an efficient way to query across members
of a service group, modify the resource properties document of a service
group to have this structure:
<sg:Entry>
  <foo:resourceType1>
    <foo:Property1>hello</foo:property1>
    <foo:Property2>world</foo:property2>
  </foo:resourceType1>
  <wsrf-sg:MemberEPR>...</wsrf-sg:MemberEPR>
  <wsrf-sg:MembershipProperties>...</wsrf-sg:MembershipProperties>
</sg:Entry>
<sg:Entry>
  <foo:resourceType1>
    <foo:Property1>how are</foo:property1>
    <foo:Property2>you</foo:property2>
  </foo:resourceType1>
  <wsrf-sg:MemberEPR>...</wsrf-sg:MemberEPR>
  <wsrf-sg:MembershipProperties>...</wsrf-sg:MembershipProperties>
</foo:resourceType1>
</sg:Entry>
<sg:Entry>
  <bar:resourceType2>
    <bar:Property1>hello</bar:property1>
    <bar:Property2>world</bar:property2>
  </bar:resourceType2>
  <wsrf-sg:MemberEPR>...</wsrf-sg:MemberEPR>
  <wsrf-sg:MembershipProperties>...</wsrf-sg:MembershipProperties>
</sg:Entry>
In addition, one of the elements under "Membership Properties" should
indicate whether the resource properties document of the member
presented in the "entry" element corresponds to the entire resource
properties document or a subset of it.


Go beyond just property Qnames in "contentElement", allow Xpath
statements that must evaluate to true.


Remove representation of each entry as a stand-alone resource (I believe
this is already an issue)


Remove ability for the same member to belong to the service group more
than once.


Since our portType aggregation mechanism looses the QName of the
orginial portType, does it make sense to use Qnames of portTypes in
membership ContentRule? Shouldn't we use SOAPAction of messages? ... Or
figure out a way to maintain original portType Qnames in our aggregation
mechanism... ;-)