Re: [tigerstripe-dev] Re: Unique annotations?

[Andrey Platov <andrey@xxxxxxxxx>]

Hi Eric,

Yes I'm going to try to expose IResource as an EObject as you suggested.

As for resolving provider conflicts my thoughts like following:

* Problem description (as I understand it)

Consider we have some POJO implemening IAdaptable interface, which we want to adapt to IAnnotable. Right now only one "provider" wins, so in case JavaElementProvider wins over TigerstripeElementProvider it will manage URI and other stuff without any Tigerstripe knowledge. This do not looks good, since we shall give a chance to all the providers to participate in this process. (Right now the process is about mapping URIs to POJOs and vice-versa, but in future it may involve other things).

Another bad thing is we're loosing actual object identity, for example let's consider some Java Type (JDT), which is TigerstripeElement. At the same time *this* object is also JavaElement. Each existing provider will use own schema to identify the object, which is not bad. Bad thing that in current model both URIs "points" to different objects, which is not true. So query for all object's annotations using Tigerstripe scheme will not return annotations provided with Java scheme because we think that objects are different in current model.

* Proposed solution

This is only thoughts extending "adapting to EObject" idea. I'm not sure how correct, realistic, and/or useful it may be:

Let's look at some POJO, which implements IAdaptable. Let's assume this POJO can be adapted to IResource, IJavaElement, and ITSElement. Tigerstripe Annotations Framework is responsible for adapting IAdaptable to EObject (or a class derived from EObject like EAnnotableObject). Adaptation process is like following:

1) Framework ask providers about types they're responsible for. For our case this will be IResource, IJavaElement, and ITSElement.
2) Framework check is POJO (IAdaptable) adapts to types returned in step (1)
3) Framework construct synthetic EMF class, which is derived from EAnnotableResource, EAnnoitableJavaElement, and EAnnotableTSElement (multiple inheritance, assuming we found that POJO can be adapted to IResource, IJavaElement, and ITSElement in step 2). 
4) Framework instantiate object of the class (3), and pass it to each of providers found in step (2) to initialize object content with provider-specific data.

Framework clients will work with EAnnotableObjects instead of URIs and all provider stuff will be hidden from clients, so Framework can be very flexible with managing object identity and understand which annotations actually bound to "this" object.

That's some draft idea, please share your thoughts.

Kind Regards,
Andrey

----- Original Message -----
From: "Eric Dillon" <erdillon@xxxxxxxxx>
To: "Tigerstripe developers list" <tigerstripe-dev@xxxxxxxxxxx>, "Andrey Platov" <andrey@xxxxxxxxx>
Sent: Tuesday, May 6, 2008 1:50:02 AM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [tigerstripe-dev] Re: Unique annotations?

Hi Andrey,

So, first of all, yes, let's do a "quick" change to support the "unique"
annotation.

Now, I do like adapting annotable objects to Eobject instead of Iannotable.
It seems we've outgrown Iannotable already, so we would probably just keep
changing it. So an early move now makes a lot of sense.

I am not quite sure how much work this would actually trigger though... So a
bit of prototyping is definitely a good idea. Maybe see what this does with
one of the providers? (Iresource?).

I am not sure I'm following you on your comment on how this would help solve
current conflicts with Java Provider and Tigerstripe provider though :-)?
Could you elaborate a bit on that?

Thanks,
Eric


On 5/5/08 2:31 AM, "Andrey Platov" <andrey@xxxxxxxxx> wrote:

> 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
> 
> 
> _______________________________________________
> tigerstripe-dev mailing list
> tigerstripe-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev