Proposal: Schema for Outfitting

I’d like to propose an addition to the schema to carry station outfitting data. The proposed change to the schema is below - basically it just adds an optional “modules” property which is an array of integer IDs.

The semantics of the “modules” array is that it represents the availability of outfitting at the station at the time of reporting. Each element in the array is an integer ID which represents a module available in the station’s outfitting screen. An empty “modules” array indicates that the station does not provide outfitting. (Publishers that do not provide outfitting info should therefore omit the “modules” property rather than supply an empty array).

Here is a not-quite exhaustive list of mappings from IDs to modules. I’d like to also propose that the EDDN project own and maintain this list.

Some Q&A:

Q: Why use integer IDs rather than strings (like we do for the commodity names)? A: Using IDs does add an extra level of complexity/indirection, but offers some advantages over strings:

• Less ambiguity - no chance of variant spellings etc.
• Easier for non-English speaking subscribers to translate.
• More robust in the face of updates to E:D - subscribers can process IDs and store them in their databases even if they don’t (yet) know how to display them.
• More compact - about a third of the size of the corresponding strings.

Q: For consistency, why not convert the commodities array to also use integer IDs instead of string names? A: Converting the commodities array to use IDs would be a barrier to adoption. The proposed schema change is narrowly scoped in order to be trivial for subscribers to adopt - subscribers can just handle the proposed schema identically to the v2 schema by ignoring the new “modules” property. They can then choose to exploit the outfitting data encapsulated in the “modules” property later, or not at all.

Q: What about prices? A: Unlike commodities, module prices don’t typically vary from station to station. They may vary according to other factors including the player’s allegiance, ranking, discounts etc but these are necessarily player-specific.

Q: What if the station provides outfitting, but doesn’t have a commodities market? A: The publisher should supply an empty “commodities” array.

Q: What about shipyard info (c.f. issue #16) ? A: A new “ships” property could work in the same way and have similar semantics to the proposed “modules” property. Here is a not-quite exhaustive list of mappings from IDs to ships.

The proposed addition to the schema:

--- schema2.xml 2015-06-02 02:43:35.000000000 +0100
+++ schema3.xml 2015-06-12 00:20:06.000000000 +0100
@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-04/schema#",
-  "id": "http://schemas.elite-markets.net/eddn/commodity/2#",
+  "id": "http://schemas.elite-markets.net/eddn/commodity/3#",
   "type": "object",
   "additionalProperties": false,
   "properties": {
@@ -96,6 +96,15 @@
                       }
                       ]   
           }
+        },
+        "modules": {
+          "type": "array",
+          "additionalProperties": false,
+          "uniqueItems": true,
+          "items": {
+            "type": "integer",
+            "additionalProperties": false
+          }
         }
       },
       "required": [

[Marginal]

Here is a sample message in the proposed schema.

[Marginal]

I’ve updated this table to reflect (I think) a complete list of currently available modules, with fields consistent with the outfitting schema that I’m suggesting in pull request #22.