Re: Re[4]: [higgins-dev] IdAS update proposals

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/21/07 2:21 PM >>>
<snip>
>> 2) Having IPropertyValue.isSimple and IPropertyValue.isComplex is
>> redundant.  Only one is needed to determine the nature of the property value.
>
>When we have third possibility (i.e. IPropertyValue.isList) this is
>not true. To determine that some property value is complex, for
>example, it will be necessary to check twice (!isSimple() && !isList()).
 
I hoped that we could say when it's a list, that they're all the same type (simple or complex)

>> 3) IValueList extends IPropertyValue, thus has a type. 
>> Furthermore, it appears to hold a set of IPropertyValues, each of
>> which can have its own type?  Not only that, each contained
>> IPropertyValue could return true from isList().  Is this the
>> intent?  Plus, each contained IPropertyValue could itself be either
>> simple or complex.  It seems like we've added something we didn't mean to here.
>
>In the description for IPropertyValue.getType() I wrote that in the case
>when isList() return true the value returned by getType() represents
>the type of contained items. All contained items will have the same
>type and we could define method like IValueList.addValue() without
>parameters to create an add new value.
>
>Although, it is possible on API level to have hierarchical structure
>of lists, I do not think that it is possible to model
>this using our data model and so, this will never happens.

Hopefully it won't.

>> What if instead of putting the notion of a property value list at
>> the value level, we left it at the property level, yet added
>> something similar to what you guys have suggested like this (I left out the update op's for now):
>>  
>> Interface IProperty {
>>  URI getType();
>>  Iterator getValues(); // returns an Iterator of one or more IPropertyValue instances.
>>  boolean isSingleValued(); // true if can cast to ISingleValueProperty
>> }
>
>When isSingleValued return true does it mean that I can't have more
>then one value or this particular instance just contains only one?
 
I like the semantics you prescribed.  Meaning, it follows the model, not this particular instance.

>> Interface ISingleValueProperty extends IProperty {
>>  IPropertyValue getValue();
>> }
>>  
>>  
>> This lets us leave IPropertyValue unchanged.  Note that
>> IProperty.getValues() still works when there is only a single value
>> -- but in that case it only has a single element.  Anyway, I think
>> this addresses the original problem statement which is that
>> IProperty.getValue() is ambiguous in its meaning.
>
>Ok, I agree that it could be another option but it will affect
>attribute's definition and we'll need to define something like
>ISingleValuedAttribute as well.
>As for me it is not right thing to do.

See above -- isSingleValued would only be true when the model dictates that the cardinality is 1.  When an attribute is allowed to hold multiple values, but happens to only hold a single value, callers will still have to call getValues and enumerate the (single) value.

Jim