[occi-wg] Revisiting Fat Links
michael.behrens at r2ad.com
Tue Aug 17 21:16:27 CDT 2010
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
>> Where one aspect of confusion or debate arises with your initial
>> 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
>> 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
(571) 594-3008 (cell)
(703) 714-0442 (land)
More information about the occi-wg