[occi-wg] Yet Another (non)Link Proposal

[Csom Gyula]

Hi,
I think using different terms for the different layers (entity model vs. http/html representation)
is a practical thing:) There's one point though I couldn't catch in the proposal. The following
rule is not intuitive for me:

"Rule 2: One occi element is represented by one Reference."

What does 'one' and 'represent' mean here?

* By the classical term a reference is made from one entity to another hence a reference
  doesn't represent entites rather relationships between them.
* Also by the classical term different references could be given to the same entity. That
  is supported by roles which specifie the entity roles within the relationship. Currently
  the OCCI entity model is simple enough so that Resources specify their roles. However
  when thinking of extension this might not be true... the same entity could play different
  roles...

I might missed something..., so could you please clarify the above rule?:)

Cheers,
Gyula

________________________________
Feladó: occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org> [occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org>] ; meghatalmazó: Gary Mazz [garymazzaferro at gmail.com<mailto:garymazzaferro at gmail.com>]
Küldve: 2010. augusztus 17. 12:04
Címzett: Edmonds, AndrewX
Másolatot kap: occi-wg at ogf.org<mailto:occi-wg at ogf.org>
Tárgy: [occi-wg] Yet Another (non)Link Proposal

Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1].

I think we need to revisit the reasons why we have linking in the first place.

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  implementations.
3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones.

This was all  decided prior to the introduction of the occi http header implementation.

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.

The Proposal:

Name Changes:
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.

New Definitions:

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.

Logic Rules:
Reference:
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 occi extensions.
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:
TBD

I'll follow up with examples if there is interest

cheers,
gary




[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link