[occi-wg] Typed Link Kind
Jean Parpaillon
jean.parpaillon at free.fr
Mon Aug 3 06:46:04 EDT 2015
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
-------------- next part --------------
$ curl -v -H 'accept: application/json' http://localhost:32770/-/
* Trying ::1...
* Connected to localhost (::1) port 32770 (#0)
> GET /-/ HTTP/1.1
> Host: localhost:32770
> User-Agent: curl/7.43.0
> accept: application/json
>
< HTTP/1.1 200 OK
< connection: keep-alive
< date: Mon, 03 Aug 2015 09:24:30 GMT
< content-length: 1187
< server: erocci OCCI/1.1
< content-type: application/json
< vary: accept
<
{
"kinds" : [
{
"term" : "compute",
"scheme" : "http://example.org/occi/#",
"class" : "kind",
"title" : "A Resource Kind",
"parent" : "http://schemas.ogf.org/occi/core#resource",
"attributes" : {
"occi" : {
"example" : {
"attr1" : {
"mutable" : true,
"title" : "Attribute 1",
"required" : false,
"type" : "string"
},
"attr1" : {
"type" : {
"mutable" : true,
"title" : "Attribute 2",
"required" : false,
"type" : "string"
}
},
"attr2" : {
"with" : {
"additionale" : {
"namespace" : {
"mutable" : true,
"title" : "Attribute 1",
"required" : false,
"type" : "string"
}
}
}
}
}
}
},
"location" : "http://localhost:32770/collections/compute/"
}
],
"mixins" : [
],
"actions" : [
]
}
* Connection #0 to host localhost left intact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ext1.xml
Type: application/xml
Size: 838 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20150803/abe0dfb0/attachment.xml>
-------------- next part --------------
# The function takes as input an attribute name, as a list of name's components,
# and the value of the attribute.
# The accumulator is used for recursion.
#
# It returns the tree representation of the JSON object representing the lsit of attributes
# eg:
# Given the following attributes:
# {"occi.example.attr1", "value1"}
# {"occi.example.attr2.with.additional.namespace", "value2"}
# {"occi.example.attr1.type", "value3"}
#
# 1/ attributes names are splitted:
# {[ "occi", "example", "attr1" ], "value1"}
# {[ "occi", "example", "attr2", "with", "additional", "namespace" ], "value2"}
# {[ "occi", "example", "attr1", "type" ], "value3"}
#
# 2/ this pair list is given to insert_attr and should output:
# {[
# { "occi", [
# { "example", [
# { "attr1", "value },
# { "attr2", [
# { "with", [
# { "additional", [
# {"namespace", "value2"}
# ]}
# ]}
# ]},
# { "attr1", [
# { "type": "value3" }
# ]}
# ]}
# ]}
# ]}
#
# This structure of tuple and lists is then transformed into JSON syntax with a pretty
# straightforward algorithm:
# { "key", "value" } -> "key": "value"
# [ {"key1", "value1"}, {"key2", "value2"}] -> { "key1": "value1", "key2": "value2" }
# etc.
#
# Name: list of attribute name components
# Value: any object
# Acc: a list of { Key, Value } pairs
function insert_attr(Name, Value, Acc):
if length(Name) == 1:
# Last name component, we insert the value
return prepend({Name, Value}, Acc);
{ ActualNS, Children } = first(Acc);
if first(Name) == ActualNS:
# This name component is already present in Acc,
# insert attribute in the existing tree
Tree = insert_attr(tail(Name), Value, Children);
return prepend({Name, Tree}, tail(Acc));
else:
# This name component does not exist in Acc,
# creates a new branch
Tree = insert_attr(tail(Name), Value, []);
return prepend({Name, Tree}, Acc);
More information about the occi-wg
mailing list