[occi-wg] Typed Link Kind

Jean Parpaillon jean.parpaillon at free.fr
Mon Aug 3 07:58:51 EDT 2015 

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

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