Hi!:) 1) Do you mean the following diagram: http://forge.ogf.org/sf/sfmain/do/downloadAttachment/projects.occi-wg/wiki/C... Well, yes and maybe not:) The above diagram specifiies the source - link relation as an UML composition, hence deleting a source triggers deleting the link, as well. However it specifiies the target - link relation as a simple binary association which might not have builtin life cycle semantics... 2) Could you please give some more details? Especially do you mean a client-driven solution? Ie. should the client create both the link and the reverse link in this solution? Or?:) 3) Yep:) 4) So a provider can define specific Link categories... ie. within the scheme "http://example.com/occi/link#" Then the category draft should be updated since it tells that even providers can not extend builtin schemes: "Categories schemes can be extended by providers and users by defining there own (with different mutability) scheme. Those MUST be in a different namespace then those described in the OCCI specification." Or did I miss something?:) Gyula ________________________________________ Feladó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. szeptember 1. 18:58 Címzett: Csom Gyula; occi-wg@ogf.org Tárgy: RE: Link specification Hey Gyula, 1) How about "An OCCI server MUST delete associated Links after deleting their associated Resource"? This is implicit in Alexander's UML diagram showing that a Resource is composed of Links. Composition indicates that the owning class manages their lifecycle, unless a Link is explicitly removed. 2) If reverse links are required then this can be implemented as a custom/domain-specific link type that subclasses Link 3) Currently the only categories for infrastructure are Compute, Network, Storage. Currently, for my own purposes, I can use Link to associate each of these entities but I cannot associate additional attributes (e.g. IP, macaddress etc) with Link so I will subclass Link and make a domain specific Link (e.g. StorageLink, NetworkLink). 4) I think for now only providers can introduce new categories for the purpose of Resource/Link extension. It will be a useful and valuable addition whereby users can create their own Categories for the sole purpose of organization, in the same vein/style as tags. Andy -----Original Message----- From: Csom Gyula [mailto:csom@interface.hu] Sent: Wednesday, September 01, 2010 5:32 PM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: RE: Link specification Hi, some notes: [1] action on resource delete The working draft specifies the behaviour of deleting links (ie. "An OCCI server MUST NOT delete the associated Resources upon receiving a client DELETE request for a Link."). It's counter part should be also defined, ie. the behaviour of deletion of associated resources. Should the server automatically delete links, as well (CASCADE DELETE behaviour)? Or should it prevent from deleting a resource, if there's a link pointing to it? Or should it be configurable either per link instance or link type? [2] reverse links It might be useful to provide a so called 'reverse link' service, too. Ie. one should be able to query the links that points to a specific resource. Or formally: reverse_links(r) := {link | link.target = r}. In order to? Well, querying reverse links is a common task. For instance: to see what computes belong to a given network... Why... since someone can list all links then filter out the unwanted ones? Within a large system this could be a slow and resource-intensive operation. Meanwhile the cloud system could work from its internal index to filter the necessarry links which is much more faster. This might be modeled as either a new attribute (ie. adding reverse_links to Resource or kinda) or as a special query service (GET /reverse_links/$resource_id HTTP/1.0 or such). [3] built in link types The working draft enables subtyping links: "An OCCI server MAY enforce additional attributes at creation time if the link has been subtyped using additional categories." Sample from the wiki: Category: link; scheme="http://schemas.ogf.org/occi/core#", disk_drive; scheme="http://example.com/occi/link#" Attribute: occi.link.source="/compute/vm01", occi.link.target="/storage/disk03", com.example.drive.interface="ide" I guess built in link categories should be defined for the Infrastructure model (ie. disk, nic and maybe console):) This topic relates to the following one as well: [4] link extensions? It is not clear whether someone could use her own, specific links. The category spec states: "Categories schemes can be extended by providers and users by defining there own (with different mutability) scheme. Those MUST be in a different namespace then those described in the OCCI specification." Hence someone can introduce new Categories within new schemes. But can she introduce new categories within the builtin OCCI namespaces? In order to use user defined links this is mandatory since domain specific links are specified by categories of Link type: "A set of associated attributes defined by the categories of the Link type." Cheers, Gyula ________________________________________ Feladó: Csom Gyula Küldve: 2010. szeptember 1. 17:35 Címzett: Edmonds, AndrewX; occi-wg@ogf.org Tárgy: RE: Link specification Have just ran through the wiki page, though need more time to understand the details:) one basic question came into my mind. In most use cases 'bilateral' links are enough ________________________________________ Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ; meghatalmazó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. szeptember 1. 17:01 Címzett: occi-wg@ogf.org Tárgy: [occi-wg] Link specification Just a reminder - from our confcall today, the deadline for any further changes that will impact significantly the link specification [1] is next Wednesday August 8th. Get reading! :-) Andy [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link