Instance Model Structure
[email protected]
Serialization to YAML
• Allows us to look at a snapshot of the instance model without having
to define query/navigation techniques
• … but need to maintain a clear concept of the information to be
represented
• Approach:
• Encode input values provided by user as input_instances
• Encode policies applied as policy_instances linking to affected templates and
instances
• Encode requirement resolution as needed for automated matching for
fulfillment
• Generate node_instances for final topology
• Encode output with final values
Information Model
Type Schema
Templates
Types
Instances
Type w
…
Type x
derived from
Properties
name: type
attributes
Met model of a
TOSCA Type
E.g. Class, data
type, references,
attributes
NodeType,
CapabilityType, …
Template y
Type x
properties
attributes
Instance z
Template y
properties
Attributes
Dynamic info
Normative?
Env specific
Parameterized
“constructors”
Parameterized
“constructors”
Relations between Node Instances
Node
Template
A
M
N
Node
Template
B
A[0]
B[0]
A[1]
B[1]
A[2]
Node instances have m x n cardinality
by default but we’ll need to support
other kind of configurations.
Instance Model Example
Unstructured approach
where node instances
are in same list and not
grouped by template.
Each node instance
indicates its template
but only way to group is
to query for matching
template name.
Instance Model Specific Serialization Issues
• Users may want to include information defined from other standards/meta
models
• Implementations may want to include additional information in TOSCA instances
• E.g. resource mapping information
• Structural information indicating relationships among other entities
• Implementations may want to include information not part of TOSCA instances
• TOSCA does not have all the features to support object trees
• Referencing entities in other subtrees (can only reference specific instances by name, no
collections)
• Generalized referencing that work in document, cross document with relative and absolute
URIs
• Collections
• Referencing entities in ordered collections
• Referencing entities by key
Reference semantics
A
D
Containment Reference
B
C
E
C
Cross Reference
Extensions for General Information
Representation
• Enhance data types:
•
•
•
•
Explicitly denote containment and cross reference
Reference other documents and namespaces using URIs and fragments
Fragments with index
New section object_instances to hold generic data objects not TOSCA
instances
• Support indexing into a list
Adding referencing to YAML
• JSON had to solve similar problem (solved originally in XML)
• JSON Schema
• Motivates referencing
• JSON Pointer
• JSON Reference
• Interesting:
• XMI
• JSONPath (no formal spec???)
• JSON-LD
http://abc.com/schemas/abc_data_types#/data_types/tosca.datatypes.AbcType
URI
Fragment
JSON Pointer
URI Fragment Identifier Representation
A JSON Pointer can be represented in a URI fragment identifier by encoding it into octets using UTF-8 [RFC3629], while
percent-encoding those characters not allowed by the fragment rule in [RFC3986]. Note that a given media type needs
to specify JSON Pointer as its fragment identifier syntax explicitly (usually, in its registration [RFC6838]). That is, just
because a document is JSON does not imply that JSON Pointer can be used as its fragment identifier syntax. In
particular, the fragment identifier syntax for application/json is not JSON Pointer. Bryan, et al. Standards Track [Page 5]
RFC 6901 JSON Pointer April 2013 Given the same example document as above, the following URI fragment identifiers
evaluate to the accompanying values:
# // the whole document
{
#/foo
["bar", "baz"]
"foo": ["bar", "baz"],
#/foo/0 "bar"
"": 0,
#/
0
Sample
"a/b":
1,
Sample
#/a~1b 1
fragment
"c%d": 2,
Document
#/c%25d 2
identifiers
"e^f": 3,
#/e%5Ef 3
"g|h": 4,
#/g%7Ch 4
"i\\j": 5,
#/i%5Cj 5
"k\"l": 6,
#/k%22l 6
" ": 7, "m~n": 8
#/%20 7
}
#/m~0n 8
JSON Reference (for inspiration)
A JSON Reference is a JSON object, which contains a member named "$ref", which has a JSON string value.
Example: { "$ref": "http://example.com/example.json#/foo/bar" } If a JSON value does not have these
characteristics, then it SHOULD NOT be interpreted as a JSON Reference. The "$ref" string value contains a
URI [RFC3986], which identifies the location of the JSON value being referenced. It is an error condition if the
string value does not conform to URI syntax rules. Any members other than "$ref" in a JSON Reference object
SHALL be ignored.