[occi-wg] Typed Link Kind

Mon Aug 3 07:24:46 EDT 2015

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 at troeger.eu","tmetsch at 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?

Thanks!

Cheers, Boris

On Mon, Aug 3, 2015 at 12:46 PM, Jean Parpaillon
<jean.parpaillon at 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 at 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 at 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 at gmail.com
>> > > > skype: jean.parpaillon
>> > > > linkedin: http://www.linkedin.com/in/jeanparpaillon/en
>> > > > _______________________________________________
>> > > > occi-wg mailing list
>> > > > occi-wg at 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 at 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 at gmail.com
> skype: jean.parpaillon
> linkedin: http://www.linkedin.com/in/jeanparpaillon/en