Hi Boris, Le lundi 03 août 2015 à 13:24 +0200, Boris Parak a écrit :
Hi Jean,
that's a very good point. Thanks! I will explore erocci a little bit :-)
However, there is one problem we did not discuss yet (AFAIK). I've seen the unfinished DRMAA<->OCCI document and Peter is using complex instance attributes, such as:
< X-OCCI-Attribute: occi.drmaa2.drmsName="Platform LSF" < X-OCCI-Attribute: occi.drmaa2.drmsVersion={"major":"42", "minor":"0"} < X-OCCI-Attribute: occi.drmaa2.drmaaName="Thijs’s OCCI-DRMAA backend" < X-OCCI-Attribute: occi.drmaa2.drmaaVersion={"major":"2", "minor":"17"}
or
X-OCCI-Attribute: occi.drmaa2.remoteCommand="/bin/date" X-OCCI-Attribute: occi.drmaa2.machineOS="LINUX" X-OCCI-Attribute: occi.drmaa2.email=["peter@troeger.eu"," tmetsch@platform.com"] X-OCCI-Attribute: occi.drmaa2.emailOnTerminated=true
As far as I know, this is not something we explored in the main OCCI specification and we need to address it for OCCI 1.2. The Core document is talking about possible attribute types Object, Array, Hash ... but the rendering documents (Text or JSON) do not specify how to render/parse these without ambiguity. Especially in JSON, as you pointed out, complex instance attribute values cannot be parsed without the accompanying attribute definitions ... and even with that, there is still some ambiguity there due to the unknown structure of the particular instance attribute value.
Let's say we have two instance attributes with Hash values:
occi.test.case.attr1 = { "subattr1": { "value1": "something_here" } }
occi.test.case.attr1.subattr1 = { "value1" : "something_different_here" }
Once rendered into JSON, these two are indistinguishable despite the fact that they are technically two different attributes with two different values. This is a major problem, especially with the intended degree of extensibility of OCCI.
Therefore I propose to modify the JSON rendering specification and use the attribute name as an identifier without any internal structure, i.e. no splitting on '.'.
Am I completely wrong here? Does anyone else think this is a problem?
From to the discussion in January 2014 (still), we agreed this was not an issue until attribute values are all scalar (string, number, boolean). Some thoughts: 1/ DRMAA spec is incorrect wrt actuel OCCI specifications 2/ do we want to allow complex attribute value types: Yes -> requires to explicit these types: dictionaries ? list ? tuples ? etc. ? and update all renderings in consequence No -> DRMAA spec remains incorrect, but how many future spec will be more complex because of that restriction...
IMHO: whatever we decide to allow complex attributes in a future Core spec, JSON rendering should not be a limitation for that. -> I support your modification to JSON rendering.
Thanks!
Cheers, Boris
Jean
On Mon, Aug 3, 2015 at 12:46 PM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:
Hi Boris,
Le vendredi 31 juillet 2015 à 23:08 +0200, Boris Parak a écrit :
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/s rc/r ende ring/occi_renderer_json.erl#L194
I have to admit that my basic understanding of functional languages is a problem here :-)
The occi_rendering_json.code file contains a "pseudo-code" version of the algorithm, without pattern matching, which is maybe what's confusion there.
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?
I suppose it is related in some way to the discussion we've had in January 2014 ;) https://www.ogf.org/pipermail/occi-wg/2014-January/003438.html
You will find in attachment an XML description of such complex attributes with the JSON output from erocci. Would you like to test other cases, you can use the erocci docker, as described here, replacing occi.xml with your own schema (like ext1.xml in attachment): https://github.com/erocci/docker-erocci
Rendering the JSON is fine with the above algorithm. Parsing is unambiguous but parsing may be tough to implement: - when parsing the attribute definition, if "type" value is a string, it is the type of the attribute, if "type" value is an object, it is a component of the attribute name. - when parsing the attribute instance, "type" can be only an attribute name component.
At the end, implementation concerns may be a valid reason for forbidding some attribute names, but we must explicit it in the specification.
Could you give me the rendered JSON as an example?
See attachment.
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
Cheers, Jean
[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
-- 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
-- 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