[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Proposed changes for chapter 4.4.1: Primitive Types
Thanks Tal, this is excellent. I have incorporated this text in the latest revision. Chris From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron Following today's ad hoc meeting, here are my proposed changes to this chapter.
4.4 Properties, Attributes, and Parameters
This section presents handling data in TOSCA via properties, attributes and parameters.
The type of the values they contain can be divided into built-in primitive types, special types that are extensions of the primitive types, and collection types, as well as user-defined refinements of
these and complex data types that can themselves be defined in TOSCA profiles and the TOSCA service template.
Values can also be evaluated from expressions based on TOSCA functions. [See XXX]
The following table summarizes the built-in types. All of these type names are reserved and cannot be used for custom data types. Note, however, that it is possible to derive a custom data type from a
primitive type in order to add constraints.
Primitive Types: (section 4.4.1)
Special Types: (section 4.4.2)
Collection Types: (section 4.4.3)
[Tal's comment: the Data Type section would thus be pushed to 4.4.4]
4.4.1 Primitive Types
The TOSCA primitive types have been specified to allow for the broadest possible support for implementations.
Guiding principles:
4.4.1.1 string
An array of Unicode runes. (For storing an arbitrary array of bytes see the âbytesâ type, below.)
Because we adhere to 64-bit precision, the minimum length of strings is 0 and the maximum length of strings is 4,294,967,295.
TOSCA does not specify a character encoding. For example, a string could be encoded as UTF-8 or UTF-16. The exact encoding used depends on the implementation.
Be aware that YAML parsers will attempt to parse unquoted character sequences as other types (booleans, integers, floats, etc.)
before falling back to the !!string type. For example, the unquoted sequence â0.1â would be interpreted as a YAML
!!float. Likewise for the unquoted sequence ânanâ would become the
!!float value of not-a-number. However, in TOSCA a string value
must be specified in YAML as a !!string.
A TOSCA parser shall not attempt to convert other primitive types to strings if a string type is required. This requirement is necessary for ensuring portability, because there is no single, standard
representation for the other types, e.g. scientific notations for decimals, the words âtrueâ va. âTrueâ for booleans, etc. In YAML users should thus add quotation marks around literal strings that YAML would otherwise interpret as other types.
This following example would be invalid if there were no quotation marks around â0.1â:
node_types:
Node:
properties:
name:
type: string
topology_template:
node_templates:
node:
type: Node
properties:
name: "0.1"
Notes:
[Talâs comment: for functions and constraints we should specify their exact behavior for various primitive types. Some wonât work on all types, e.g. âlengthâ should not work on integers.]
4.4.1.2 integer
A 64-bit signed integer.
For simplicity, TOSCA does not have integers of other bit widths, nor does it have an unsigned integer type. However, it is possible to enforce most of these variations using data type constraints [see
XXX].
For example, this would be a custom data type for unsigned 16-bit integers:
data_types:
UInt16:
derived_from: integer
constraints:
- in_range: [ 0, 0xFFFF ]
Notes:
4.4.1.3 float
A 64-bit (double-precision) floating-point number [IEEE 754], including the standard values for negative infinity, positive infinity, and not-a-number.
Be aware that YAML parsers will parse numbers with a decimal point as
!!float even if they
could be represented as !!int, and likewise numbers without a decimal point would
always be parsed as !!int.
A TOSCA parser shall not attempt to convert a YAML
!!int to a float. This requirement is necessary for avoiding rounding errors and ensuring portability. Users should thus add a â.0â suffix
to literal integers that must be floats. Note that this even includes zero, i.e. users must specify â0â for a zero integer and â0.0â for a zero float.
This following example would be invalid if there were no â.0â suffix added to â10â:
node_types:
Node:
properties:
velocity:
type: float
topology_template:
node_templates:
node:
type: Node
properties:
velocity: 10.0
Notes:
4.4.1.4 boolean
A single bit.
Note that in YAML literal booleans can be
only either the unquoted all-lowercase words âtrueâ or âfalseâ.
A TOSCA parser shall not attempt to convert these values, nor variations such as âyesâ or âTrueâ, as quoted strings to booleans, nor shall it attempt to convert integer values (such as 1 and 0)
to booleans. This requirement is necessary for ensuring portability as well as clarity.
4.4.1.5 bytes
An array of arbitrary bytes. Because we adhere to 64-bit precision, the minimum length of bytes is 0 and the maximum length of bytes is 4,294,967,295.
To specify literal bytes in YAML you
must use a Base64-encoded !!string [RFC 2045 section 6.8]. There exist many free tools to help you convert arbitrary data to Base64.
Example:
node_types:
Node:
properties:
preamble:
type: bytes
topology_template:
node_templates:
node:
type: Node
properties:
preamble: "\
R0lGODlhDAAMAIQAAP//9/X17unp5WZmZgAAAOfn515eXvPz7Y6OjuDg4J+fn5\
OTk6enp56enmlpaWNjY6Ojo4SEhP/++f/++f/++f/++f/++f/++f/++f/++f/+\
+f/++f/++f/++f/++f/++SH+Dk1hZGUgd2l0aCBHSU1QACwAAAAADAAMAAAFLC\
AgjoEwnuNAFOhpEMTRiggcz4BNJHrv/zCFcLiwMWYNG84BwwEeECcgggoBADs="
Notes:
4.4.1.6 nil
The nil type always has the same singleton value.
No other type can have this value.
This value is provided literally in YAML via the unquoted all-lowercase word ânullâ. Example:
node_types:
Node:
properties:
nothing:
type: nil
required: true
topology_template:
node_templates:
node:
type: Node
properties:
nothing: null
Note that a nil-typed value is
distinct from an unassigned value. For consistency TOSCA requires you to assign nil values even though their value is obvious. Thus, the above example would be invalid if we did not specify the null value for the property at the node template.
Following is a valid example of
not assigning a value:
node_types:
Node:
properties:
nothing:
type: nil
required: false
topology_template:
node_templates:
node:
type: Node |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]