Where the bundled schemas differ from the published ones

Finding 3: agvActions[].blockingTypes is declared type array but carries its enum on the array instead of on the items, which no conformant factsheet can satisfy. The enum is moved under items, as the field's own description requires.

Finding 3: agvActions[].blockingTypes is declared type array but carries its enum on the array instead of on the items, which no conformant factsheet can satisfy. The enum is moved under items, as the field's own description requires.

The published file is not valid JSON — it carries a trailing comma — so the comma was removed and nothing else was changed. Finding 5: typeSpecification.required demands 'mobileRobotKinematic', a property the schema never defines and section 7.10 does not use — it names the field 'mobileRobotKinematics'. Required now matches the property and the prose. Finding 6: mobileRobotActions[].pauseAllowed and .cancelAllowed are declared as string, while section 7.10 defines both as boolean and their own descriptions read "True:"/"False:". Both are typed boolean here.

The published file is not valid JSON — it carries a trailing comma — so the comma was removed and nothing else was changed.

The published file is not valid JSON — it carries a trailing comma — so the comma was removed and nothing else was changed.

Finding 28: the actionStatus enum omits 'PAUSED', which section 6.11 lists among the six values and section 7.4 describes as "the action is paused because of a pause instantAction or external trigger" - and which this schema's own description of the field still names. 2.0.0 has it in the enum. A vehicle paused by a startPause has no status to report it with, and the field the fleet controller reads to see the pause take effect is the one the schema forbids. PAUSED is accepted here.

Finding 11: the requestStatus enums of zoneRequest and edgeRequest omit 'QUEUED', which section 6.9 lists among the values the field shall support and section 7.5 allows as a response. A robot answering a queued request has no status to report it with. QUEUED is accepted here; the contradiction is reported to the committee.

The published file is not valid JSON — it carries a trailing comma — so the comma was removed and nothing else was changed.

Finding 10: the PRIORITY and PENALTY branches define their factor as 'priorityFactor ' and 'penaltyFactor ', with a trailing space, while 'required' names them without one. Nothing is rejected and nothing is checked either: the bounds 0.0 to 1.0 apply to a property no message carries, so a priorityFactor of 7.5 passes unremarked. The space is removed, which is what makes the range the standard states apply.

VDA5050 1.1 has no published JSON schema (the official repo first shipped schemas at 2.0.0). Derived from the official 2.1.0 connection schema, whose mandatory fields, types and enumerations 1.1 shares. Reference: vda5050/vda5050 branch release/1.1.0, VDA5050_EN.md.

Derived from the 2.1.0 house schema; VDA5050 1.1 publishes no schemas of its own. One difference read from its own field table (6.9): 1.1 calls the array "instantActions", which 2.0 renamed to "actions".

VDA5050 1.1 has no JSON schema in the official repo (schemas were first published for 2.0.0). Derived from the 2.1.0 house schema: 1.1's mandatory order fields, types and enumerations (blockingType NONE/SOFT/HARD, nodes/edges graph model) are identical to 2.1.0, and 1.1 leaves nodePosition.theta and controlPoint.weight optional exactly as 2.1.0 does. Official reference: vda5050/vda5050 branch release/1.1.0, VDA5050_EN.md section 6.7. zoneSetId is not required: the 1.1 field table (6.7) does not italicise it the way it marks its other optional fields, but its own description reads 'Optional: Some master control systems do not use zones. Do not add to message if no zones are used.' A field a specification tells the sender not to send cannot be mandatory, and every later version has it optional. See docs/analyzer/vda5050-spec-findings.md, finding 25.

VDA5050 1.1 has no JSON schema in the official repo (schemas were first published for 2.0.0). Derived from the 2.1.0 house schema: 1.1's mandatory state fields, types and enumerations are identical to 2.1.0, and 1.1 leaves nodePosition.theta and controlPoint.weight optional exactly as 2.1.0 does (2.0.0 required them). 1.1 has no factsheet topic. Official reference: vda5050/vda5050 branch release/1.1.0, VDA5050_EN.md sections 6.10/6.11. The optional loads array of the 1.1 field table (6.10.6) is modelled too. Two root fields are carried here that the 1.1 document does not name cleanly. The position field is printed 'anyPosition' in the state table, 'agyPosition' in its own object header and 'agvPosition'/'agyPosition'/'ayPosition' in the initPosition row - the name every later version uses, and the one the document itself uses when it references the field, is agvPosition, so that is what is modelled (committee finding 22). Its optional map note is printed 'mapDiscripation' and modelled as mapDescription. The info array is named 'informations' in the 1.1 table while 6.10.4 calls it 'the information array' and 2.0 onwards settled on 'information'; both spellings are accepted rather than judging a robot on which half of its own specification it followed (committee finding 23). The teach-in operating mode is printed 'TEACHIN' in the state's enum row and 'TEACHING' in the OperatingModes table of 6.10.6 that the very same row refers to; both are accepted for the same reason, and 2.0 onwards settled on TEACHIN (committee finding 27).

VDA5050 1.1 has no published JSON schema (the official repo first shipped schemas at 2.0.0). Derived from the official 2.1.0 visualization schema, whose mandatory fields, types and enumerations 1.1 shares. Reference: vda5050/vda5050 branch release/1.1.0, VDA5050_EN.md.