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
<?xml version="1.0" encoding="UTF-8" ?>
<specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
identity="HpeUsage.xid.xml">
<title>HPE Usage Messages</title>
<comment>This file the usage messages produced by the HPE.</comment>
<import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
<import ref="https://xid.location.studio/Tensor/V1.0.0/Logging.xid.xml" local="Logging.xid.xml" />
<namespace name="HPE">
<using namespace="Tensor"/>
<using namespace="Logging"/>
<!--Initialization Report Msg-->
<struct name="InitializationReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/initrpt"'>
<comment>
Message captures HPE initialization data.
</comment>
<elem name="state" type="StateInfo" multiplicity="1">
<comment>
State information.
</comment>
</elem>
</struct>
<!--Observation Report Msg-->
<struct name="ObservationReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/obsrpt"'>
<comment>
Message captures HPE observation data for playback purposes and debugging.
</comment>
<elem name="observations" type="ObservationSet" multiplicity="1">
<comment>
Observation Data provided by the caller.
</comment>
</elem>
<elem name="refdata" type="ReferenceDataSet" multiplicity="0..1">
<comment>
Contains reference data provided by the caller.
</comment>
</elem>
<elem name="directive" multiplicity="0..*" type="Tensor.NameValue">
<comment>
A set of directives to influence processing. Unknown directives are ignored.
</comment>
</elem>
</struct>
<!--TaskReport Msg-->
<struct name="TaskReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/taskrpt"'>
<comment>
Message reports processing task result data. Tasks are any computational elem
within the HPE including calculators, converters, estimators.
</comment>
<elem name="taskid" type="string" multiplicity="1">
<comment>
The unique tasks identifier. A source may have multiple tasks, this field assigns
an identifier that uniquely characterizes what the task was that was accomplished.
</comment>
</elem>
<elem name="start" type="datetime" multiplicity="1">
<comment>
The start time at which the processor is used.
</comment>
</elem>
<elem name="duration" type="uint16" multiplicity="1">
<tag name="unit" value="msec"/>
<comment>
The duration of the processing in msec. This is not meant to be a high
resolution duration monitoring, implement a metric counter for precise timing data.
</comment>
</elem>
<elem name="status" type="ProcessingStatus" multiplicity="1">
<comment>The result of the processor use, typically success or failure.</comment>
</elem>
</struct>
<!--Position Report Msg-->
<struct name="PositionReport" type="Logging.UsageMsg" rttkey='"tpf://hpe/posrpt"'>
<comment>
Usage message reports position information produced by HPE.
</comment>
<elem name="position" type="HPE.Spheroid" multiplicity="1">
<comment>The 2D/3D position reported. </comment>
</elem>
<elem name="speed" type="int16" multiplicity="1">
<tag name="unit" value="cm/sec"/>
<comment>The observed speed. O if not known.</comment>
</elem>
<elem name="heading" type="int16" multiplicity="1">
<tag name="unit" value="degrees"/>
<comment>Observed heading relative true north (azimuth).</comment>
</elem>
<elem name="veracity" type="byte" multiplicity="1">
<comment>
Veracity defines the validity of the measurement in the range between 0 and 100.
A high score means the estimate is deemed valid and more reliable than a lower score.
If no veracity scoring is performed, this will have a value of 255
</comment>
</elem>
<elem name="confidence" type="byte" multiplicity="1">
<comment>The estimate confidence. Valid range is 0 to 100</comment>
</elem>
<elem name="calctype" type="string" multiplicity="1">
<comment>
Positioning calculation stereo type specifier (hybrid, cellular, slam, etc.). If not defined set to "".
</comment>
</elem>
<elem name="obstype" type="ObservationType" multiplicity="1">
<comment>The last observation type used to create the estimate.</comment>
</elem>
</struct>
</namespace>
</specification>
HPE/V1.2/HpeWiFi.xid.xml 0 → 100644
<?xml version="1.0" encoding="UTF-8" ?>
<specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
identity="HpeWiFi.xid.xml">
<title>HPE Wi-Fi Data Definition</title>
<comment>File contains data definitions observation datatypes.</comment>
<import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
<namespace name="HPE.WiFi">
<using namespace="Tensor"/>
<using namespace="HPE"/>
<array name="SSID" type="int8" size="33">
<comment>ssid string of wifi access point</comment>
</array>
<struct name="WiFiRssi" type="ObservationEpoch" pack="true" rttkey="HPE.ObservationType.WIFI_RSS">
<comment>Wi-Fi RSSI observation</comment>
<elem name ="rssi" type="uint8" multiplicity="1">
<tag name="unit" value="-dBm"/>
<comment>RSS signal measured value(used as negative). </comment>
</elem>
<elem name ="macaddr" type="mac48" multiplicity="1">
<comment>Access point mac address</comment>
</elem>
</struct>
<struct name="WiFiRssiExt" type="WiFiRssi" rttkey="HPE.ObservationType.WIFI_RSS_EXT">
<comment>Extension of the WifiRssi data structure</comment>
<elem name="ssid" type="SSID" multiplicity="1">
<comment>ssid of the wifi access point</comment>
</elem>
<elem name="freq" type="float32" multiplicity="1">
<comment>Radio frequency of the Wifi Access point</comment>
</elem>
<elem name="uncert" type="float32" multiplicity="1">
<comment> uncertainty of the rssi measurements</comment>
</elem>
</struct>
</namespace>
</specification>
ILP/V1.2/ApiBase.xid.xml 0 → 100644
<?xml version="1.0" encoding="UTF-8" ?>
<specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
identity="ApiBase.xid.xml">
<title>ILP Services API Base Definitions</title>
<comment>
This document defines the common types API service interface for the ILP and Simultaneous Localization
and Mapping (SLAM) services definitions. The service provides access to ILP and SLAM technologies for position
calculation for devices and services communicating via standard
IP based protocols. The API currently supports XMF and JSON wire formats.
</comment>
<import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
<import ref="https://xid.location.studio/Tensor/V1.0.0/Common.xid.xml" local="Definitions.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCellular.xid.xml" local="HpeCellular.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeWiFi.xid.xml" local="HpeWiFi.xid.xml" />
<namespace name="ILP">
<using namespace="HPE"/>
<using namespace="Tensor"/>
<!--
*******************************
*InputBase Type Definition
*******************************
-->
<struct name="InputBase" >
<comment>Base input fields for operations supporting asynchronous transaction information.</comment>
<elem name="directive" multiplicity="0..*" type="NameValue">
<comment>
A set of directives to influence processing.
</comment>
</elem>
<elem name="devid" multiplicity="1" type="string">
<comment>
Required device identifier, that provides a consistent multi-transaction identifier
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
in the system logs, providing traceability. Identifier should be unique.
</comment>
</elem>
<elem name="etid" multiplicity="0..1" type="string">
<comment>
Optional external transaction identifier for the caller to uniquely identify and track
the transaction and corresponding results. These identifiers will appear in the
ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
the ILP system.
</comment>
</elem>
</struct>
<!--
*******************************
*OutputBase Type Definition
*******************************
-->
<struct name="OutputBase" >
<comment>Base output fields common to operations supporting asynchronous returning transaction information.</comment>
<elem name="devid" multiplicity="0..1" type="string">
<comment>
Device identifier provided at operation input, provides a consistent identifier
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
in the system logs, providing traceability.
</comment>
</elem>
<elem name="etid" multiplicity="0..1" type="string">
<comment>
Optional external transaction identifier for the caller to uniquely identify and track
the transaction and corresponding results. These identifiers appear in the
ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
the ILP system.
</comment>
</elem>
<elem name="resultcode" type="ResultCode" multiplicity="1" >
<comment>Result of the operation.</comment>
</elem>
<elem name="errinfo" type="Tensor.string" multiplicity="0..1">
<comment>Error information if result was not success.</comment>
</elem>
</struct>
</namespace>
</specification>
ILP/V1.2/IlpApiBase.xid.xml 0 → 100644
<?xml version="1.0" encoding="UTF-8" ?>
<specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
identity="IlpApiBase.xid.xml">
<title>ILP Hybrid Positioning Services API Base Definitions</title>
<comment>
This document defines the common types API service interface for the IoT Location Platform (ILP).
The service provides hybrid position calculation for devices and services communicating
via standard IP based protocols. The API currently supports XMF and JSON wire formats.
</comment>
<import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCellular.xid.xml" local="HpeCellular.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeWiFi.xid.xml" local="HpeWiFi.xid.xml" />
<namespace name="ILP">
<using namespace="HPE"/>
<using namespace="Tensor"/>
<!--
*******************************
*IlpInputBase Type Definition
*******************************
-->
<struct name="IlpInputBase" >
<comment>Base input fields for operations supporting asynchronous transaction information.</comment>
<elem name="idDevice" multiplicity="1" type="string">
<comment>
Required device identifier, that provides a consistent multi-transaction identifier
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
in the system logs, providing traceability. Identifier should be unique.
</comment>
</elem>
<elem name="idTransaction" multiplicity="0..1" type="string">
<comment>
Optional transaction identifier for the caller to uniquely identify and track
the transaction and corresponding results. These identifiers will appear in the
ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
the ILP system.
</comment>
</elem>
<!-- THis is future, don't uncomment until design issues resolved. M. Mathews/s. Hines 161130
<elem name="urlCallback" multiplicity="0..1" type="string">
<tag key="life-cycle" value="future" />
<comment>
Optional asynchronous callback used to callback client servers during long operations. Not all
interfaces may support this.
</comment>
</elem>
-->
</struct>
<!--
*******************************
*IlpOutputBase Type Definition
*******************************
-->
<struct name="IlpOutputBase" >
<comment>Base output fields common to operations supporting asynchronous returning transaction information.</comment>
<elem name="idDevice" multiplicity="1" type="string">
<comment>
Device identifier provided at operation input, provides a consistent identifier
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
in the system logs, providing traceability.
</comment>
</elem>
<elem name="idTransaction" multiplicity="0..1" type="string">
<comment>
Optional transaction identifier for the caller to uniquely identify and track
the transaction and corresponding results. These identifiers appear in the
ILP system logs for traceability analysis. The format of the transaction identifier is up to the caller
and can be anything: e.g. [uuid], [id1.subid0], [numerical], etc. This data is never interpreted by
the ILP system.
</comment>
</elem>
<!-- THis is future, don't uncomment until design issues resolved. M. Mathews/s. Hine 161130
<elem name="urlCallback" multiplicity="0..1" type="string">
<tag key="life-cycle" value="future" />
<comment>
Optional asynchronous callback used to callback client servers during long operations. Not all
interfaces may support this.
</comment>
</elem>
-->
</struct>
</namespace>
</specification>
ILP/V1.2/IlpAssistanceApi.xid.xml 0 → 100644
<?xml version="1.0" encoding="UTF-8" ?>
<specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
identity="IlpAssistanceApi.xid.xml">
<title>ILP Assistance Services</title>
<comment>
This document defines the positioning assistance service interface for the IoT Location Platform (ILP).
The service provides assistance data supporting GNSS and other positioning technologies for devices
and services communicating via standard IP based protocols. The API currently supports XMF and JSON wire formats.
</comment>
<import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
<import ref="https://xid.location.studio/ILP/V1.2/IlpApiBase.xid.xml" local="IlpApiBase.xid.xml" />
<namespace name="ILP">
<using namespace="HPE"/>
<using namespace="Tensor"/>
<!--
*******************************************************
GnssData input/ouput structure declarations.
*******************************************************
-->
<!-- GnssDataInput structure -->
<struct name="GnssDataInput" type="IlpInputBase">
<comment>ILP.Assistance.GnssData input request data.</comment>
<!-- Define internal data structure -->
<struct name="RequestSpec">
<comment>Specifies the data request for each constellation type.</comment>
<elem name ="constellation" type="HPE.Gnss.Constellation" multiplicity="1">
<comment>Specifies the constellation of interest.</comment>
</elem>
<elem name="directive" multiplicity="0..*" type="NameValue">
<comment>
A set of directives to influence processing.
</comment>
</elem>
<elem name="minId" multiplicity="0..1" type ="uint8" default="0">
<comment>
Specifies the minimum satellite ID to return constellation data.
</comment>
</elem>
<elem name="maxId" multiplicity="0..1" type ="uint8" default="255">
<comment>
Specifies the maximum satellite ID to return constellation data.
</comment>
</elem>
<elem name="AssistData" multiplicity="1..*" type ="HPE.Gnss.AssistanceData">
<comment>
Specifies the types of constellation assistance data to return.
</comment>
</elem>
</struct>
<!-- Define input elements.-->
<elem name="epoch" multiplicity="0..1" type="datetime">
<comment>
Optional epoch for which the data is valid. Leave unspecified if the current epoch is desired.
</comment>
</elem>
<elem name="encoding" multiplicity="0..1" type="EncodingFormat" default="0">
<comment>
ConstellationData encoding format for the response. This field is carried into
GetAssistanceData_output.encCon and GetGnssAlmanacs_output.conData will be encoded
in this format. If not specified the "native" format of the protocol is used.
</comment>
</elem>
<elem name="location" multiplicity="0..1" type="Shape">
<comment>
Optional specification of the location to compute assistance data. If not specified
all available asistance data will be provided.
</comment>
</elem>
<elem name="elmask" multiplicity="0..1" type="int8" default="-90">
<comment>
Optional, specifies the elevation cutoff mask relative to the current
location in degrees. If not specified or -90, all values within the specified satellite ID ranges are returned.
</comment>
<tag name="unit" value="degrees"/>
</elem>
<elem name="Request" multiplicity="1..*" type="RequestSpec">
<comment>Specifies the requested data. One specification is required, multiple can be processed simultaneously.</comment>
</elem>
</struct>
<!-- GnssDataOutput structure -->
<struct name="GnssDataOutput" type="IlpOutputBase">
<comment>ILP.Assistance.GnssData output structure. </comment>
<elem name="resultcode" multiplicity="1" type="ResultCode">
<comment>
Result of GnssData operation.
If resultcode is not success, encCon and constellation data will not be present.
</comment>
</elem>
<elem name="encoding" multiplicity="0..1" type="EncodingFormat" default="0">
<comment>
Constellation Data encoding format. Data can be provided in a different encoding format
than the native protocol format. This is carried over from input.
If not present, the data is in the native protocol format (e.g. XMF, JSON).
</comment>
</elem>
<elem name="assistdata" multiplicity="0..*" type ="HPE.Gnss.ConstellationData" encoding="encoding">
<comment>
The list of ConstellationData encoded in the format specified by encoding.
</comment>
</elem>
</struct>
<!--
*******************************************************
ILP GNSS Assistance Data Service Interface.
*******************************************************
-->
<interface name="Assistance">
<comment>Assistance data interface functions.</comment>
<operation name="Gnss">
<comment>Returns caller requested GNSS assistance data.</comment>
<input name="Input" type="GnssDataInput" sid="0x1018"/>
<output name="Result" type="GnssDataOutput" sid="0x1019"/>
</operation>
</interface>
</namespace>
</specification>
ILP/V1.2/IlpSubmissionApi.xid.xml 0 → 100644
<?xml version="1.0" encoding="UTF-8" ?>
<specification xmlns="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xid="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://xid.location.studio/schema/V1.0.0/XtensibleInterfaceDefinition.xsd XtensibleInterfaceDefinition.xsd"
identity="IlpSubmissionApi.xid.xml">
<title>ILP Submission API</title>
<comment>
This document defines a lightweight Observation Submission API for submitting ILP compatible observation
data without invoking the full get position operation.
</comment>
<import ref="https://xid.location.studio/Tensor/V1.0.0/Definitions.xid.xml" local="Definitions.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCore.xid.xml" local="HpeCore.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeGnss.xid.xml" local="HpeGnss.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeCellular.xid.xml" local="HpeCellular.xid.xml" />
<import ref="https://xid.location.studio/HPE/V1.2/HpeWiFi.xid.xml" local="HpeWiFi.xid.xml" />
<import ref="https://xid.location.studio/ILP/V1.2/IlpApiBase.xid.xml" local="IlpApiBase.xid.xml" />
<namespace name="ILP">
<using namespace="HPE"/>
<using namespace="Tensor"/>
<!-- SubmitInput structure definition.
Note: all the tags are defined. These have to
match CalculateInput tags of the same name.
-->
<struct name="PositionInfo" type="IlpInputBase" >
<comment>Used as ILP.Submission.PositionInfo input.</comment>
<elem name="state" multiplicity="0..1" type="StateInfo" ord="90">
<comment>
Optional position information.\n
At least one of observations or state is required,
otherwise there is insufficient data to process.
</comment>
</elem>
<elem name="directive" multiplicity="0..*" type="NameValue" ord="87">
<comment>
A set of directives to influence processing.
</comment>
</elem>
<elem name="encObs" multiplicity="0..1" type="EncodingFormat" default="0" ord="88">
<comment>
Observation set encoding format. Observations may be passed to the service in
an encoding format different than that outer wire format.
</comment>
</elem>
<elem name="observations" multiplicity="0..1" type="ObservationSet" encoding ="encObs" ord="89">
<comment>
Optional Set of observation data encoded in the format specified by encObs.\n
At least one of observations or state is required,
otherwise there is insufficient data to process.
</comment>
</elem>
</struct>
<!--
*******************************************************
Observation Submission API
*******************************************************
-->
<interface name="Submission">
<comment>Interface for submitting data to ILP. </comment>
<operation name="PositionInfo">
<comment>
Interaction submits position and observation data.\n
There is no response besides bearer response codes.
</comment>
<input name="Input" type="PositionInfo" sid="0x101E"/>
</operation>
</interface>
</namespace>
</specification>
README.md
......@@ -5,9 +5,41 @@ This is a public repo containing published XID (Xtensible Interface Definition)
----------
## State ##
* *In Process* means these are currently being edited
* *Stable* means they are not changing (but can have documentation changes)
* *Decrecated* means it is going away soon
* *Retired* means it is gone (no systems support the API)
### In Process ###
* HPE/V1.2/*
* ILP/V1.2/*
* ILP/SLAM/V1.0.0_alpha/*
### Stable ###
* schema/V1.0.0/*
* Tensor/V1.0.0/*
* HPE/V1.1.1/*
* HPE/CommonDefs/V1.1.1/*
* ILP/V1.1.1/*
### Decrecated ###
N/A
### Retired ###
N/A
---
---
## Naming conventions ##
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 :
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 :
**[filename].[xid|cid].[xml|json|xmf]**
......@@ -19,6 +51,11 @@ XSD Schemas for the XID/CID should be stored separately and versioned consistent
**/schema/[version]/[specification].xsd**
### [version] ###
The [version] specifier should be V{major}.{minor}; for historical reasons the original XIDs have V{major}.{minor}.{bug}
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}.
\<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.
## Process ##
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!