OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?







Lets consider a concrete example:
Presume a Producer (JSR168 semantics) exposes the following entities:

PreferredGroupID     EntityName
  Group1                           P1
  Group1                           P2
  Group1                           P3
  Group2                           P4
  Group2                           P5

The Consumer assigns the following grouping:

groupID  Entity
 G1              P1
 G1              P2
 G1              P5
 G2              P1 (2nd instance on page)
 G2              P2 (2nd instance on page)
 G3              P3

Key questions:
1) Is there value to having the Consumer isolate the 2 instances of P1 from
each other? I think the answer is yes.
2) Should the Consumer be allowed to place P5 in G1 despite this going
against the "preference" of the Producer? I can go either way on this. If
it is allowed, then Producers where data sharing semantics would not allow
these to share data (i.e. JSR168) should define their own sharing scopes
within the Consumer's specification to enforce their policies. Producers
without such policies could pass through the Consumer's sharing
specifications. I can also argue that the Producer specification should be
taken as more than a hint and therefore it is invalid for the consumer to
include P5 in G1.
3) Should the Consumer be allowed to isolate entities the Producer has
grouped? In other words, should the Consumer be forced to place P3 in one
of the other groups? I think there is always value in allowing such partial
groups and would prefer the Consumer have this flexibility.

I hope this helps, but since I wasn't the originator of this proposal I
also hope I haven't gone way off base on what was proposed.



                                                                                                                  
                      Michael Freedman                                                                            
                      <Michael.Freedman@        To:       wsrp-wsia@lists.oasis-open.org                          
                      oracle.com>               cc:                                                               
                                                Subject:  Re: [wsrp-wsia] Issues #6 - Is groupID required?        
                      10/15/2002 03:45                                                                            
                      PM                                                                                          
                                                                                                                  
                                                                                                                  



Rich,
   On proposal (1), you state it "requires that the Producer mediated
sharing
is scoped to all of the entities it exposes".  I think it might be fairer
to
state:  "In our protocol, Producer-mediated sharing is scoped to all of the
entities it exposes.  Producers needing finer grained sharing are free to
implement this function transparently to the consumer within this scope".
I.e.  The function defined in proposal (2), is easily implemented entirely
within the producer without exposing any notion of groupID.
   As for proposal (2), that do we think the value of tighter "grouping"
is?  I
recall two have been discussed:  (1) used to isolate two instances of a
portlet
from each other -- i.e. a portlet doesn't have to worry about colliding
with
other instances of itself in this shared space (2) a way to pass/manage
sharing
between a set of portlets.
    I don't see how either of these is satisfied by your second proposal.
If I
understand it correctly, the preferredGroupID is at the entity [type] level
not
the per entity level.  I.e. all consumer configured entities derived from
this
proffered entity get the same preferredGroupID.  If this is the case then
value
(1) cited above isn't achieved.   As value (2) is just an extension of (1)
--
i.e. the use case is meant to group a specific set of entities -- not all
consumer configured entities + its prooffered entity, it also isn't
achieved.
   Can you explain the usage case proposal (2) addresses?
       -Mike-


Rich Thompson wrote:

> We need to reach a decision on this ... basically everyone agrees that
the
> semantics in draft v0.7 need clarification for this to be useful. The 2
> proposals we have had put forward are:
>
> 1) Remove groupID from the protocol as we have no specific semantics for
> it.
>       - It has been noted that this, combined with keeping
initEnvironment
> (), requires that the Producer-mediated sharing is scoped to all of the
> entities it exposes.
>
> 2) Add entity metadata for "preferredGroupID" - Allows Producers to
expose
> the effect of their data sharing policies.
>     Add semantics to groupID that it specifies Consumer-level scoping on
> the Producer-mediated data sharing. This allows the Producer to define
> finer levels of data-sharing scopes, but does not allow those to cross
the
> Consumer-specified scoping. This would be added as a MUST restriction on
> the Producer.
>
> I have tried to represent these proposals objectively (sorry if I failed
to
> do so). In order to reach a decision, we need explicit pro/con statements
> for these proposals and I would ask their proponents to post them ASAP.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC