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. 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

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!

[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

You're welcome. Jean linkedin: http://www.linkedin.com/in/jeanparpaillon/en

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/src/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

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

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

linkedin: http://www.linkedin.com/in/jeanparpaillon/en

Hi Peter,

The draft (!) is 3 years old, so this is not surprising. Please, send me some more details about what is wrong with the current mapping approach. I still get requests for making it a real specification, so the demand is there.

the mistake is on our side, not yours. We will fix it in OCCI 1.2.

As said above, our experience shows that you cannot get away with simple data types only. This is why the DRMAA root spec (language-agnostic, as OCCI core) relies on a struct type as smallest common denominator across multiple languages. They can be mapped to dictionaries (Python / Perl / Ruby), classes (C++, Java) or simple structs (C).

Agreed. The new OCCI Core spec will reflect that. Cheers, Boris On Mon, Aug 3, 2015 at 2:08 PM, Peter Tröger <peter@troeger.eu> wrote:

Dear all,

...

...

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“}

...

...

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" }

From to the discussion in January 2014 (still), we agreed this was not an issue until attribute values are all scalar (string, number, boolean).

Agreed, but flattening the DRMAA data structures into single OCCI attributes is not the right way. Sometimes you need „snapshot“ semantics for sets of values.

...

Some thoughts: 1/ DRMAA spec is incorrect wrt actuel OCCI specifications

The draft (!) is 3 years old, so this is not surprising. Please, send me some more details about what is wrong with the current mapping approach. I still get requests for making it a real specification, so the demand is there.

...

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.

As said above, our experience shows that you cannot get away with simple data types only. This is why the DRMAA root spec (language-agnostic, as OCCI core) relies on a struct type as smallest common denominator across multiple languages. They can be mapped to dictionaries (Python / Perl / Ruby), classes (C++, Java) or simple structs (C).

Best regards, Peter.