Update of Link Header Rendering
I have updated the Link wiki page [1] with the latest proposal on Link Header rendering with respect to the latest Core Model. The proposal is based on the latest discussions. Comments welcome. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
Good work! Appreciated Ralf! :-) Andy andy.edmonds.be On Wed, Sep 1, 2010 at 11:01, Ralf Nyren <ralf@nyren.net> wrote:
I have updated the Link wiki page [1] with the latest proposal on Link Header rendering with respect to the latest Core Model.
The proposal is based on the latest discussions. Comments welcome.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Good read!.....good job Ralf. Some comments: 1) Wikipedia reference to REST...for the spec, is there a normative publication that can be used? Perhaps http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 2) What should a client do with links that do not present a category? For instance, if a storage category is specified, clients could group it with other storage elements, etc. Perhaps implementers SHOULD provide categories if they are known. Thanks. Ralf Nyren wrote:
I have updated the Link wiki page [1] with the latest proposal on Link Header rendering with respect to the latest Core Model.
The proposal is based on the latest discussions. Comments welcome.
regards, Ralf
[1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Thu, 02 Sep 2010 04:15:08 +0200, Michael Behrens <michael.behrens@r2ad.com> wrote:
1) Wikipedia reference to REST...for the spec, is there a normative publication that can be used? Perhaps http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
You are right, the wikipedia reference should be replace/removed when this information is moved into the real specification.
2) What should a client do with links that do not present a category? For instance, if a storage category is specified, clients could group it with other storage elements, etc. Perhaps implementers SHOULD provide categories if they are known.
A Link is always associated with at least one Category, i.e. http://schemas.ogf.org/occi/core#link. The same is true for Resources as well. If you are referring to the "Minimal HTTP Link Header rendering" of Resources, where only the Link target is provided, I would say a client has to issue a separate GET request for the target to determine the type (set of categories). Maybe the minimal rendering is not very useful, should we remove it and always require target type information in link rendering? If so, with the case of multiple categories, which categories MUST be displayed and which can be left out (if any)? regards, Ralf
Comments in line Ralf Nyren wrote:
On Thu, 02 Sep 2010 04:15:08 +0200, Michael Behrens <michael.behrens@r2ad.com> wrote:
1) Wikipedia reference to REST...for the spec, is there a normative publication that can be used? Perhaps http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
You are right, the wikipedia reference should be replace/removed when this information is moved into the real specification.
I agree, all references to wikipedia should be removed (something I've attempted in the past and met with resistance) . Wikipedia references are unstable and some of marginal quality. We should move to reference the "real" specification along with specifying version and date.
2) What should a client do with links that do not present a category? For instance, if a storage category is specified, clients could group it with other storage elements, etc. Perhaps implementers SHOULD provide categories if they are known.
A Link is always associated with at least one Category, i.e. http://schemas.ogf.org/occi/core#link. The same is true for Resources as well.
If you are referring to the "Minimal HTTP Link Header rendering" of Resources, where only the Link target is provided, I would say a client has to issue a separate GET request for the target to determine the type (set of categories).
This is correct.. The client would have to issue individual get requests for each occi resource target. It will be much more interesting with links to external systems, especially non-http implementations. I'm, still mulling over the credential comments from Wed, 9.01.2010 meeting.
Maybe the minimal rendering is not very useful, should we remove it and always require target type information in link rendering? If so, with the case of multiple categories, which categories MUST be displayed and which can be left out (if any)?
IMO, the minimal rendering has never been useful in terms of usability. Little work has been done accessing a level of interoperability to define a "minimal rendering". The "minimal rendering" may conflict with current definitions of mandatory attributes. I believe the "minimal rendering" is redundant should be removed from these OCCI specifications. The "minimal rendering" is already defined by the specification's mandatory definitions.
regards, Ralf
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (4)
-
Andy Edmonds -
Gary Mazz -
Michael Behrens -
Ralf Nyren