[tigerstripe-dev] Re: Unique annotations?

[Andrey Platov <andrey@xxxxxxxxx>]

Hi Eric,

Sounds like a good addition to set of managing EMF annotations. Also I'd like to point that this looks like a special case of more general constraints mechanism we need to work out for specifying which types of annotations can be bounded to which objects (e.g. stereotype can be applied to class only), etc

So in simplest case (if we're not going to employ OCL or other generic mechanism for constraints at the moment), I'd like to propose to enrich "unique" EMF annotation with target type specification. Something like "bind = tigerstripe/Entity; unique = false" to allow to specify cardinality on per-type basis.

The problem I see here is Annotation concept lacks of Annotable object type information, and I'm afraid we may need it in near future... From first look there are following possibilities to add typeinfo:

1) Annotable namespace providers (Java, TS, Resource) may enforce type information in the URI encoding, so clients will be able to use it if needed, for example "java:method:/Foo/..."

2) Extend IAnnotable interface with String getType method. Semantic of the type will be target-domain specific. So for example objects from Java namespace may specify type of Java element here ("Java Class", "Java Method", etc). 

Both 1-2 is nearly the same. What I do not like for this approach is poorness of such trivial "type system". At least lack of generalization would result in inablilty to attach annotations to base types (e.g. JavaElement) and so on...

3) (1) & (2) triggered elegant (I think :)) change to current annotable model: what if we'll adapt annotable objects to EObject instead of IAnnotable. As a result we will have URI (from EMF), 'annotable object'-related information as a part of EObject (if needed), and Type information... 

At the moment I'm not sure about amount of complexity this will add to the framework and some providers (Resource/Java Element), but for objects which are already stored in EMF resources (hopefully future Tigerstripe models after switched from POJOs) this approach may even simplify provider implementation: adapters will return EMF objects as is.

Evolving this idea further and with dynamic features of EMF we may try to use multiple inheritance and expose Compilation Unit as an object of type derived both from Resource and CompilationUnit -> Java Element. This looks as one of possible approaches to resolve ambiguous situation we have now with multiple providers (and turning Java provider off not to expose object as Java annotable object).

Please share your thoughts. In the meantime Yuri is going to provide simple "unique" annotation as suggested. I'd be happy to play with approach (3) and share PoC if succeed.

Kind Regards,
Andrey


----- Forwarded Message -----
From: Eric Dillon <erdillon@xxxxxxxxx>
To: Yuri Strot <yuri@xxxxxxxxx>
Cc: Tigerstripe Developers <tigerstripe-dev@xxxxxxxxxxx>
Sent: Fri, 2 May 2008 22:52:36 +0700 (NOVST)
Subject: Unique annotations?

HI Yuri,

As we consider the use of EMF annotations in the definition of the
Annotation¹s .ecore files, we should consider allowing for annotations to be
unique per URI.

Typically, Stereotypes in UML and Annotations in Java are uniquely applied
(i.e. You cannot have 2 annotations of the same type on a single URI).

I think we should make this the default behavior (³unique=true²) but allow
users to bypass it by using an annotation (unique=false).

What do you think?
Eric