Skip to content

xid / specs

Go to a project
Toggle navigation
Toggle navigation pinning
29ec9747 by Skip Hines
Options

ILP-17 : Create V1.2 for HPE and ILP. HpeWiFi.xid.xml now using "mac48" type.

1 parent 61e08a71
Expand all
Inline Side-by-side
Showing 11 changed files with 629 additions and 1 deletions
HPE/V1.2/HpeUsage.xid.xml 0 → 100644
1 <?xml version="1.0" encoding="UTF-8" ?>
2
3 <specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
4 xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6 xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
7 identity="HpeUsage.xid.xml">
8 <title>HPE Usage Messages</title>
9 <comment>This file the usage messages produced by the HPE.</comment>
10
11 <import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
12 <import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
13 <import ref="https://xid.location.studio/Tensor/V1.0.0/Logging.xid.xml" local="Logging.xid.xml" />
14
15 <namespace name="HPE">
16 <using namespace="Tensor"/>
17 <using namespace="Logging"/>
18
19 <!--Initialization Report Msg-->
20 <struct name="InitializationReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/initrpt"'>
21 <comment>
22 Message captures HPE initialization data.
23 </comment>
24
25 <elem name="state" type="StateInfo" multiplicity="1">
26 <comment>
27 State information.
28 </comment>
29 </elem>
30 </struct>
31
32 <!--Observation Report Msg-->
33 <struct name="ObservationReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/obsrpt"'>
34 <comment>
35 Message captures HPE observation data for playback purposes and debugging.
36 </comment>
37
38 <elem name="observations" type="ObservationSet" multiplicity="1">
39 <comment>
40 Observation Data provided by the caller.
41 </comment>
42 </elem>
43
44 <elem name="refdata" type="ReferenceDataSet" multiplicity="0..1">
45 <comment>
46 Contains reference data provided by the caller.
47 </comment>
48 </elem>
49
50 <elem name="directive" multiplicity="0..*" type="Tensor.NameValue">
51 <comment>
52 A set of directives to influence processing. Unknown directives are ignored.
53 </comment>
54 </elem>
55 </struct>
56
57 <!--TaskReport Msg-->
58 <struct name="TaskReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/taskrpt"'>
59 <comment>
60 Message reports processing task result data. Tasks are any computational elem
61 within the HPE including calculators, converters, estimators.
62 </comment>
63 <elem name="taskid" type="string" multiplicity="1">
64 <comment>
65 The unique tasks identifier. A source may have multiple tasks, this field assigns
66 an identifier that uniquely characterizes what the task was that was accomplished.
67 </comment>
68 </elem>
69 <elem name="start" type="datetime" multiplicity="1">
70 <comment>
71 The start time at which the processor is used.
72 </comment>
73 </elem>
74 <elem name="duration" type="uint16" multiplicity="1">
75 <tag name="unit" value="msec"/>
76 <comment>
77 The duration of the processing in msec. This is not meant to be a high
78 resolution duration monitoring, implement a metric counter for precise timing data.
79 </comment>
80 </elem>
81 <elem name="status" type="ProcessingStatus" multiplicity="1">
82 <comment>The result of the processor use, typically success or failure.</comment>
83 </elem>
84 </struct>
85
86 <!--Position Report Msg-->
87 <struct name="PositionReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/posrpt"'>
88 <comment>
89 Usage message reports position information produced by HPE.
90 </comment>
91 <elem name="position" type="HPE.Spheroid" multiplicity="1">
92 <comment>The 2D/3D position reported. </comment>
93 </elem>
94 <elem name="speed" type="int16" multiplicity="1">
95 <tag name="unit" value="cm/sec"/>
96 <comment>The observed speed. O if not known.</comment>
97 </elem>
98 <elem name="heading" type="int16" multiplicity="1">
99 <tag name="unit" value="degrees"/>
100 <comment>Observed heading relative true north (azimuth).</comment>
101 </elem>
102 <elem name="veracity" type="byte" multiplicity="1">
103 <comment>
104 Veracity defines the validity of the measurement in the range between 0 and 100.
105 A high score means the estimate is deemed valid and more reliable than a lower score.
106 If no veracity scoring is performed, this will have a value of 255
107 </comment>
108 </elem>
109 <elem name="confidence" type="byte" multiplicity="1">
110 <comment>The estimate confidence. Valid range is 0 to 100</comment>
111 </elem>
112 <elem name="calctype" type="string" multiplicity="1">
113 <comment>
114 Positioning calculation stereo type specifier (hybrid, cellular, slam, etc.). If not defined set to "".
115 </comment>
116 </elem>
117 <elem name="obstype" type="ObservationType" multiplicity="1">
118 <comment>The last observation type used to create the estimate.</comment>
119 </elem>
120 </struct>
121
122 </namespace>
123 </specification>
HPE/V1.2/HpeWiFi.xid.xml 0 → 100644
1 <?xml version="1.0" encoding="UTF-8" ?>
2
3 <specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
4 xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6 xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
7 identity="HpeWiFi.xid.xml">
8 <title>HPE Wi-Fi Data Definition</title>
9 <comment>File contains data definitions observation datatypes.</comment>
10
11 <import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
12 <import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
13
14 <namespace name="HPE.WiFi">
15 <using namespace="Tensor"/>
16 <using namespace="HPE"/>
17
18 <array name="SSID" type="int8" size="33">
19 <comment>ssid string of wifi access point</comment>
20 </array>
21
22 <struct name="WiFiRssi" type="ObservationEpoch" pack="true" rttkey="HPE.ObservationType.WIFI_RSS">
23 <comment>Wi-Fi RSSI observation</comment>
24 <elem name ="rssi" type="uint8" multiplicity="1">
25 <tag name="unit" value="-dBm"/>
26 <comment>RSS signal measured value(used as negative). </comment>
27 </elem>
28 <elem name ="macaddr" type="mac48" multiplicity="1">
29 <comment>Access point mac address</comment>
30 </elem>
31 </struct>
32
33 <struct name="WiFiRssiExt" type="WiFiRssi" rttkey="HPE.ObservationType.WIFI_RSS_EXT">
34 <comment>Extension of the WifiRssi data structure</comment>
35 <elem name="ssid" type="SSID" multiplicity="1">
36 <comment>ssid of the wifi access point</comment>
37 </elem>
38 <elem name="freq" type="float32" multiplicity="1">
39 <comment>Radio frequency of the Wifi Access point</comment>
40 </elem>
41 <elem name="uncert" type="float32" multiplicity="1">
42 <comment> uncertainty of the rssi measurements</comment>
43 </elem>
44 </struct>
45
46 </namespace>
47 </specification>
ILP/V1.2/ApiBase.xid.xml 0 → 100644
1 <?xml version="1.0" encoding="UTF-8" ?>
2
3 <specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
4 xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6 xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
7 identity="ApiBase.xid.xml">
8
9 <title>ILP Services API Base Definitions</title>
10 <comment>
11 This document defines the common types API service interface for the ILP and Simultaneous Localization
12 and Mapping (SLAM) services definitions. The service provides access to ILP and SLAM technologies for position
13 calculation for devices and services communicating via standard
14 IP based protocols. The API currently supports XMF and JSON wire formats.
15 </comment>
16
17 <import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
18 <import ref="https://xid.location.studio/Tensor/V1.0.0/Common.xid.xml" local="Definitions.xid.xml" />
19 <import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
20 <import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
21 <import ref="https://xid.location.studio/HPE/V1.2/HpeCellular.xid.xml" local="HpeCellular.xid.xml" />
22 <import ref="https://xid.location.studio/HPE/V1.2/HpeWiFi.xid.xml" local="HpeWiFi.xid.xml" />
23
24 <namespace name="ILP">
25 <using namespace="HPE"/>
26 <using namespace="Tensor"/>
27
28
29 <!--
30 *******************************
31 *InputBase Type Definition
32 *******************************
33 -->
34 <struct name="InputBase" >
35 <comment>Base input fields for operations supporting asynchronous transaction information.</comment>
36 <elem name="directive" multiplicity="0..*" type="NameValue">
37 <comment>
38 A set of directives to influence processing.
39 </comment>
40 </elem>
41
42 <elem name="devid" multiplicity="1" type="string">
43 <comment>
44 Required device identifier, that provides a consistent multi-transaction identifier
45 for a device or equivalent (e.g. service identifier) providing the data. Any errors or issues resulting from processing the data will include this identifier
46 in the system logs, providing traceability. Identifier should be unique.
47 </comment>
48 </elem>
49
50 <elem name="etid" multiplicity="0..1" type="string">
51 <comment>
52 Optional external transaction identifier for the caller to uniquely identify and track
53 the transaction and corresponding results. These identifiers will appear in the
54 ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
55 and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
56 the ILP system.
57 </comment>
58 </elem>
59 </struct>
60
61
62 <!--
63 *******************************
64 *OutputBase Type Definition
65 *******************************
66 -->
67 <struct name="OutputBase" >
68 <comment>Base output fields common to operations supporting asynchronous returning transaction information.</comment>
69 <elem name="devid" multiplicity="0..1" type="string">
70 <comment>
71 Device identifier provided at operation input, provides a consistent identifier
72 for a device or equivalent (e.g. service identifier) providing the data. Any errors or issues resulting from processing the data will include this identifier
73 in the system logs, providing traceability.
74 </comment>
75 </elem>
76
77 <elem name="etid" multiplicity="0..1" type="string">
78 <comment>
79 Optional external transaction identifier for the caller to uniquely identify and track
80 the transaction and corresponding results. These identifiers appear in the
81 ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
82 and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
83 the ILP system.
84 </comment>
85
86 </elem>
87
88 <elem name="resultcode" type="ResultCode" multiplicity="1" >
89 <comment>Result of the operation.</comment>
90 </elem>
91
92 <elem name="errinfo" type="Tensor.string" multiplicity="0..1">
93 <comment>Error information if result was not success.</comment>
94 </elem>
95
96 </struct>
97
98 </namespace>
99 </specification>
ILP/V1.2/IlpApiBase.xid.xml 0 → 100644
1 <?xml version="1.0" encoding="UTF-8" ?>
2
3 <specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
4 xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6 xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
7 identity="IlpApiBase.xid.xml">
8
9 <title>ILP Hybrid Positioning Services API Base Definitions</title>
10 <comment>
11 This document defines the common types API service interface for the IoT Location Platform (ILP).
12 The service provides hybrid position calculation for devices and services communicating
13 via standard IP based protocols. The API currently supports XMF and JSON wire formats.
14 </comment>
15
16 <import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
17 <import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
18 <import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
19 <import ref="https://xid.location.studio/HPE/V1.2/HpeCellular.xid.xml" local="HpeCellular.xid.xml" />
20 <import ref="https://xid.location.studio/HPE/V1.2/HpeWiFi.xid.xml" local="HpeWiFi.xid.xml" />
21
22 <namespace name="ILP">
23 <using namespace="HPE"/>
24 <using namespace="Tensor"/>
25
26
27 <!--
28 *******************************
29 *IlpInputBase Type Definition
30 *******************************
31 -->
32 <struct name="IlpInputBase" >
33 <comment>Base input fields for operations supporting asynchronous transaction information.</comment>
34 <elem name="idDevice" multiplicity="1" type="string">
35 <comment>
36 Required device identifier, that provides a consistent multi-transaction identifier
37 for a device or equivalent (e.g. service identifier) providing the data. Any errors or issues resulting from processing the data will include this identifier
38 in the system logs, providing traceability. Identifier should be unique.
39 </comment>
40 </elem>
41
42 <elem name="idTransaction" multiplicity="0..1" type="string">
43 <comment>
44 Optional transaction identifier for the caller to uniquely identify and track
45 the transaction and corresponding results. These identifiers will appear in the
46 ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
47 and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
48 the ILP system.
49 </comment>
50 </elem>
51
52 <!-- THis is future, don't uncomment until design issues resolved. M. Mathews/s. Hines 161130
53 <elem name="urlCallback" multiplicity="0..1" type="string">
54 <tag key="life-cycle" value="future" />
55 <comment>
56 Optional asynchronous callback used to callback client servers during long operations. Not all
57 interfaces may support this.
58 </comment>
59 </elem>
60 -->
61 </struct>
62
63
64 <!--
65 *******************************
66 *IlpOutputBase Type Definition
67 *******************************
68 -->
69 <struct name="IlpOutputBase" >
70 <comment>Base output fields common to operations supporting asynchronous returning transaction information.</comment>
71 <elem name="idDevice" multiplicity="1" type="string">
72 <comment>
73 Device identifier provided at operation input, provides a consistent identifier
74 for a device or equivalent (e.g. service identifier) providing the data. Any errors or issues resulting from processing the data will include this identifier
75 in the system logs, providing traceability.
76 </comment>
77 </elem>
78
79 <elem name="idTransaction" multiplicity="0..1" type="string">
80 <comment>
81 Optional transaction identifier for the caller to uniquely identify and track
82 the transaction and corresponding results. These identifiers appear in the
83 ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
84 and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
85 the ILP system.
86 </comment>
87 </elem>
88
89 <!-- THis is future, don't uncomment until design issues resolved. M. Mathews/s. Hine 161130
90 <elem name="urlCallback" multiplicity="0..1" type="string">
91 <tag key="life-cycle" value="future" />
92 <comment>
93 Optional asynchronous callback used to callback client servers during long operations. Not all
94 interfaces may support this.
95 </comment>
96 </elem>
97 -->
98 </struct>
99
100
101 </namespace>
102 </specification>
ILP/V1.2/IlpAssistanceApi.xid.xml 0 → 100644
1 <?xml version="1.0" encoding="UTF-8" ?>
2
3 <specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
4 xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6 xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
7 identity="IlpAssistanceApi.xid.xml">
8 <title>ILP Assistance Services</title>
9 <comment>
10 This document defines the positioning assistance service interface for the IoT Location Platform (ILP).
11 The service provides assistance data supporting GNSS and other positioning technologies for devices
12 and services communicating via standard IP based protocols. The API currently supports XMF and JSON wire formats.
13 </comment>
14
15 <import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
16 <import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
17 <import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
18 <import ref="https://xid.location.studio/ILP/V1.2/IlpApiBase.xid.xml" local="IlpApiBase.xid.xml" />
19
20 <namespace name="ILP">
21 <using namespace="HPE"/>
22 <using namespace="Tensor"/>
23
24 <!--
25 *******************************************************
26 GnssData input/ouput structure declarations.
27 *******************************************************
28 -->
29 <!-- GnssDataInput structure -->
30 <struct name="GnssDataInput" type="IlpInputBase">
31 <comment>ILP.Assistance.GnssData input request data.</comment>
32
33 <!-- Define internal data structure -->
34 <struct name="RequestSpec">
35 <comment>Specifies the data request for each constellation type.</comment>
36 <elem name ="constellation" type="HPE.Gnss.Constellation" multiplicity="1">
37 <comment>Specifies the constellation of interest.</comment>
38 </elem>
39 <elem name="directive" multiplicity="0..*" type="NameValue">
40 <comment>
41 A set of directives to influence processing.
42 </comment>
43 </elem>
44 <elem name="minId" multiplicity="0..1" type ="uint8" default="0">
45 <comment>
46 Specifies the minimum satellite ID to return constellation data.
47 </comment>
48 </elem>
49 <elem name="maxId" multiplicity="0..1" type ="uint8" default="255">
50 <comment>
51 Specifies the maximum satellite ID to return constellation data.
52 </comment>
53 </elem>
54 <elem name="AssistData" multiplicity="1..*" type ="HPE.Gnss.AssistanceData">
55 <comment>
56 Specifies the types of constellation assistance data to return.
57 </comment>
58 </elem>
59 </struct>
60
61 <!-- Define input elements.-->
62 <elem name="epoch" multiplicity="0..1" type="datetime">
63 <comment>
64 Optional epoch for which the data is valid. Leave unspecified if the current epoch is desired.
65 </comment>
66 </elem>
67
68 <elem name="encoding" multiplicity="0..1" type="EncodingFormat" default="0">
69 <comment>
70 ConstellationData encoding format for the response. This field is carried into
71 GetAssistanceData_output.encCon and GetGnssAlmanacs_output.conData will be encoded
72 in this format. If not specified the "native" format of the protocol is used.
73 </comment>
74 </elem>
75
76 <elem name="location" multiplicity="0..1" type="Shape">
77 <comment>
78 Optional specification of the location to compute assistance data. If not specified
79 all available asistance data will be provided.
80 </comment>
81 </elem>
82
83 <elem name="elmask" multiplicity="0..1" type="int8" default="-90">
84 <comment>
85 Optional, specifies the elevation cutoff mask relative to the current
86 location in degrees. If not specified or -90, all values within the specified satellite ID ranges are returned.
87 </comment>
88 <tag name="unit" value="degrees"/>
89 </elem>
90
91 <elem name="Request" multiplicity="1..*" type="RequestSpec">
92 <comment>Specifies the requested data. One specification is required, multiple can be processed simultaneously.</comment>
93 </elem>
94 </struct>
95
96 <!-- GnssDataOutput structure -->
97 <struct name="GnssDataOutput" type="IlpOutputBase">
98 <comment>ILP.Assistance.GnssData output structure. </comment>
99
100 <elem name="resultcode" multiplicity="1" type="ResultCode">
101 <comment>
102 Result of GnssData operation.
103 If resultcode is not success, encCon and constellation data will not be present.
104 </comment>
105 </elem>
106
107 <elem name="encoding" multiplicity="0..1" type="EncodingFormat" default="0">
108 <comment>
109 Constellation Data encoding format. Data can be provided in a different encoding format
110 than the native protocol format. This is carried over from input.
111 If not present, the data is in the native protocol format (e.g. XMF, JSON).
112 </comment>
113 </elem>
114
115 <elem name="assistdata" multiplicity="0..*" type ="HPE.Gnss.ConstellationData" encoding="encoding">
116 <comment>
117 The list of ConstellationData encoded in the format specified by encoding.
118 </comment>
119 </elem>
120 </struct>
121
122
123 <!--
124 *******************************************************
125 ILP GNSS Assistance Data Service Interface.
126 *******************************************************
127 -->
128 <interface name="Assistance">
129 <comment>Assistance data interface functions.</comment>
130
131 <operation name="Gnss">
132 <comment>Returns caller requested GNSS assistance data.</comment>
133 <input name="Input" type="GnssDataInput" sid="0x1018"/>
134 <output name="Result" type="GnssDataOutput" sid="0x1019"/>
135 </operation>
136
137 </interface>
138
139 </namespace>
140 </specification>
ILP/V1.2/IlpSubmissionApi.xid.xml 0 → 100644
1 <?xml version="1.0" encoding="UTF-8" ?>
2
3 <specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
4 xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6 xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
7 identity="IlpSubmissionApi.xid.xml">
8 <title>ILP Submission API</title>
9 <comment>
10 This document defines a lightweight Observation Submission API for submitting ILP compatible observation
11 data without invoking the full get position operation.
12 </comment>
13
14 <import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
15 <import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
16 <import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
17 <import ref="https://xid.location.studio/HPE/V1.2/HpeCellular.xid.xml" local="HpeCellular.xid.xml" />
18 <import ref="https://xid.location.studio/HPE/V1.2/HpeWiFi.xid.xml" local="HpeWiFi.xid.xml" />
19 <import ref="https://xid.location.studio/ILP/V1.2/IlpApiBase.xid.xml" local="IlpApiBase.xid.xml" />
20
21 <namespace name="ILP">
22 <using namespace="HPE"/>
23 <using namespace="Tensor"/>
24
25
26 <!-- SubmitInput structure definition.
27 Note: all the tags are defined. These have to
28 match CalculateInput tags of the same name.
29 -->
30 <struct name="PositionInfo" type="IlpInputBase" >
31 <comment>Used as ILP.Submission.PositionInfo input.</comment>
32
33 <elem name="state" multiplicity="0..1" type="StateInfo" ord="90">
34 <comment>
35 Optional position information.\n
36 At least one of observations or state is required,
37 otherwise there is insufficient data to process.
38 </comment>
39 </elem>
40
41 <elem name="directive" multiplicity="0..*" type="NameValue" ord="87">
42 <comment>
43 A set of directives to influence processing.
44 </comment>
45 </elem>
46
47 <elem name="encObs" multiplicity="0..1" type="EncodingFormat" default="0" ord="88">
48 <comment>
49 Observation set encoding format. Observations may be passed to the service in
50 an encoding format different than that outer wire format.
51 </comment>
52 </elem>
53
54 <elem name="observations" multiplicity="0..1" type="ObservationSet" encoding ="encObs" ord="89">
55 <comment>
56 Optional Set of observation data encoded in the format specified by encObs.\n
57 At least one of observations or state is required,
58 otherwise there is insufficient data to process.
59 </comment>
60 </elem>
61 </struct>
62
63 <!--
64 *******************************************************
65 Observation Submission API
66 *******************************************************
67 -->
68 <interface name="Submission">
69 <comment>Interface for submitting data to ILP. </comment>
70
71 <operation name="PositionInfo">
72 <comment>
73 Interaction submits position and observation data.\n
74 There is no response besides bearer response codes.
75 </comment>
76 <input name="Input" type="PositionInfo" sid="0x101E"/>
77 </operation>
78 </interface>
79 </namespace>
80 </specification>
README.md
...@@ -5,9 +5,41 @@ This is a public repo containing published XID (Xtensible Interface Definition) ...@@ -5,9 +5,41 @@ This is a public repo containing published XID (Xtensible Interface Definition)
5 5
6 ---------- 6 ----------
7 7
8 ## State ##
9
10 * *In Process* means these are currently being edited
11 * *Stable* means they are not changing (but can have documentation changes)
12 * *Decrecated* means it is going away soon
13 * *Retired* means it is gone (no systems support the API)
14
15 ### In Process ###
16
17 * HPE/V1.2/*
18 * ILP/V1.2/*
19 * ILP/SLAM/V1.0.0_alpha/*
20
21 ### Stable ###
22
23 * schema/V1.0.0/*
24 * Tensor/V1.0.0/*
25 * HPE/V1.1.1/*
26 * HPE/CommonDefs/V1.1.1/*
27 * ILP/V1.1.1/*
28
29 ### Decrecated ###
30
31 N/A
32
33 ### Retired ###
34
35 N/A
36
37 ---
38 ---
39
8 ## Naming conventions ## 40 ## Naming conventions ##
9 41
10 Besides XID specs written in XML, there is a new concept of Concrete Interface Definitions (CID). These are complete specifications (no imports) that will have their own schema. XID and CID files can be written in XML, JSON, or XMF (if you are really the hardcore type person), XID CG should be able to input or output in these formats. Given that, the filename convention will be : 42 XID specs are written in XML, but there is a new concept of Concrete Interface Definitions (CID). These are complete, single-source, full-qualified specifications (no imports) that will have their own schema. XID and CID files can be written in XML, JSON, or XMF (if you are really the hardcore type person), XIDCG will be able to input or output in these formats. Given that, the filename conventions reflect this future :
11 43
12 **[filename].[xid|cid].[xml|json|xmf]** 44 **[filename].[xid|cid].[xml|json|xmf]**
13 45
...@@ -19,6 +51,11 @@ XSD Schemas for the XID/CID should be stored separately and versioned consistent ...@@ -19,6 +51,11 @@ XSD Schemas for the XID/CID should be stored separately and versioned consistent
19 51
20 **/schema/[version]/[specification].xsd** 52 **/schema/[version]/[specification].xsd**
21 53
54 ### [version] ###
55 The [version] specifier should be V{major}.{minor}; for historical reasons the original XIDs have V{major}.{minor}.{bug}
56 We have decided that once published, a structural bug fix is significant to an API and is therefore a {minor} revision ... hence the elimination of {bug}.
57 \<comment>, \<artifact>, \<tag> and other edits to XID/CID and schema files that do not affect the structural integrity of the API can be updated without changing the {major}.{minor} version.
58
22 ## Process ## 59 ## Process ##
23 60
24 Update access to the master branch will be limited. Updates and new XID specs must be added on branches and merged to master via pull requests. Updates to existing XID specification (other than typo and documentation updates), will require updating the version directory. 61 Update access to the master branch will be limited. Updates and new XID specs must be added on branches and merged to master via pull requests. Updates to existing XID specification (other than typo and documentation updates), will require updating the version directory.
......
Styling with Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!