I think we're getting somewhere here.  I agree with all the views 
  you have in this reply except one...
  >2. Attibute was returned by IDigitalSubject.getAttribute(). In this 
  case it 
>is "stored" attribute and its value should be 
  changed.
  I think it's too confusing to the IdAS consumer (and will also require 
  state tracking by the CP) to have two semantics associated with the same 
  method based on how the object was originally obtained.  I would 
  rather see setValue only affect the in-memory copy of the Attribute.  
  
  In other words, think of IAttribute's returned by 
  IDigitalSubject.getAttribute as returned by value rather than returned by 
  reference (which would be more symmetric with the way you propose we think of 
  IAttributes which are passed to IContext.addSubject).  If we do this, the 
  semantics of an IAttribute instance remain consistent.
  In fact, it was this very issue which led me to push all build and update 
  methods to IContext and off of the specific objects.  There was nothing 
  to indicate to the IdAS consumer when an update would actually change 
  something in a backing data store.  For example, a complex application 
  might have a function which takes an IAttribute and at some point might call 
  setValue on it.  That function might not know how the IAttribute was 
  obtained.
  The only argument I see against this is one of convenience to the IdAS 
  consumer.  Let's se what it would take to update an attribute once it has 
  been gotten from a subject:
  There are a number of ways to make the 3 lines of code easier.  We 
  could overload updateSubject to take a single UpdateOperation (but there is 
  another thread asking that we discontinue overloading). We could add more 
  methods like IContext.updateAddAttribute(String cuid, IAttribute attr) which 
  are really just shortcuts for the three lines above, but then we get method 
  bloat.  I'm not sure those 3 lines of code are that bad.
  >>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 3/28/07 
  8:49 AM >>>
Jim,
> // Next, I assume all would agree 
  that this would add the entire 
> myAttribute to mySubject2
> 
  Vector v = new Vector();
> v.add(myAttribute);
> String s = 
  myContext.addSubject("http://...#person", "mySubject2", v, 
> 
  null);
I think we should consider myAttribute as a parameter by value 
  not by 
reference. For mySubject2 we should create its own attribute 
  instance, not 
just set a reference to myAttribute. So there should not be 
  any two 
DigitalSubjects which have a reference to the same attribute/value 
  instance.
> // Next, I assume all would agree that this would add 
  the entire 
> myAttribute to mySubject2
> Vector v = new 
  Vector();
> v.add(myAttribute);
> String s = 
  myContext.addSubject("http://...#person", "mySubject2", v, 
> 
  null);
> // Here's where I'm confused.  Does this affect 
  mySubject1, mySubjet2, 
> both, or neither?
> 
  myAttribute.setValue(buildSimpleValue("http://www.w3.org/2001/XMLSchema/normalizedString","brown"));
I 
  think we should separate two possible situations:
1. Attribute is 
  "in-memory" instance created by IContext.buildAttribute(). 
In this case 
  IAttribute.setValue() shouldn't cause any changes for 
DigitalSubject. In 
  other words setValue() for "in-memory" attribute should 
invoke only 
  "in-memory" changes for this attribute.
2. Attibute was returned by 
  IDigitalSubject.getAttribute(). In this case it 
is "stored" attribute and 
  its value should be changed.
Thanks,
Sergey Lyakhov
----- 
  Original Message ----- 
From: "Jim Sermersheim" 
  <jimse@xxxxxxxxxx>
To: "'Higgins (Trust Framework) Project developer 
  discussions'" 
<higgins-dev@xxxxxxxxxxx>
Sent: Wednesday, March 
  28, 2007 12:23 AM
Subject: [higgins-dev] Stored versus in-memory IProperty 
  instances (was:IdAS 
is now Java 1.4)
>>> "Sergey 
  Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 3/27/07 10:51 AM 
  >>>
<snip>
>I think we need to create a new 
  "stored" instance of IProperty for each 
>stored Digital Subject 
  regardless of which type of IProperty ("stored" or 
>"in-memory") was 
  passed to setValue(). In this case there will be no any 
>two or more 
  Subjects which refers to the same "stored" instance of 
>attribute, 
  metadata or value.
I'm trying to envision what this would look like. 
  Let's use some sample code 
to talk about it:
IDigitalSubject 
  mySubject1 = myContext.getSubject("subject1");
IDigitalSubject mySubject2 = 
  myContext.getSubject("subject2");
IAttribute myAttribute = 
  mySubject1.getAttribute("eyeColor", null);
// At this point, is 
  myAttribute associated with MySubject1 in terms of 
updates?
// In other 
  words what happens here, does it only affect the in-memory copy, 
or does 
  it also affect mySubject1?
// I think you're opinion is that this should 
  affect 
  mySubject1.
myAttribute.setValue(buildSimpleValue("http://www.w3.org/2001/XMLSchema/normalizedString","blue"));
// 
  Next, I assume all would agree that this would add the entire myAttribute 
  
to mySubject2
Vector v = new Vector();
v.add(myAttribute);
String 
  s = myContext.addSubject("http://...#person", "mySubject2", v, 
  null);
// Here's where I'm confused.  Does this affect mySubject1, 
  mySubjet2, both, 
or 
  neither?
myAttribute.setValue(buildSimpleValue("http://www.w3.org/2001/XMLSchema/normalizedString","brown"));
Jim
_______________________________________________
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