[occi-wg] JSON Rendering proposal, rev 2

[Ralf Nyren]

On Wed, 29 Feb 2012 12:23:25 +0100, Feldhaus, Florian  
<florian.feldhaus at gwdg.de> wrote:

> Hi Ralf,

Hi Florian and thanks for the update!

> at todays Plugfest Jamie Marshall, David Slik, Houssem Medhioub, Andy  
> Edmonds, Thijs Metsch and I discussed about the JSON rendering. Your  
> proposal was well received. For the entity rendering there was the  
> suggestion to make it more intuitively usable. The main difference is,  
> that the attributes should be directly accessible by name structure.  
> e.g. make it possible to do the following commands in your favorite  
> programming language:
> var occi = GET /compute/123
> occi.kind
> occi.compute.cores
> occi.my_mixin.my_attribute

Yes, would be really nice if we could get something like that to work.

> The only thing we have to prohibit then is, that a single service  
> provider has mixins from different domains with the same term and  
> attributes.

This is the hard part. I cannot see a way to do this without changing  
fundamental parts of OCCI Core :-\

Today we have 2 name-spaces where conflicts could arise:
1. Entity sub-types
2. Attributes

1:
For entity sub-types we have a categorisation schema (as part of the  
Kind/Mixin identifier) which allows arbitrary naming within the schema.  
E.g. you could have 100 providers interacting and sharing resources which  
each of them have their own "compute" type (term="compute"). It works  
since they are forced to have unique categorisation schemas.

Let's assume for a minute that we would drop the categorisation schema and  
only have the "term" left. We prohibit anyone from using resource, link,  
compute, storage, etc since we have defined them already. Later on we want  
to add a new infrastructure type but since it was not forbidden from the  
beginning adding a new type could break interoperability. So the system  
falls apart without the categorisation schema.

2:
For attributes we have another name-space saying that anything starting  
with "occi." is reserved and any custom attributes MUST start with the  
reversed domain name of each provider, e.g. "com.example.".

Again, if we drop the attribute prefix requirement we can no longer  
control future additions of attributes in the OCCI spec. If you say that a  
particular provider must not have conflicting attribute names _today_ he  
may for example add a "ipv6" attribute. Now if we decide to add a new  
attribute, e.g. "ipv6", to a future version of OCCI Infrastructure we can  
never know if there isn't a service provider out there who already have  
that attribute in use (with different semantics). Therefore we would not  
be able to add anything and guarantee backwards compatibility.

Please feel free to prove me wrong, I would be glad if you did.

Now what we _could_ do is to instead of saying "compute": { "memory": 4,  
...} we would say:

"http://schemas.ogf.org/occi/infrastructure#compute": { "memory": 4, ... }

That would work but require more bytes on the wire in most cases. It  
actually combines the two name-spaces into a single one which is nice  
though.

What say you?

> In the category rendering we proposed to use special parameters for  
> different attribute types. e.g. having min_length and max_length for  
> strings and an array of bounds for integers or floats.

Different restrictions for different types, sure. I would just make a  
slight modification and say, e.g.:
"string": { "min_length": 4, "max_length": 32 }
That way it is much easier to strictly specify which restrictions apply to  
which type.

Could you make a list of the restrictions applicable to each of the  
defined attribute types?

> Here are some ideas:
> http://pastebin.com/y2K7bu1S

I do not really see the purpose of the URL list format you call  
"collection". You already have this with text/uri-list.

In the collection example you call "entities" you use a JSON array at the  
top level. This is a security problem and must be avoided. That is partly  
why I choose to say { "collection": [ ... ] }.
Basically if you always have an json object at the top level silly people  
doing eval() on the received json data will be kept safe.

I see you made the format really lean which is nice. How did you intend to  
render Link attributes?

> http://pastebin.com/KLF4YKny

I like the "choices" property, only make it a json array instead of a new  
string format which need to be parsed.

> What do you think about them?

Great feedback, keep it coming! :)

regards, Ralf