[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: EntityId decision analysis page (wasRE:[higgins-dev]entityIDnotan attribute?)
|
This is interesting. So, further... Maybe we could define our policy
objects such when one is going about the business of specifying an
entity (as a subject or resource), instead of allowing any old string or
textual identifier to be passed there, one must actually pass an
IEntity. That way, the policy object could be sure to call
getCanonicalID. Maybe that's heavy-handed. I just hate leaving gapping
holes lying around for people to stumble into.
Anyway to repeat... An Entity could be referred to by it's
'human-friendly' entityID which isn't guaranteed to always be able to
find the same entity (though one imagines confidence being at least
medium to med-high), and also possibly be referred to by its canonical
entityID (which may or may not be less aesthetically pleasing to humans)
which is guaranteed to get you back to the original entity. I think
this may be an example of what Tony was talking about when he was saying
"an entity could have multiple entity identifiers"
we could just overload getEntityID to take a bool bEnsureCanonical arg.
Also, the following could be used to test whether an entityID is
canonical (assuming EntityID's are Strings here:
String friendlyID = myEntity.getEntityID();
String canonicalID = myEntity.getEntityID(true);
if (friendlyID !=null && canonicalID != null &&
friendlyID.equals(canonicalID)) {
// the entity has a friendly id and it is canonical.
}
of course, one interested in the canonical id would simply get that and
use it.
Jim
>>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 09/16/08 2:04 PM >>>
Yes, it's a good point Jim - all a getEntityIdsMutable method could do
is
serve as an input to a application making policy decisions.
More useful might be a method for asking an Entity specifically for an
immutable EntityId. Call it getCanonicalId. The rule would be that it
always
returns one EntityId value that the Context asserts is the immutable
canonical identifier for that Entity in that Context.
If the Context does not support immutable identifiers, then
getCanonicalId
will return an error, and the application can plan accordingly. But I
suspect the value of having an immutable reference would incent CPs to
support this method.
=Drummond
> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
> Sent: Monday, September 15, 2008 11:01 PM
> To: 'Higgins (Trust Framework) Project developer discussions'
> Subject: RE: EntityId decision analysis page
(wasRE:[higgins-dev]entityID
> notan attribute?)
>
> How does it help an application to know whether a context's entityIDs
> are mutable? Does that tell the client that they'd better not use
this
> Higgins policy objects (at least none that refer to entities as
subjects
> or resources)?
>
>
>
> >>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 09/15/08 9:59 PM >>>
> Okay, after talking with Markus and Paul on the phone, and gathering
the
> last round of comments in email, I did another update to
> http://wiki.eclipse.org/EntityId_Requirements. This should really be
> called
> "EntityId Requirements for Context Data Model 1.1", since what we're
> talking
> about here is the delta between what we have in 1.0 and 1.1.
>
> The current state as I understand it in 1.0 is that the entityId
> parameter
> to the getEntity method on IContext interface:
>
> 1. Is of type string (confirm?)
> 2. Has cardinality 0..1
> 3. MUST be Context-unique; MAY be globally unique.
> 4. Is always exposed as an Attribute.
> 5. Exposes no information about mutability.
>
> Following are the proposed changes in 1.1. Please do comment on each
> one.
>
> #1: NOT REQUIRE entityId TO BE EXPOSED AS AN ATTRIBUTE
>
> The proposed change is to make EntityId OPTIONAL to expose as an
> Attribute.
> Contexts that do not want to expose the EntityId can omit it from the
> list
> of Attributes for an Entity. Note: if the EntityId is mutable, it
SHOULD
> be
> exposed as an Attribute so it can be modified.
>
> #2: ADD getEntityIdsMutable METHOD
>
> The proposed change is to add a getEntityIdsMutable() method on
IContext
> that returns a Boolean indicating whether EntityIds in that Context
are
> mutable or not. True = mutable.
>
> #3: ADD getIdentifiers METHOD
>
> The proposed change is to add a getIdentifiers() method on IEntity
that
> returns all Identifiers for an Entity (0..n). By definition this would
> return all identifiers that the Context considers to be synonyms of
the
> EntityId, even if the EntityId was not among the values returned.
>
> #4: MULTI-PART KEYS
>
> The proposal is to keep it simple by requiring multi-part keys to be
> serialized into a composite identifier, which can then be used as an
> EntityId or exposed as an Identifiers attribute.
>
> Again, comments welcome so we can close this.
>
> =Drummond
>
> > -----Original Message-----
> > From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> > bounces@xxxxxxxxxxx] On Behalf Of Tom Doman
> > Sent: Monday, September 15, 2008 1:34 PM
> > To: 'Higgins (Trust Framework) Project developer discussions'
> > Subject: RE: EntityId decision analysis
> page(wasRE:[higgins-dev]entityID
> > not an attribute?)
> >
> > +1
> >
> > On #1, I think more complex could get CP implementors into some
> > difficult situations though that's just a hunch w/o concrete
examples.
> > But, like Jim, I prefer simple.
> >
> > On "another question", I don't see how we could guarantee
immutability
> > or referential integrity. I understand the need, just not how we'd
> pull
> > it off especially w/o producing a major house of cards to implement.
> > Event notification from the backing store, if even possible, would
> still
> > not be guaranteed to be reliable. Maybe doing the best we can is
> better
> > than no guarantee whatsoever.
> >
> > Tom
> >
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
> ------------------- TEXT.htm follows -------------------
> <html>
> <head>
> <style type=3D"text/css">
> <!--
> body { font-variant: normal; margin-left: 4px; margin-bottom:
1px;
> =
> line-height: normal; margin-top: 4px; margin-right: 4px }
> p { margin-bottom: 0; margin-top: 0 }
> -->
> </style>
> =20
> </head>
> <body style=3D"margin-left: 4px; margin-bottom: 1px; margin-top:
4px; =
> margin-right: 4px">
> <p style=3D"margin-bottom: 0; margin-top: 0">
> <font face=3D"Dialog" size=3D"2">How does it help an application
to
> =
> know whether a context's entityIDs are mutable? Does
that =
> tell the client that they'd better not use this Higgins policy
objects
> =
> (at least none that refer to entities as subjects or
> resources)?=
> ; </font> </p>
> <br> =20
> <p style=3D"margin-bottom: 0; margin-top: 0">
> <br>
> <br>
> >>> "Drummond Reed"
> <drummond.reed@xxxxxxxxxxxx=
> > 09/15/08 9:59 PM >>><br>Okay, after talking with
Markus
> =
> and Paul on the phone, and gathering the<br>last round of comments
in
> =
> email, I did another update to<br><a
> href=3D"http://wiki.eclipse.org/En=
>
tityId_Requirements.">http://wiki.eclipse.org/EntityId_Requirements.</a>&n
> b=
> sp;This should really be called<br>"EntityId Requirements for
Context
> =
> Data Model 1.1", since what we're talking<br>about here
is =
> the delta between what we have in 1.0 and 1.1.<br><br>The current
state as
> =
> I understand it in 1.0 is that the entityId parameter<br>to the
getEntity
> =
> method on IContext interface:<br><br>   1. Is of type =
> string (confirm?)<br>   2. Has cardinality
=
> 0..1<br>   3. MUST be Context-unique; MAY be
globally =
> unique.<br>   4. Is always exposed as an
> Attribute.<br> =
> ;  5. Exposes no information about
mutability.<br><br>Following
> =
> are the proposed changes in 1.1. Please do comment on each
> one.<br><br>#=
> ;1: NOT REQUIRE entityId TO BE EXPOSED AS AN ATTRIBUTE<br><br>The
proposed
> =
> change is to make EntityId OPTIONAL to expose as an
Attribute.<br>Contexts
> =
> that do not want to expose the EntityId can omit it from the
list<br>of =
> Attributes for an Entity. Note: if the EntityId is mutable, it
SHOULD
> =
> be<br>exposed as an Attribute so it can be modified.<br><br>#2:
ADD =
> getEntityIdsMutable METHOD<br><br>The proposed change is to add a =
> getEntityIdsMutable() method on IContext<br>that returns a
Boolean
> =
> indicating whether EntityIds in that Context are<br>mutable or not.
True =
> = mutable.<br><br>#3: ADD getIdentifiers METHOD<br><br>The =
> proposed change is to add a getIdentifiers() method on IEntity
=
> that<br>returns all Identifiers for an Entity (0..n). By
> definition=
> this would<br>return all identifiers that the Context considers to be
=
> synonyms of the<br>EntityId, even if the EntityId was not among
the =
> values returned.<br><br>#4: MULTI-PART KEYS<br><br>The proposal is
to
> =
> keep it simple by requiring multi-part keys to be<br>serialized into a
=
> composite identifier, which can then be used as an<br>EntityId or
=
> exposed as an Identifiers attribute.<br><br>Again, comments
welcome so
> =
> we can close this.<br><br>=Drummond<br><br>> -----Original =
> Message-----<br>> From: higgins-dev-bounces@xxxxxxxxxxx
> [mailto:higg=
> ins-dev-<br>> bounces@xxxxxxxxxxx] On Behalf Of Tom
Doman<br>> =
> Sent: Monday, September 15, 2008 1:34 PM<br>> To:
'Higgins
> =
> (Trust Framework) Project developer discussions'<br>> =
> Subject: RE: EntityId decision analysis page(wasRE:[higgins-
> dev]=
> ;entityID<br>> not an attribute?)<br>><br>>
> +1<br>>=
> <br>> On #1, I think more complex could get CP implementors
=
> into some<br>> difficult situations though that's just a hunch
w/o
> =
> concrete examples.<br>> But, like Jim, I prefer
> simple.<br>><=
> br>> On "another question", I don't see how we
could
> =
> guarantee immutability<br>> or referential integrity.  I
=
> understand the need, just not how we'd pull<br>> it off =
> especially w/o producing a major house of cards to implement.<br>>
=
> Event notification from the backing store, if even possible,
would
> =
> still<br>> not be guaranteed to be reliable.  Maybe doing
the
> =
> best we can is better<br>> than no guarantee
> whatsoever.<br>><br>>=
>
>
Tom<br>><br><br>_______________________________________________<br>higg
> =
> ins-dev mailing list<br>higgins-dev@xxxxxxxxxxx<br><a
> href=3D"https://dev.e=
>
clipse.org/mailman/listinfo/higgins">https://dev.eclipse.org/mailman/listi
> n=
> fo/higgins</a>-dev<br>
> </p>
> </body>
> </html>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
------------------- TEXT.htm follows -------------------
<html>
<head>
<style type=3D"text/css">
<!--
body { line-height: normal; font-variant: normal; margin-bottom: =
1px; margin-top: 4px; margin-left: 4px; margin-right: 4px }
p { margin-top: 0; margin-bottom: 0 }
-->
</style>
=20
</head>
<body style=3D"margin-left: 4px; margin-top: 4px; margin-bottom: 1px; =
margin-right: 4px">
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">This is interesting. So, =
further... Maybe we could define our policy objects such when one is going =
about the business of specifying an entity (as a subject or resource=
1;, instead of allowing any old string or textual identifier to be =
passed there, one must actually pass an IEntity. That way, =
the policy object could be sure to call getCanonicalID. Maybe =
that's heavy-handed. I just hate leaving gapping holes lying =
around for people to stumble into.</font> </p>
<br> =20
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">Anyway to repeat... An Entity could =
be referred to by it's 'human-friendly' entityID which =
isn't guaranteed to always be able to find the same entity (though =
one imagines confidence being at least medium to med-high), and =
also possibly be referred to by its canonical entityID (which may or =
may not be less aesthetically pleasing to humans) which is guaranteed =
to get you back to the original entity. I think this may be an =
example of what Tony was talking about when he was saying "an entity =
could have multiple entity identifiers"</font> </p>
<br> =20
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">we could just overload getEntityID =
to take a bool bEnsureCanonical arg. Also, the following could =
be used to test whether an entityID is canonical (assuming EntityID'=
;s are Strings here:</font> </p>
<br> =20
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">String friendlyID = myEntity.get=
EntityID();</font> </p>
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">String canonicalID = myEntity.ge=
tEntityID(true);</font> </p>
<br> =20
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">if (friendlyID !=null =
&& canonicalID != null && friendlyID.equals(can=
onicalID)) {</font> </p>
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog"> // the entity has =
a friendly id and it is canonical.</font> </p>
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">}</font> </p>
<br> =20
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">of course, one interested in =
the canonical id would simply get that and use it.</font> </p>
<br> =20
<p style=3D"margin-bottom: 0; margin-top: 0">
<font size=3D"2" face=3D"Dialog">Jim</font><br><br>>>> =
"Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 09/16/08 2:04 =
PM >>><br>Yes, it's a good point Jim - all a getEntityIdsM=
utable method could do is<br>serve as an input to a application making =
policy decisions.<br><br>More useful might be a method for asking an =
Entity specifically for an<br>immutable EntityId. Call it getCanonicalId. =
The rule would be that it always<br>returns one EntityId value that the =
Context asserts is the immutable<br>canonical identifier for that Entity =
in that Context.<br><br>If the Context does not support immutable =
identifiers, then getCanonicalId<br>will return an error, and the =
application can plan accordingly. But I<br>suspect the value of having an =
immutable reference would incent CPs to<br>support this method.<br><br>==
;Drummond<br><br>> -----Original Message-----<br>> From: higgins-dev-=
bounces@xxxxxxxxxxx [mailto:higgins-dev-<br>> bounces@xxxxxxxxxxx	=
3; On Behalf Of Jim Sermersheim<br>> Sent: Monday, September =
15, 2008 11:01 PM<br>> To: 'Higgins (Trust Framework) =
Project developer discussions'<br>> Subject: RE: EntityId decision =
analysis page (wasRE:[higgins-dev]entityID<br>> notan =
attribute?)<br>><br>> How does it help an application to =
know whether a context's entityIDs<br>> are mutable?  =
Does that tell the client that they'd better not use this<br>> =
Higgins policy objects (at least none that refer to entities as =
subjects<br>> or resources)?<br>><br>><br>><br>> =
>>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> =
09/15/08 9:59 PM >>><br>> Okay, after talking with Markus =
and Paul on the phone, and gathering the<br>> last round of =
comments in email, I did another update to<br>> <a href=3D"http://wi=
ki.eclipse.org/EntityId_Requirements.">http://wiki.eclipse.org/EntityId_Req=
uirements.</a> This should really be<br>> called<br>> "Enti=
tyId Requirements for Context Data Model 1.1", since what =
we're<br>> talking<br>> about here is the delta between what we =
have in 1.0 and 1.1.<br>><br>> The current state as I understand it =
in 1.0 is that the entityId<br>> parameter<br>> to the getEntity =
method on IContext interface:<br>><br>>    1. Is =
of type string (confirm?)<br>>    2. =
Has cardinality 0..1<br>>    3. MUST be Context-uniq=
ue; MAY be globally unique.<br>>    4. Is =
always exposed as an Attribute.<br>>    5. Exposes =
no information about mutability.<br>><br>> Following are the =
proposed changes in 1.1. Please do comment on each<br>> one.<br>><br>=
> #1: NOT REQUIRE entityId TO BE EXPOSED AS AN ATTRIBUTE<br>><br>=
> The proposed change is to make EntityId OPTIONAL to expose as =
an<br>> Attribute.<br>> Contexts that do not want to expose the =
EntityId can omit it from the<br>> list<br>> of Attributes for an =
Entity. Note: if the EntityId is mutable, it SHOULD<br>> be<br>> =
exposed as an Attribute so it can be modified.<br>><br>> #2: ADD =
getEntityIdsMutable METHOD<br>><br>> The proposed change is to add a =
getEntityIdsMutable() method on IContext<br>> that returns a =
Boolean indicating whether EntityIds in that Context are<br>> mutable =
or not. True = mutable.<br>><br>> #3: ADD getIdentifiers =
METHOD<br>><br>> The proposed change is to add a getIdentifiers(&=
#41; method on IEntity that<br>> returns all Identifiers for an Entity =
(0..n). By definition this would<br>> return all identifiers =
that the Context considers to be synonyms of the<br>> EntityId, =
even if the EntityId was not among the values returned.<br>><br>> =
#4: MULTI-PART KEYS<br>><br>> The proposal is to keep it simple =
by requiring multi-part keys to be<br>> serialized into a composite =
identifier, which can then be used as an<br>> EntityId or exposed =
as an Identifiers attribute.<br>><br>> Again, comments welcome =
so we can close this.<br>><br>> =Drummond<br>><br>> > =
-----Original Message-----<br>> > From: higgins-dev-bounces@eclipse.o=
rg [mailto:higgins-dev-<br>> > bounces@xxxxxxxxxxx] On =
Behalf Of Tom Doman<br>> > Sent: Monday, September 15, 2008 =
1:34 PM<br>> > To: 'Higgins (Trust Framework) Project =
developer discussions'<br>> > Subject: RE: EntityId decision =
analysis<br>> page(wasRE:[higgins-dev]entityID<br>> > =
not an attribute?)<br>> ><br>> > +1<br>> =
><br>> > On #1, I think more complex could get CP =
implementors into some<br>> > difficult situations though that's =
just a hunch w/o concrete examples.<br>> > But, like Jim, I =
prefer simple.<br>> ><br>> > On "another question"=
4; I don't see how we could guarantee immutability<br>> > or =
referential integrity.  I understand the need, just not how =
we'd<br>> pull<br>> > it off especially w/o producing a major =
house of cards to implement.<br>> > Event notification from the =
backing store, if even possible, would<br>> still<br>> > =
not be guaranteed to be reliable.  Maybe doing the best we can =
is<br>> better<br>> > than no guarantee whatsoever.<br>> =
><br>> > Tom<br>> ><br>><br>> ________________________=
_______________________<br>> higgins-dev mailing list<br>> higgins-de=
v@xxxxxxxxxxx<br>> <a href=3D"https://dev.eclipse.org/mailman/listinfo/h=
iggins">https://dev.eclipse.org/mailman/listinfo/higgins</a>-dev<br>><br=
>><br>> ------------------- TEXT.htm follows -------------------<br>&=
gt; <html><br>>   <head><br>>  &=
#160;  <style type=3D"text/css"><br>> =
;      <!--<br>>   &=
#160;     body { font-variant: =
normal; margin-left: 4px; margin-bottom: 1px;<br>> =
=<br>> line-height: normal; margin-top: 4px; margin-right: =
4px }<br>>        &nbs=
p;p { margin-bottom: 0; margin-top: 0 }<br>>=
;       --><br>>   =
  </style><br>>    =20<br>>&#=
160;  </head><br>>   <body style=3=
D"margin-left: 4px; margin-bottom: 1px; margin-top: 4px; =
=<br>> margin-right: 4px"><br>>    &n=
bsp;<p style=3D"margin-bottom: 0; margin-top: 0"><b=
r>>       <font face=3D"D=
ialog" size=3D"2">How does it help an application =
to<br>> =<br>> know whether a context&#39;s =
entityIDs are mutable&#63; &nbsp;Does that =<br>>=
; tell the client that they&#39;d better not use this Higgins =
policy objects<br>> =<br>> &#40;at least none that =
refer to entities as subjects or<br>> resources&#41;&=
5;63=<br>> ; </font>    </p><br>=
> <br>     =20<br>>  =
60;  <p style=3D"margin-bottom: 0; margin-top: =
0"><br>>       <br><br>=
>       <br><br>>  =
;     &gt;&gt;&gt; =
&quot;Drummond Reed&quot;<br>> &lt;drummond.reed=
@cordance.net=<br>> &gt; 09/15/08 9:59 PM &gt;&g=
t;&gt;<br>Okay&#44; after talking with =
Markus<br>> =<br>> and Paul on the phone&#44; and =
gathering the<br>last round of comments in<br>> =<br>> =
email&#44; I did another update to<br><a<br>> =
href=3D"http://wiki.eclipse.org/En=<br>> tityId_Requirement=
s."><a href=3D"http://wiki.eclipse.org/EntityId_Requirements.";>http=
://wiki.eclipse.org/EntityId_Requirements.</a></a>&n<br>> =
b=<br>> sp;This should really be called<br>&quot;E=
ntityId Requirements for Context<br>> =<br>> Data Model =
1.1&quot;&#44; since what we&#39;re =
talking<br>about here is =<br>> the delta between what we =
have in 1.0 and 1.1.<br><br>The current state as<br>> =
=<br>> I understand it in 1.0 is that the entityId parameter<br&g=
t;to the getEntity<br>> =<br>> method on IContext interface:<b=
r><br>&#160;&#160;&nbsp;1. Is of =
type =<br>> string &#40;confirm&#63;&=
5;41;<br>&#160;&#160;&nbsp;2. =
Has cardinality =<br>> 0..1<br>&#160;&#160=
;&nbsp;3. MUST be Context-unique&#59; MAY be =
globally =<br>> unique.<br>&#160;&#160;=
;&nbsp;4. Is always exposed as an<br>> Attribute.<br>&=
#160=<br>> ;&#160;&nbsp;5. Exposes no =
information about mutability.<br><br>Following<br>> =
=<br>> are the proposed changes in 1.1. Please do comment on =
each<br>> one.<br><br>&#35=<br>> ;1: NOT =
REQUIRE entityId TO BE EXPOSED AS AN ATTRIBUTE<br><br>The =
proposed<br>> =<br>> change is to make EntityId OPTIONAL to =
expose as an Attribute.<br>Contexts<br>> =<br>> that do =
not want to expose the EntityId can omit it from the list<br>of =
=<br>> Attributes for an Entity. Note: if the EntityId is mutable&am=
p;#44; it SHOULD<br>> =<br>> be<br>exposed as an =
Attribute so it can be modified.<br><br>&#35;2: =
ADD =<br>> getEntityIdsMutable METHOD<br><br>The =
proposed change is to add a =<br>> getEntityIdsMutable&#40&#=
59;&#41; method on IContext<br>that returns a Boolean<br>=
> =<br>> indicating whether EntityIds in that Context are<br&g=
t;mutable or not. True =<br>> &#61; mutable.<br>&l=
t;br>&#35;3: ADD getIdentifiers METHOD<br><br>Th=
e =<br>> proposed change is to add a getIdentifiers&#40;=
&#41; method on IEntity =<br>> that<br>returns =
all Identifiers for an Entity &#40;0..n&#41;. =
By<br>> definition=<br>>  this would<br>return =
all identifiers that the Context considers to be =<br>> synonyms of =
the<br>EntityId&#44; even if the EntityId was not among =
the =<br>> values returned.<br><br>&#35;4: =
MULTI-PART KEYS<br><br>The proposal is to<br>> =<br>>=
keep it simple by requiring multi-part keys to be<br>serialized =
into a =<br>> composite identifier&#44; which can then =
be used as an<br>EntityId or =<br>> exposed as an Identifiers =
attribute.<br><br>Again&#44; comments welcome =
so<br>> =<br>> we can close this.<br><br>&#61=
;Drummond<br><br>&gt; -----Original =<br>> =
Message-----<br>&gt; From: higgins-dev-bounces@xxxxxxxxxxx<br=
>> &#91;mailto:higg=<br>> ins-dev-<br>&gt&#=
59; bounces@xxxxxxxxxxx&#93; On Behalf Of Tom Doman<br>&a=
mp;gt; =<br>> Sent: Monday&#44; September 15&=
5;44; 2008 1:34 PM<br>&gt; To: &#39;Higgins<b=
r>> =<br>> &#40;Trust Framework&#41; =
Project developer discussions&#39;<br>&gt; =
=<br>> Subject: RE: EntityId decision analysis page&#40;=
wasRE:&#91;higgins-<br>> dev&#93=<br>> =
;entityID<br>&gt; not an attribute&#63;&&=
#35;41;<br>&gt;<br>&gt;<br>> &#4=
3;1<br>&gt;=<br>> <br>&gt; On =
&#35;1&#44; I think more complex could get CP =
implementors =<br>> into some<br>&gt; difficult =
situations though that&#39;s just a hunch w/o<br>> =
=<br>> concrete examples.<br>&gt; But&#44;=
like Jim&#44; I prefer<br>> simple.<br>&gt;&l=
t;=<br>> br>&gt; On &quot;another question&qu=
ot;&#44; I don&#39;t see how we could<br>> =
=<br>> guarantee immutability<br>&gt; or referential =
integrity.&#160;&nbsp;I =<br>> understand the =
need&#44; just not how we&#39;d pull<br>&=
gt; it off =<br>> especially w/o producing a major house of =
cards to implement.<br>&gt; =<br>> Event notification =
from the backing store&#44; if even possible&#44; =
would<br>> =<br>> still<br>&gt; not be guaranteed =
to be reliable.&#160;&nbsp;Maybe doing the<br>> =
=<br>> best we can is better<br>&gt; than no =
guarantee<br>> whatsoever.<br>&gt;<br>&gt;&#=
61;<br>><br>> Tom<br>&gt;<br><br>__________=
_____________________________________<br>higg<br>> =<br>> =
ins-dev mailing list<br>higgins-dev@xxxxxxxxxxx<br><a<br>>=
; href=3D"https://dev.e=<br>> clipse.org/mailman/listinfo/h=
iggins"><a href=3D"https://dev.eclipse.org/mailman/listi";>https://d=
ev.eclipse.org/mailman/listi</a><br>> n=<br>> fo/higgins</a>=
;-dev<br><br>>     </p><br>>=
0;  </body><br>> </html><br>> _________________=
______________________________<br>> higgins-dev mailing list<br>> =
higgins-dev@xxxxxxxxxxx<br>> <a href=3D"https://dev.eclipse.org/mailman/=
listinfo/higgins">https://dev.eclipse.org/mailman/listinfo/higgins</a>-dev<=
br><br>_______________________________________________<br>higgins-dev =
mailing list<br>higgins-dev@xxxxxxxxxxx<br><a href=3D"https://dev.eclipse.o=
rg/mailman/listinfo/higgins">https://dev.eclipse.org/mailman/listinfo/higgi=
ns</a>-dev<br>
</p>
</body>
</html>
