Information type Data renamed to Vehicle data.

README.md

@@ -24,6 +24,12 @@ that can be used to define tree structures representing information (see below)
 This repository is managed by the [COVESA Data Expert Group](https://wiki.covesa.global/display/WIK4/Data+Expert+Group),
 together with the [COVESA CVIS project](https://wiki.covesa.global/display/WIK4/CVIS+Meeting+Topics+and+Meeting+Notes).
 
+## Latest version
+[HIM version 1.0](https://github.com/COVESA/hierarchical_information_model/releases/tag/v1.0)
+
+## Previous versions
+None.
+
 ## HIM Overview
 
 The information of a domain that is described using HIM is represented in a graph made up of a tree structure with parent-child relationships,
@@ -38,14 +44,19 @@ This rule set aims at being domain agnostic and can thus be used to define the t
 Another ambition of HIM s that it shall support definition of taxonomies of different types of information,
 and not only the type here called "resource data".
 HIM currently supports the following "information types":
-- Resource data: Information defining the data that a resource produces or consumes.
-- Service data: Information defining the details of a "service" in the form of a procedure (name, input, output).
+- Vehicle data: Information defining the data that a vehicle produces or consumes.
+- Service: Information defining the details of a "service" in the form of a procedure (name, input, output).
 - Type definition data: Information defining complex/composite data types that are used by the other information types.
 
 HIM also provides a rule set for the definition of a "configuration file" that can be used by a HIM enabled data server in its management of
-a "forest" of multiple trees. This information can also by the server be provided to a client wanting to know what data or services the server
+a "forest" of multiple trees. This information can also by the server be provided to a client wanting to know what vehicle data or services the server
 has to offer.
 
+HIM uses profiles that defines subsets of the complete model.
+Currently the following profiles are defined:
+* Vehicle data profile: excludes the Service information type
+* Service profile excludes the Vehicle data information type
+
 What is not an ambition of HIM is to define how the information is transported between agents,
 which is left to projects defining transport protocols, interfaces, and the like.
 Neither is it aiming for defining the content of any tree, which is also left to other projects.

docs-gen/content/_index.md

@@ -18,7 +18,7 @@ A domain can in the HIM context be defined with the help of two dimensions:
   - Examples are a car, a truck, a trailer, an airplane, etc.,
 - an 'information type' dimension that is used in the description of a coherent dimension using a specific information type.
   - The currently defined information types are listed below.
-    - Data
+    - Vehicle data
     - Service
     - Type definitions
 
@@ -29,8 +29,8 @@ One example of such a project is the [Vehicle Signal Specification](https://gith
 
 The documentation is structured in the different rule sets shortly described below.
 
-## HIM Data Rule Set
-[Rules](/hierarchical_information_model/data_rule_set/) for describing data produced/consumed by resources that can be represented by static or dynamically changing data values.
+## HIM Vehicle Data Rule Set
+[Rules](/hierarchical_information_model/vehicle_data_rule_set/) for describing data produced/consumed by vehicles that can be represented by static or dynamically changing data values.
 
 ## HIM Service Rule Set
 [Rules](/hierarchical_information_model/service_rule_set/) for describing services that can be represented by procedure signatures.
@@ -49,28 +49,26 @@ The HIM model supports different information types,
 and a server exposing an interface that uses HIM for its data representation may have to implement features that its clients have no interest in.
 A server to be used in an environment where the Data type (i. e. classical signals) is used can then be
 implemented without support for a service oriented architecture (SOA).
-To support scenarios like this HIM specifies the three different profiles shown below.
+To support scenarios like this HIM specifies the different profiles shown below.
 
-A client that issues an inquiry on what profile is supported shall receive information on that in the response.
-
-### HIM Data Profile
-The HIM Data profile excludes use of trees that contain the Service data information type.
+### HIM Vehicle Data Profile
+The HIM vehicle data profile excludes use of trees that contain the Service information type.
 This profile is for example compatible with the VSS tree.
 
 ### HIM Service Profile
-The HIM Service profile excludes use of trees that contain the Data information type.
+The HIM Service profile excludes use of trees that contain the Vehicle data information type.
 This profile can for example be used in "pure" SOA architectures.
 
-### HIM All Profile
-The HIM All profile supports use of trees that contain data of any HIM specified information type.
+### HIM Complete Profile
+The HIM Complete profile supports use of trees that contain data of any HIM specified information type.
 This makes it possible for a server to serve clients that wants to have access to both "classical signals" and services represented by function calls.
 
 ## HIM enablers
 HIM enables a single server implementation to support use cases from multiple domains, e. g. telemetry via a tree such as the
 [COVESA VSS](https://github.com/COVESA/vehicle_signal_specification) tree,
 or diagnostics via a tree referring to diagnostics data, or trees describing the data or services of other domains.
 
-The same server can expose access to both data (signals) and services (procedures).
+The same server can expose access to both vehicle data (signals) and services (procedures).
 Instead of developing a new server and possibly also define a new interface when a new domain is to be served,
 a new tree containing the signals or services for the domain is created and linked to the server via the HIM configuration file.
 

docs-gen/content/configuration_rule_set/basics.md

@@ -36,15 +36,14 @@ Usage of a HIM configuration file is optional, but it is recommended in scenario
 
 The following node types can be used in a configuration tree:
 1. [Branch](/hierarchical_information_model/common_rule_set/node_types/branch/)
-2. [Direct](/hierarchical_information_model/configuration_rule_set/node_types/diect/)
+2. [Direct](/hierarchical_information_model/configuration_rule_set/node_types/direct/)
 3. [Proxy](/hierarchical_information_model/configuration_rule_set/node_types/proxy/)
 
 ## Configuration Tree Example
-This example shows a forest consisting of three local trees, and a remote tree:
+This example shows a forest consisting of three local trees:
 1. A local tree containing passenger car related signals, having the root node name VehicleData.
 2. A local tree containing passenger car related services, having the root node name VehicleServices.
 3. A local tree containing type passenger car related ype definitions, having the root node name Types.
-4. A remote tree containing charge station related signals, having the root node name ChargingStationData.
 
 ```YAML
 HIM:
@@ -54,10 +53,10 @@ HIM:
 
 VehicleData:
   type: direct
-  domain: Vehicle.Car.Data
+  domain: Vehicle.Car.VehicleData
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.Data.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.VehicleData.X.Y.Z
   description:  ….
 
 VehicleServices:
@@ -73,14 +72,6 @@ Types:
   domain: Vehicle.Car.TypeDefinition
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.DataType.X.Y.Z
-  description:  ….
-
-
-ChargingStationData:
-  type: proxy
-  domain:ChargingStation.Vehicle.Data
-  version: X.Y.Z
-  public: https://himrepo.energyco.com?instance=ChargingStation.Vehicle.Data.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.TypeDefinition.X.Y.Z
   description:  ….
   ```

docs-gen/content/configuration_rule_set/node_types/direct.md

@@ -61,9 +61,9 @@ An example of the specification of a `direct` node is given below.
 ```YAML
 HIM.Vehicle:
   type: direct
-  domain: Vehicle.Car.Data
+  domain: Vehicle.Car.VehicleData
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.Data.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.VehicleData.X.Y.Z
   description: This is a tree of type direct.
 ```

docs-gen/content/configuration_rule_set/node_types/proxy.md

@@ -66,7 +66,7 @@ The `local` points to a Unix domain socket for communication with a proxy server
 ```YAML
 HIM.Home:
   type: proxy
-  domain: HomeAutomation.Zigbee.Data
+  domain: HomeAutomation.Zigbee.Service
   version: X.Y.Z
   local: uds://path/to/uds-file
   description: Home automation proxy tree.

docs-gen/content/service_rule_set/_index.md

@@ -4,7 +4,7 @@ weight: 20
 chapter: true
 ---
 
-# HIM Service Data Rule Set
+# HIM Service Rule Set
 
 The rules that are specific for the information type `service` is described in this part of the document,
 and together with the rules in the [Common rule set part](/hierarchical_information_model/common_rule_set) it forms the overall rules for this information type.

docs-gen/content/data_rule_set/_index.md → docs-gen/content/vehicle_data_rule_set/_index.md

@@ -1,10 +1,10 @@
 ---
-title: HIM Data Rule Set
+title: HIM Vehicle Data Rule Set
 weight: 20
 chapter: true
 ---
 
-# HIM Data Rule Set
+# HIM Vehicle Data Rule Set
 
-The rules that are specific for the information type `data` is described in this part of the document,
+The rules that are specific for the information type `vehicledata` is described in this part of the document,
 and together with the rules in the [Common rule set part](/hierarchical_information_model/common_rule_set) it forms the overall rules for this information type.

docs-gen/content/data_rule_set/basics.md → docs-gen/content/vehicle_data_rule_set/basics.md

@@ -4,8 +4,8 @@ date: 2019-08-04T13:05:11+02:00
 weight: 1
 ---
 
-The rule set for Data is inherited from the [VSS rule set](https://covesa.github.io/vehicle_signal_specification/rule_set/).
-It is the leaf nodes of a tree that represents and defines the actual data.
+The rule set for vehicle data is inherited from the [VSS rule set](https://covesa.github.io/vehicle_signal_specification/rule_set/).
+It is the leaf nodes of a tree that represents and defines the actual vehicle data.
 The definition is expressed by metadata describing the data associated to the node.
 
 ## Node Types

examples/HIM_config_example.v1.0.0.him

@@ -5,31 +5,24 @@ HIM:
 
 HIM.Vehicle:
   type: direct
-  domain: Vehicle.Car.Data
+  domain: Vehicle.Car.VehicleData
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.ResourceData.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.VehicleData.X.Y.Z
   description:  Vehicle signal tree.
 
 HIM.VehicleServices:
   type: direct
   domain: Vehicle.Car.Service
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.ServiceData.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.Service.X.Y.Z
   description:  Vehicle service tree.
 
 HIM.Types:
   type: direct
   domain: Vehicle.Car.TypeDefinition
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.DataType.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.TypeDefinition.X.Y.Z
   description:  Type definition tree.
-
-HIM.Home:
-  type: proxy
-  domain: HomeAutomation.Zigbee.Data
-  version: X.Y.Z
-  local: uds://path/to/uds-file
-  description: Home automation proxy tree.

examples/README.md

@@ -1,12 +1,11 @@
 # HIM example files
 
 This directory contains an example file of each of the information types that HIM currently defines:
-- Resource data: HIM_Resource_example.v1.0.0.vspec
-- Service data: HIM_Service_example.v1.0.0.vspec
+- Vehicle data: HIM_VehicleData_example.v1.0.0.vspec
+- Service: HIM_Service_example.v1.0.0.vspec
 - Type definition data: TypeDefinition_example.v1.0.0.vspec
 
 It also contains an example file of a HIM configuration file: HIM_config_example.v1.0.0.him
 
-The resource data example uses the vspec format that is inherited from the VSS project.
-The service data and type definition data examples are expressed in YAML as it is the primary format for HIM files.
-However, HIM also inherits the pattern from VSS to allow translation from the primary format into other formats such as JSON, etc.
+The information type example files shall use the vspec format as the primary format.
+However, HIM inherits the pattern from VSS to allow translation from the primary format into other formats such as JSON, etc.

tools/README.md

@@ -7,15 +7,15 @@ Currently it supports the exporter formats:
 * JSON
 * binary
 
-All the key names of properties used to define a data tree can be used, plus te following:
+All the key names of properties used to define a vehicle data tree can be used, plus the following:
 * procedure  // the name of the procedure that is called to execute the service
 * iostruct   // a struct that is dedicated to define the procedure input and output parameters.
 
 The HIM tools does not support the "instances" feature.
 
 ## HIM tools generated service tree in a VISSR context
 HIM tools can be used to generate a binary formatted tree that can to a limited extent be used by the VISSR server.
-The limitation depends on that the current version of VISSR only supports the HIM data profile, not he HIM service profile.
+The limitation depends on that the current version of VISSR only supports the HIM vehicle data profile, not the HIM service profile.
 It is herefore not possible to invoke a service on VISSR, i. e. make a call to a procedure node together with its input parameters.
 What can be done however, is to issue a "service discovery" request to the server, on which it will return the metadata of the addressed subtree.
 
@@ -35,7 +35,7 @@ HIM.VehicleService:
   domain: Vehicle.Car.Service
   version: 0.0.1
   local: forest/himExport.binary
-#  public: https://himrepo.oem.com?instance=Vehicle.Car.ResourceData.X.Y.Z
+#  public: https://himrepo.oem.com?instance=Vehicle.Car.Service.X.Y.Z
   description: A HIM service tree.
 ```
 7. Start the VISSR server plus a feeder. This can be done by issuing "$ ./runstack startme" in the vissr directory.

tools/TypeDefinition/Datatypes.vspec → tools/TypeDefinition/Datatypes2.vspec

@@ -1,3 +1,4 @@
+# Type definition tree with struct that has a member that is another struct
 Types:
   description: Datatype definitions.
   type: branch
@@ -25,6 +26,29 @@ Types.Struct.FileDescriptor.Uid:
   type: property
   datatype: string
 
+Types.Struct.InlineStruct:
+  description: Test struct with member that is a struct.
+  type: struct
+
+Types.Struct.InlineStruct.Name:
+  description: Name struct member.
+  type: property
+  datatype: string
+
+Types.Struct.InlineStruct.NewStruct:
+  description: A new struct as struct member.
+  type: property
+  datatype: Types.Struct.InlineStruct.InlineStructMember
+
+Types.Struct.InlineStruct.InlineStructMember:
+  description: Test struct used as member of another struct.
+  type: struct
+
+Types.Struct.InlineStruct.InlineStructMember.Name:
+  description: Name inline struct member.
+  type: property
+  datatype: string
+
 Types.Allowed:
   description: Allowed datatype definitions.
   type: branch