[occi-wg] JSON Rendering

Gary Mazz garymazzaferro at gmail.com
Thu May 3 06:12:56 EDT 2012


I'll take a shot at it later today. At least the ABNF

-gary

On 5/3/2012 3:30 AM, Ralf Nyren wrote:
> On Thu, 03 May 2012 02:24:15 -0600, Gary Mazz<garymazzaferro at gmail.com>
> wrote:
>> I agree with separate sections.. I think.. I need to see a simple
> example..
>
> \section{OCCI Kind}
>
> {
>    "scheme": *string*,
>    "term": *string*",
>    ...
> }
>
> \section{OCCI Link}
>
> {
>    "kind": *string*,
>    "source": *string*,
>    "target": *string*,
>    "attributes": *object*,
>    ...
> }
>
>
>> The resource, link and category are 3 different views and need to be
>> defined in detail.
> +2 for detailed definition!
>
> /Ralf
>
>> -gary
>>
>> On 5/3/2012 2:10 AM, Ralf Nyren wrote:
>>> Looks like Florian commited a work-in-progress version. There are still
>>> content from the previous version which has not been updated. The media
>>> type of the discovery interface serialization for example.
>>>
>>> I would find it easier to read if we described the serialization of
> each
>>> OCCI type (Kind, Mixin, Resource, Link, Action) in a separate
> subsection
>>> for each one.
>>>
>>> Then a final section could described the actual JSON format sent on the
>>> wire which is a combination of the serialization of the OCCI types. It
>>> would follow the same pattern as how the HTTP doc uses ABNF to describe
>>> the
>>> individual headers and then shows how they are put together.
>>>
>>> For the JSON example structures it would be nice to drop the example
>>> content and just write the JSON type in italics. Instead of:
>>>    "title": "My example title",
>>> just specify:
>>>    "title": *string*
>>> (where *xxx* means italic)
>>>
>>> This way it would be very clear what part of the JSON is static
> keywords
>>> and what is variable content.
>>>
>>> regards, Ralf
>>>
>>> On Wed, 02 May 2012 23:25:08 -0400, Michael Behrens
>>> <michael.behrens at r2ad.com>   wrote:
>>>> In reviewing the latest sent out...here a few nit-noids...which Gary
> may
>>>> have already corrected....
>>>>
>>>> -    In section 5.1, I see two JSON examples....looks like a second
> one
>>>> starts on line 113.  Perhaps a description of the second one would
> help
>>>> separate the two. Or am I reading it
>>>> wrong?
>>>> -    in that JSON, there are some extra spaces showing up after "http:
>>> ".
>>>> Lines 88, 90, 91, 97
>>>> -    Line 106, missing comma at end of line (I think)
>>>> -    Looks like the JSON in section 5.2 is split up - perhaps the
> tables
>>>> should follow the JSON - presumably.
>>>>
>>>> I like the usage of the pattern attribute...that will help with client
>>>> side validation :)
>>>>
>>>> - Michael B.
>>>>
>>>> _______________________________________________
>>>> occi-wg mailing list
>>>> occi-wg at ogf.org
>>>> https://www.ogf.org/mailman/listinfo/occi-wg



More information about the occi-wg mailing list