Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: EntityId decision analysis page (was RE:[higgins-dev]entityID not an attribute?) 
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
>

Back to the top