[occi-wg] Yet Another (non)Link Proposal
garymazzaferro at gmail.com
Tue Aug 17 05:04:24 CDT 2010
Good work, Andy's write up seems to capture many of our issues, from
current linking discussions in .
I think we need to revisit the reasons why we have linking in the first
1) Initially we knew we weren't able to capture all aspects of cloud
architectures and our preliminary work would need to be extensible. We
needed a way to integrate changes into occi.
2) We also realized we would need to integrate vendor proprietary
3) Additionally, we decided that we need to breakup the occi represented
resources into small parts for easy transport and support devices like
This was all decided prior to the introduction of the occi http header
During this process, we decided to use linking, again prior to headers,
to represent both References between resources and Associations between
representations out of occi's scope.
This approach intuitively combined issues surrounding data context and
data data description into an predetermined implementation as a 'link'.
I think link we need to further define the term as 'Link' which refers
to OCCI both type of occi associations and the 'link' for the
implementation used in headers and HTML/RDFa.
I would prefer to see 'Link' to be renamed to "Reference' and
'Association' where appropriate in the occi specification. It would
help limit confusion on the part of implementors and contributors.
*Reference: *A portion of the occi logical model representing an occi
configuration indicating a binding relationship between occi entities.
*Association: *A portion of the occi logical model representing an occi
configuration indicating a bind relationship between occi entities and
systems outside the scope of occi.
*Rule 1: *All References are part of the occi name space.
*Rule 2: *One occi element is represented by one Reference.
* Association: *
*Rule 1: *Associations are used to extend occi with system entities
outside of occi's scope. Interoperability cannot be guaranteed across
*Rule 2: *Although indented for external systems, occi entities may be a
defined in Associations. This would help ensure backward compatibility
if an extension is adopted and becomes part of the occi name space. *
Rule 3:* Detailed information about the occi extension is only
available after the extension is loaded be the extension consumer.
*Rule 4:* The URI is mandatory for an Association.
*Rule 5:* An occi Title attribute is mandatory for an Association.
*Rule 6:* An occi Summary attribute is optional for an Association.
*Header Implementation Details:*
Remove the Link field from the header definition and replace it with the
appropriate Reference and Association header field.
*Header Implementation Benefit:*
1) Reduces Link attribute parsing complexity
2) Reduces provides better clarity of the information's purpose
HTML5/RDFa Implementation Details:*
I'll follow up with examples if there is interest
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the occi-wg