[occi-wg] Revisiting Fat Links

[Michael Behrens]

In trying to digest all the link traffic (great stuff by the way) - can 
we perhaps assume that any POST or PUT operation would never destroy 
links.  Then, for removal of links, perhaps a separate DELETE call to 
the resource that specifies (somehow) only the deletion of the listed 
links is removed?  Sorry if I've missed a comment about that already.

Ralf Nyren wrote:
> 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
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
>    


-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell)
(703) 714-0442 (land)