| Re: [higgins-dev] Dealing with multi versus single valued attributes |
|
I checked in the minimal changes to give the convenience of calling getValue() when a property is single-valued.
I haven't yet checked in the replace* methods we talked about because I wanted to do more analysis in terms of all the places that belongs. The proposal would end up allowing people to replace property values, but not properties, and not digital subjects.
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 5/2/07 4:33 PM >>> After debating this for an hour or so at the current F2F, we've decided to leave the multi-valuedness of attributes as it is today.
If we keep the current view, we still have the issue of wrapping up this http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02365.html
I'll just move on proposal #3 there, and we can move from there.
Jim
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/30/07 8:52 PM >>> I think the primary goal with this issue is that we should strive to model in the most natural, simple way possible. We may be doing that right now, I don't know -- that's all I'm exploring. Beyond that, we spend a lot of time discussing perceived issues that crop up due to the current model. Meaning, we say attributes contain values at the abstract level, but in practice we believe they most commonly contain only a single value.
So the question comes up: what's the most natural way to model data where an attribute may be multi-valued, but is most often single valued? I feel like both methods below work, but cause us to shift the way we think about attributes very slightly (Does a group have a member attribute with multiple values, or does it have a membership attribute which is a list of values?).
To me, I don't like the strawman below for multi-valued attributes because there's an extra layer we don't need. Let's compare the two models when dealing with single-valued attributes:
today:
// this discovers the single-valuedness
if (prop.getPropertyModel().getMaxCardinality() == 1)
// this gets me the single value
IPropertyValue val = myAttribute.getValue(false);
today + Proposition 3:
// this discovers the single-valuedness
if (myAttribute.isSingleValued()) {
// this gets me the single value IPropertyValue val = ((ISingleValuedProperty) prop).getValue();strawman:
// this gets me the single value
IPropertyValue val = myAttribute.getValue();
// When this is true, it's a simple, single value if (val.isSimple())
Note that in the strawman, there's no difference at the API layer between a complex value, a list of complex values, or a list of simple values. I think of the strawman as a model more like the way XML works. That is, a node has either a simple value (which has a lexical string representation), or it is complex (it has sub-nodes).
Hmm, if we were to look at it that way, maybe we'd want to say that a Property itself is either simple or complex. When simple, you can call getValue(), when complex, you can call getProperties(). It still ends up looking a little silly when the CP is backed by LDAP because every multi-valued attribute turns into a Property with sub-properties, each having the same name. But that's what you'd have if you represented an LDAP entry in XML I think.
Jim
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 4/30/07 10:30 AM >>> I have a fundamental problem on this one, namely, what is the inherent badness in the notion of representing multi-valued attributes at the IdAS API level? What's broken? What are we "fixing"? Assuming something IS broken, what are the use cases we're trying to handle? Tom >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/28/2007 10:12 AM >>> If IAttribute myAttribute represents a thing called "hobbies", today I access a multi-valued attribute this way: URI attrType = myAttribute.getType(); // returns a URI, probably with the word "hobbies" at the end. // this gets me the values Iterator iter = myAttribute.getValues(); while (iter.hasNext()) { // assuming I have apriori knowledge of it being simple ISimpleValue val = ((ISimpleValue)iter).next(); val.getType(); // returns a URL like http://www.w3.org/2001/XMLSchema#string String str = ((String)val).getData(); System.out.println(attrType + " = " + str); } With the strawman: URI attrType = myAttribute.getType(); // returns a URI, probably with the word "hobbies" at the end. // assuming I have apriori knowledge that it's a complex value which is a list of strings IComplexValue outerVal = myAttribute.getValue(); Iterator iter = outerVal.getProperties(); while (iter.hasNext()) { IProperty prop = ((IProperty)iter).next(); prop.getType(); // returns something rather useless in this particular case // assuming I have apriori knowledge of each element being a simple string ISimpleValue val = prop.getValue(); val.getType(); // returns a URL like http://www.w3.org/2001/XMLSchema#string String str = ((String)val).getData(); System.out.println(attrType + " = " + str); } I got halfway through the strawman code and realized we already had this discussion almost a year ago. I remember typing similar examples, thinking to myself -- yuk. Well, other input is welcome. Maybe there's a positive spin I'm not seeing. Jim >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/28/07 9:26 AM >>> It may be a good time to re-visit an alternative approach to dealing with the issue of multi-valued attributes. This is something I've resisted and I probably still don't like it, but I think we need to at least consider it while the topic is on people's minds. A strawman proposal is to do away with the notion of multi-valued attributes at the IdAS API level. Random thoughts about that: - A CP with a backing store which has such a model (LDAP comes to mind) would represent a multi-valued attribute as if it were a single valued attribute which is a complex value. Each element of the complex value has some generic type (like "value"), and represents one of the values in the backing store. Updating these separately is now possible with the latest update operations. - IFilter and friends may need to be re-visited such that a filter element can say (match if "hobbies" contains an element called "flying"). This ought to be made possible anyway. It would be good to get more input on this than just that from Valery, Tom, and myself. Jim _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |