Hi, Le lundi 03 août 2015 à 14:06 +0200, Boris Parak a écrit :
On Mon, Aug 3, 2015 at 1:58 PM, Jean Parpaillon < jean.parpaillon@free.fr> wrote:
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...
Oh, sorry, I forgot to say. The current OCCI 1.2 core spec already allows complex instance attribute values. That's why I sort of resurrected this discussion. It allows
Object (let's say "any simple value") Array (List) Hash (dict)
Ok, I was not referring to the latest document :) Cheers, Jean
So, yes, we need to update rendering documents. I already added comments to the public comment to track this.
IMHO: whatever we decide to allow complex attributes in a future Core spec, JSON rendering should not be a limitation for that.
Exactly.
-> I support your modification to JSON rendering.
Ok, thanks for your feedback. If we resolve this correctly, the proposed 'source.type' and 'target.type' attributes can be safely included in OCCI 1.2
Thanks!
Cheers, Boris
Jean
Cheers, Boris
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_co re/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
-- 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