Skip to content

xid / specs

Go to a project
Toggle navigation
Toggle navigation pinning
Switch branch/tag
README.md 2.65 KB

XID specification repository

This is a public repo containing published XID (Xtensible Interface Definition) specifications. Files on the master branch are published specs.

State

  • In Process means these are currently being edited
  • Stable means they are not changing (but can have documentation changes)
  • Deprecated means it is going away soon
  • Retired means it is gone (no systems support the API)

In Process

  • GeoSpatial/V1.0
  • Tensor/V1.1/*
  • HPE/V1.2/*
  • ILP/V1.2/*
  • ILP/SLAM/V1.0.0_alpha/*
  • HPE/V2.0/*

Stable

  • schema/V1.0.0/*
  • Tensor/V1.0.0/*
  • HPE/V1.1.1/*
  • HPE/CommonDefs/V1.1.1/*
  • ILP/V1.1.1/*

These two versions are historical copies that work with the old code generator. The V1.1.1 versions above were updated for the new code generator. The changes are related to enum defaults; new code generator requires literal name and does not accept numerical value.

  • HPE/V1.1.1_orig/*
  • ILP/V1.1.1_orig/*

Deprecated

Retired

N/A

Naming conventions

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]

Specifications stored in the published repo may have a packaging structure that is independent of namespace (not really recommended though), thus path reference to a definition would be :

{[dir1]{/[dir2]…{/dirN}}}/[version]/[filename].[xid|cid].[xml|json|xmf]

XSD Schemas for the XID/CID should be stored separately and versioned consistently with the pattern :

/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.