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@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) (703) 714-0442 (land)