Monica J. Martin wrote:
> Farrukh Najmi wrote:
>
>> Nikola Stojanovic wrote:
>>
>>> <Farrukh>
>>>
>>> > My proposal is to add a new logical id attribute to the set of
>>> > registry versioning attributes, and otherwise improving ObjectRef to
>>> > allow selection of a particular version of an object.
>>>
>>> +1 on being able to reference a logical object in a version independent
>>> manner.
>>>
>>> This is exactly what the lid attribute is for in the versioning spec
>>> being added to version 2.6.
>>>
>>> I think that the use case you raise can (and should) be addressed very
>>> easily by extending the ObjectRef class to have a choice of:
>>>
>>> a) a static "hard-wired" reference to a specific version of a specific
>>> object (current capability)
>>>
>>> b) a dynamic "late-binding" reference to a logical object which is
>>> determined at run-time (de-refence time).
>>> I could see this being done via a second attribute named "dynamic".
>>> When
>>> dynamic is false (default) the registry
>>> assumes that the id attribute references the referenced object. When
>>> dynamic is true, the registry assumes that the id attribute MUST be
>>> to a
>>> stored query that dynamically determines the referenced objects.
>>>
>>> This is a very powerful concept. Thanks Matt for seeding this idea. I
>>> hope we can discuss this over email prior to next telecon. Thanks.
>>>
>>> </Farrukh>
>>>
>>> I also see this as a very valid and a needed Use Case and that
>>> LateBinding approach is interesting. However, I think that we have a
>>> solution that doesn't need LateBinding. It would be something like
>>> this:
>>>
>>> - subscribe to relevant event(s); in this case it is Update of the
>>> objects that are members of the package.
>>>
>>> - implement "Web Service" that is going to be triggered by the above
>>> event and that is going to adjust relevant object references.
>>>
>>> As one looks at the context of the two, LateBinding would incur
>>> lookups whenever object references need to be resolved and
>>> EventNotification will be invoked when relevant events happen. One
>>> would assume that occurrence frequency of the first is higher then
>>> of the second.
>>>
>> Interesting point that Matt's use case is already addressable via the
>> Event Notification feature. So as I understand your suggestion the
>> reference that needs to always be to the latest version of an object
>> could be updated from one version of an object to another by a web
>> service that is an Event Notification Listener service that gets
>> invoked whenever a new version of the object is created.
>>
>> I agree with the point that your alternative is more efficient than
>> late binding Object Reference approach and requires no additional work.
>>
>> I now reconsider the idea of doing late binding of object references
>> now. Instead we should keep it in our future candidate work items and
>> rely on your Event Notification based approach to address Matt's use
>> case for now.
>>
>> Any one disagree with this proposed resolution?
>
>
> mm1: I don't disagree but wish to ask a question that applies to not
> only late binding but the event notification approach where object
> references are updated. In ebBP, we found that LateBinding is not a
> black-white situation. For example, when we started to talk about
> conditional attributes such as time to perform, we determined that
> LateBinding could have a duration, may or may not be allowed, and
> constraints could be applied (when changed, if changed where does the
> value come from, etc). This raises questions:
>
> * Can you update the object references to the latest version?
Yes. For the latest object at the time of update.
> * Are there conditions that apply? Are all objects in the package
> updated?
Lets focus on the simpler case of Object A wishing to reference latest
version of Object B.
The answer is that:
-If late binding is used then the object A updated when the object B is
updated since the late binding ObjectRef stays unchanged.
-If event notification is used to update the reference in Object A then
Object A will be updated (and likely new version created) when Object B
is updated.
This is a significant difference between the two solutions.
> * Does the owner define the duration, parameters or constraints of
> when they can be changed?
Object B can change any time its owner (or delegate) updates it. Object
A's owner (or delegate) controls the criterea for the dynamic reference
but has no control over when Object B is updated.
>
> As well, in our work on time to perform, we found the conditional
> aspects to be best expressed as an element not an attribute.
In the late binding approach the conditional aspects are expressed in a
stored query so an attribute with the query's id is sufficient.
Thanks for the though provoking questions.
--
Regards,
Farrukh
