[occi-wg] Syntax for attributes on links

Sam Johnston samj at samj.net
Thu May 7 10:52:48 CDT 2009


Sorry about the double vision before... went trough a tunnel on the
train so it was sent twice. Comments inline...

On 5/7/09, Roger Menday <roger.menday at uk.fujitsu.com> wrote:
>
>
> Hi all,
>
>> The original example was:
>>
>>> <link href="urn:uuid:4cc8cf62-69a4-4650-9e8c-7d4c516884df"
>>>      rel="http://purl.org/occi/storage#device" title="Hard Drive"/>
>>
>> And as I said before, we also need a device identifier at which to
>> connect
>> the storage, making it something like:
>>
>>> <link type="ide:0:0" href="urn:uuid:4cc8cf62-69a4-4650-9e8c-7d4c516884df
>>> "
>>>      rel="http://purl.org/occi/storage#device" title="Hard Drive"/>
>
> Shouldn't these href's be HTTP URIs so I know where to go to find out
> some more about the storage device (in this case) ? And then, visiting
> the home of the storage device, I get some more (typed) links I can
> follow to other other things the storage is related to ... i.e.
> navigating the graph.

Good question and good to see people payong close attentipn. We know
we can find the resources at the root of the entry point so I'm more
inclined to use the href as an internal pointer than confuse things
when there are multiple servers potentially talking about the same
resources. we can use 3xx redirects as a kind of resolution system if
need be too.

Sam on iPhone

> (?)
>
> Roger
>
>>
>> which mapped to JSON as:
>>
>>> "link":[
>>>  {
>>>    "type":"ide:0:0"
>>>    "rel":"http://purl.org/occi/storage#device",
>>>    "href":"urn:uuid:4cc8cf62-69a4-4650-9e8c-7d4c516884df",
>>>    "title":"Hard Drive"
>>>  }
>>> ]
>>
>>
>> I still believe that the "link" here is a figment of conversion from
>> the
>> Atom XML format. To write this in something more like native JSON,
>> I'd go
>> with:
>>
>> "ide:0:0": {
>>  "href":"urn:uuid:4cc8cf62-69a4-4650-9e8c-7d4c516884df",
>>  "title":"Hard Drive"
>> }
>>
>> since the device identifier is unique for the VM, and clearly
>> specifies this
>> as a place where storage is being attached.
>>
>>
>>
>> In text format, I'd flatten this data structure as:
>>
>> ide:0:0|href|4cc8cf62-69a4-4650-9e8c-7d4c516884df
>> ide:0:0|title|Hard Drive
>>
>> or even just:
>>
>> ide:0:0|4cc8cf62-69a4-4650-9e8c-7d4c516884df
>> ide:0:0|title|Hard Drive
>>
>> Rather than the original:
>>
>> link|ide:0:0|http://purl.org/occi/storage#device|Hard
>> Drive|urn:uuid:4cc8cf62-69a4-4650-9e8c-7d4c516884df
>>
>>
>> This is rather cleaner in terms of not having to know what all the
>> possible
>> attributes might be, and where they appear in the |-deliminated list.
>>
>> Cheers,
>>
>> Richard.
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> Roger Menday (PhD)
> <roger.menday at uk.fujitsu.com>
>
> Senior Researcher, Fujitsu Laboratories of Europe Limited
> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
> Tel: +44 (0) 208 606 4534
>
>
> ______________________________________________________________________
>
>  Fujitsu Laboratories of Europe Limited
>  Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
>  Registered No. 4153469
>
>  This e-mail and any attachments are for the sole use of addressee(s) and
>  may contain information which is privileged and confidential. Unauthorised
>  use or copying for disclosure is strictly prohibited. The fact that this
>  e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
>  not guarantee that it has not been intercepted or amended nor that it is
>  virus-free.
>



More information about the occi-wg mailing list