[occi-wg] Typed Link Kind
Jean Parpaillon
jean.parpaillon at free.fr
Tue Aug 4 01:51:49 EDT 2015
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 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)
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 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_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 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
--
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