RE: New Draft API Document 1e - and discussion of PropertyName and a couple of other things

I agree with Jo that NULL_ASPECT and UNSPECIFIED_ASPECT have different
semantics. The only difference I see in the behaviours of the two
proposed behaviours is that the latter does a check to see if the aspect
is already UNSPECIFIED_ASPECT, whereas the former overrides the aspect
regardless. Thinking in terms of usage, I see no problem with being able
to override the aspect of any SimplePropertyRef instance. It should make
no difference whether the construction of the property instance was done
in an aspect-aware environment or not. I agree than an exception should
be flagged whenever the override produces an unsupported or unknown
combination of aspect/property. Consequently, I would lean towards the
first of Jo's definitions for the method.


Regarding the method itself...


> I believe we have a Simple API that is both simple and extensible. It
> also provides opportunities for compile time and run time
optimisations.
> Finally, regarding the issue of PropertyName, I believe the concept of
a
> ProeprtyName (i.e. QualifiedProperty) can be supported if we have a
> NULL_ASPECT constant and we add the following query method:
>    getPropertyValue(Evidence e, String aspect, SimplePropertyRef spr)

I should add that in an OO implementation of this API one could inherit
from the SimplePropertyRef interface and thus provide a class that
facilitates an override of the internal access attribute, and therefore
permitting:
   getPropertyValue(Evidence e, MyCustomSimplePropertyRef spr)

One might look on this as a wrapper, and it may even provide the
override temporarily via a convenience method and thus be used in the
existing API as follows:
   myValue =
getPropertyValue(evidence,myCustomSpr.withAspect("SomeAspect"));

[ The withAspect() method is an implementation-specific method of my
implementation-specific class called MyCustomSimplePropertyRef that in
turn inherits from SimplePropertyRef. ]

The problem I have with this approach is that the general concept of a
property name as a qualified term of a vocabulary is no longer
represented in the official API, and there is now the notion of
interface inheritance/override that leans towards particular
implementation strategies. Interoperability is compromised. From an
individual implementation perspective it would work, but in terms of a
possible future advanced API where property name and aspect name are
classes in their own rights, I prefer my original proposal. We would
have an evolution as follows:
   getPropertyValue(Evidence e, String aspect, SimplePropertyRef
property)
to
   getPropertyValue(Evidence e, String aspect, QualifiedProperty
property)
to
   getPropertyValue(Evidence e, QualifiedAspect aspect,
QualifiedProperty property)
to
   getPropertyValue(Evidence e, PropertyRef property)

Only the first would be available in the Simple API. In the case of the
last signature, this would be an example of the advanced Property
Reference (compared to the SimplePropertyRef), which is the 4-parameter
unambiguous reference to a context property. Server-side solutions
dealing with a particular subset of properties for a wide range of
contexts can achieve valuable optimisations by having such a class
available.



Of course, if the group decides that the PropertyName
(QualifiedProperty) concept should be captured via class inheritance
without changing the interface as currently defined, using the approach
outlined earlier, despite this being an implementation approach rather
than being expressly defined in the API itself, then I can accept such a
decision. The optimisations I previously indicated can still be achieved
in OO languages using this approach, and the method signatures mentioned
above would be moved to the advanced API.



---Rotan

Received on Monday, 25 February 2008 09:28:48 UTC