On Fri, Jul 31, 2015 at 5:01 PM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:
Hi Boris,
Le vendredi 31 juillet 2015 à 11:48 +0200, Boris Parak a écrit :
Hi Jean,
On Fri, Jul 31, 2015 at 10:49 AM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:
Hi all, With Olivier Barais, in CC, with which I am working on the OCCIware project, we would like to enhance the core specification with a way to constrain the Category of resources pointed out by occi.core.src and occi.core.target attributes of a link.
For instance, in the infrastructure extension, while it is specified (and easily make sense) a NetworkInterface link must be linked to a compute and a network instance, there is no formal way to define this constraint.
A proposal would be to add new type of Category, sub-type of Kind, with following attributes: - parent: instantiated as http://schemas.ogf.org/occi/core#link - occi.core.src.type: additional attribute, type category id - occi.core.target.type: additional attribute, type category id
The name of this type of Category could be "TypedLinkKind".
What do you think of this ?
at first glance, it looks like a reasonable request ... it would definitely improve automated validation and modeling in OCCI. Especially with previously unknown extensions.
'occi.core.target' will be a bit problematic, because it can point "outside" the local domain. But we could easily cover that by making these attributes optional.
So, I would consider dropping the TypedLinkKind and include these two attributes in the existing Link kind, as optional. That way we get a typed link, partially typed link and "legacy" link all-in-one. While keeping it all backwards compatible. If the type attribute is present, you can use it, if not ... well ... you are out of luck :-)
As a side note, I would very much like to avoid introducing attribute names with matching prefixes:
occi.core.target = "value" occi.core.target.type = "value"
This makes JSON rendering really difficult. Would you be OK with "target_type" & "source_type"?
I would prefer the former one, but I can accept the second one.
I know ... 'target.type' makes more sense and is much prettier to look at.
BTW, here is the algortihm I use for inserting any dot-separated attribute name into the JSON tree of attributes, would you be interested in implementing it into rocci: https://github.com/erocci/erocci/blob/master/apps/erocci_core/src/rende ring/occi_renderer_json.erl#L194
I have to admit that my basic understanding of functional languages is a problem here :-) How do you deal with complex attribute values? Let's say we have an attribute occi.test.target = { ... Hash Here ... } // hash has "type" => "StringHere" inside it and an attribute occi.test.target.type = "StringHere" How would you distinguish between the value for key 'type' in the attribute value (Hash) of 'occi.test.target' and the attribute value of 'occi.test.target.type'? How would these be rendered in JSON together? Could you give me the rendered JSON as an example?
Also, could you, please, include this as a comment here [1], then we can discuss it as a part of public comment on OCCI 1.2 and possibly include it :-)
Done, last minute before end of comments ;)
Thanks!
You're welcome.
Jean
Cheers, Boris
[1] https://redmine.ogf.org/boards/26/topics/429
Regards, -- Jean Parpaillon --
Cheers, Boris
Open Source Consultant OW2 Technology Council Chairman Director @ OW2 Consortium OCCIware Strategic Orientation Committee Chairman Research Engineer @ Inria -- Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg -- Jean Parpaillon -- Open Source Consultant OW2 Technology Council Chairman Director @ OW2 Consortium OCCIware Strategic Orientation Committee Chairman Research Engineer @ Inria -- Phone: +33 6 30 10 92 86 im: jean.parpaillon@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en