Shouldn't we draw the reader's attention to the zero importance of the display order of GeoPose members?

[nicolas-heigvd]

e.g. this object is a valid GeoPose:

{
  "angles": {
    "pitch": 3.30783,
    "yaw": 12.2,
    "roll": 0.04
  },
  "position": {
    "lat": 64.2123,
    "h": 45.02,
    "lon": 7.12552
  }
}

but it's not displayed in a way "we are used to"... hence bringing kind of a cognitive gap with what is written all over the Standard documentation.

Indeed, all over the Standard documentation, we are used -- in the way we named them -- to a unique order for the members of a GeoPose object. For example, for the 6 members of a Basic GeoPose, it is lat, long, and h for the position, which usually comes first, and yaw, pitch and roll for the angles member, which usually comes after.
For both 'parent' objects (position and angles), but especially in the case of angles, we all know that the "order matters".

On the other hand, a stated by the JSON standard, a JSON object is:

(...) an unordered set of name/value pairs.

Source: https://www.json.org/json-en.html

Even so we currently precise the following (p.33):

Yaw, Pitch, and Roll (YPR) angles shall be expressed as three consecutive rotations of a reference frame oriented East-North-Up (ENU) coordinate system (where the coordinate axes East, North, and Up correspond to the axes X, Y, Z) about the local (rotated) axes z, y, and x, applied in that order, corresponding to the conventional Yaw, Pitch, and Roll angles. The unit of measure shall be the degree.

I think it would not be a luxury to point out that the "natural" naming order, especially in its encoding representations, used and applied throughout the Standard document has no importance whatsoever, nor should it, and is given only for the convenience of reading.

[3DXScape]

The requirement on page 33 applies to the correspondence between the two naming conventions for the axes (ENU and XYZ) and the order that the rotations are applied (ZYX). It does not apply to the expression in an encoding, such as JSON. This correspondence does not say anything about the order of the values in a concrete data object. Different encodings have different rules. This should probably be explained explicitly ans described.

[3DXScape]

A related issue is that there is no restriction in the JSON encoding to adding additional members with names outside of the GeoPose standard to JSON GeoPose objects (except for the strict quaternion encoding). This is implicit in the JSON Schema definition and confirmed by the validator but not explicitly stated.

[3DXScape]

This issue and the preceding comments are addressed by a new informative paragraph in the JSON Encoding requirements section:

The JSON encoding is one of many possible ways of implementing a concrete representation of any one or more of the GeoPose Standardization Targets. The specific JSON encoding in this section follows all of the normal rules and conventions of JSON. For example, the order of named properties is not significant and, except in the case of the "strict" Basic-Quaternion object, there is no restriction on adding additional properties not specified in the GeoPose 1.0 Standard. In addition to supporting specific application requirements outside the GeoPose 1.0 scope, this flexibility enables experimentation with useful properties that might be part of a future version of the OGC GeoPose Standard.

[nicolas-heigvd]

Great, thanks @3DXScape!