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

OK thanks Rotan, I think I am beginning to see the picture more clearly
now. I am worried that it's going to be confusing to people who are
Aspect-unaware either way round. So we are sort of between the devil and
the deep blue sea. 

However, taking Rotan's idea of withApect forward, how about this:
PropertyName as previously defined remains part of the API, the
relationship between PropertyName and SimplePropertyRef is undefined and
PropertyName gains a factory method

SimplePropertyRef newPropertyRef(String aspect);

Then example code might look like:

static final PropertyName VENDOR = new PropertyName("vendor");

...

String deviceVendor = getPropertyValue(Evidence e,
VENDOR.newPropertyRef("device"));

UNSPECIFIED_ASEPCT is not required, NULL_ASPECT is retained.

Or something.

Anwyay, I think I would feel a lot happier thinking that the
relationship between PropertyName and SimplePropertyRef is not fixed in
the interface, which was my main problem before. It's up to
implementations to define an inheritance relationship if they want to. 

At risk of gilding the lily I have a sneaking suspicion that the use
case for having a separate PropertyName class would not be completely
fulfilled unless there were another method on SimplePropertyRef of

PropertyName newPropertyName();

But since it is not my use case I can't comment.

Jo




> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org]
On
> Behalf Of Rotan Hanrahan
> Sent: 25 February 2008 09:29
> To: public-ddwg@w3.org
> Subject: 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:59:13 UTC