[occi-wg] Revisiting Fat Links

[Ralf Nyren]

On Tue, 17 Aug 2010 19:10:43 +0200, Edmonds, AndrewX  
<andrewx.edmonds at intel.com> wrote:

> You'll probably want to bash me, Ralf, but I have always favoured your
> initial suggestion ("Another proposal") :-). Main reason is that without  
> a second call, as in the case with this new proposal, I can get the type
> information of both the link and target resource and _also_ the  
> attributes of that link, in the examples shown, a specialized Link.

I agree, it is nice to have all information in one request. Those things  
among others are what I like with the simple approach.

Two main reasons I would favor the Fat Links approach instead though:
  - Update of Links for a Resource is a problem in the simple approach.  
Links become a special case and you must always supply all Links in a PUT  
request. It is indeed more clean to have PUT only update attributes and  
nothing else.
  - You can only have _one_ Category associated with a Link, i.e. no  
composite types.

I have added a sample UML diagram of the Core Model supporting Fat Links  
to the Link wiki page. I included the resource (lower case 'r') concept in  
the diagram to illustrate the distinction between a resource and a  
Resource.

> Where one aspect of confusion or debate arises with your initial  
> suggestion
> is the idea that if a model entity has a Category associated with it, the
> entity must then be a Resource. I don't quite see it this way. Rather, I  
> see
> the addition of a Category to any (R)resource (except Category itself,
> that's non-sensical) as a means of signaling type information.

Hmm... yes I do also see the assignment of Categories as signaling type  
information. It makes things flexible and extensible in a well defined way.

Might be useful to draw an UML diagram of the simple approach just to  
clarify things.

regards, Ralf