[occi-wg] Typed Link Kind

Boris Parak xparak at mail.muni.cz
Mon Aug 3 08:06:59 EDT 2015 

On Mon, Aug 3, 2015 at 1:58 PM, Jean Parpaillon <jean.parpaillon at 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 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?
>
> 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)

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

More information about the occi-wg mailing list