Are "complex attributes" in an Extension redundant?

[balazsdukai]

One of the three ways that a CityJSON can be extended is adding "complex attributes". The example on this shows how to do this, by adding a JSON object as an attribute value.

But the specs technically allow JSON objects as attribute values (or it doesn't disallow it at least). The schema also defines the "attributes" property as an "object".

Then the only benefit I see in an Extension for this case is that one can require certain CityObject attributes. But the core specs already allow "complex attributes", one does not necessarily need the an extension for those.

Thus, this case of extending a CityJSON technically becomes very similar, or the same as prescribing extra root properties.

So I propose to reword the part on "complex attributes". I think we should remove this "complex" topic completely and say that the purpose of an extension (in these cases) is to document and validate domain-specific data schemas, require certain properties, attributes.

[clausnagel]

I think it's good to get clarification on this. My understanding of the current spec is that you can only add attributes with simple types to a city object on-the-fly. Attributes with complex types (array, object) should rather be defined in an extension first (although this is not required technically).

[cportele]

My understanding of the current spec is that you can only add attributes with simple types to a city object on-the-fly.

It is not my understanding that additional attributes must have simple types, the specification does not state this.

I also would not see why such a restriction should be added. If a tool cannot process arrays or objects, it can/will ignore the attribute.

[hugoledoux]

The interpretation of @cportele is correct. Any attributes (also complex/nested) can be added to a CityJSON file.

A new attribute in an Extension was added so that if someone wants to have a specific nested structure for existing City Object, then she can document it. However, an attribute cannot be made mandatory. Only if say you use an Extension with the extra attribute "+potato", then if one city object in the file has that attribute then it must conforms to the schema in the Extension.

If you define a new City Object, then you can enforce the presence of a specific attributes by using "required", like this for instance:

  "extraCityObjects": {
    "+GenericCityObject": {
      "allOf": [
        { "$ref": "cityobjects.schema.json#/_AbstractCityObject" },
        {
          "properties": {
            "type": { "enum": [ "+GenericCityObject" ] },
            "attributes": {
              "type": "object",
              "properties": {
                "my-attribute": { "type": "string" }
              },
              "required": ["my-attributes"]
            },
            "geometry": {
              "type": "array",
              "items": {
                "oneOf": [
                  { "$ref": "geomprimitives.schema.json#/MultiPoint" },
                  { "$ref": "geomprimitives.schema.json#/MultiLineString" },
                  { "$ref": "geomprimitives.schema.json#/MultiSurface" },
                  { "$ref": "geomprimitives.schema.json#/CompositeSurface" },
                  { "$ref": "geomprimitives.schema.json#/Solid" },
                  { "$ref": "geomprimitives.schema.json#/MultiSolid" },
                  { "$ref": "geomprimitives.schema.json#/CompositeSolid" },
                  { "$ref": "geomprimitives.schema.json#/GeometryInstance" }
                ]
              }
            }
          },
          "required": [ "type", "geometry" ]
        }
      ]
    }
  }

But I agree with @balazsdukai : complex is not necessary in the specs, and we should just say that it is to document specific attributes related to the Extension.