I propose this way for the definition of city object types. The idea is that we can introduce abstract types (denoted as _AbstractType) which define the basic properties of the objects and, then, there is a simple concrete type that include those properties and only adds the type property (e.g., see _AbstractBuilding and Building in 7b94613ba7cde9a99f9b546835ca2d13ca57158b).
There are certain benefits:
We avoid redundancy. In fact, all common attributes of city objects can be in a _AbstractCityObject, which all city objects extend. In addition, for complex types such as BuildingParts we can reuse parts from existing objects (e.g., see ab534166262f34607269ad5e963e49304ad9f54f).
We provide an easy way to extend existing objects through extensions (related to issue #31). If someone wants to add properties to the Building without specifying a new type they can simply extend the Building object. If they want to make a new building type, though, they can extend the _AbstractBuilding and just add their own type property. In any case, they don't have to rewrite all properties of the original class.
As a caveat, though, we can't use the additionalProperties: false option with this mechanism (see why here), therefore we cannot force objects to only have the properties of the schema. There is a workaround, by listing again all "inherited" properties in the last class (explained at the end of this answer). Nevertheless, I believe it's better to just warn users about this through cjio validation, than really forcing them to follow the schema. After all, the whole point of JSON is to be more flexible.
I propose this way for the definition of city object types. The idea is that we can introduce abstract types (denoted as
_AbstractType) which define the basic properties of the objects and, then, there is a simple concrete type that include those properties and only adds thetypeproperty (e.g., see_AbstractBuildingandBuildingin 7b94613ba7cde9a99f9b546835ca2d13ca57158b).There are certain benefits:
_AbstractCityObject, which all city objects extend. In addition, for complex types such asBuildingPartswe can reuse parts from existing objects (e.g., see ab534166262f34607269ad5e963e49304ad9f54f).Buildingwithout specifying a new type they can simply extend theBuildingobject. If they want to make a new building type, though, they can extend the_AbstractBuildingand just add their owntypeproperty. In any case, they don't have to rewrite all properties of the original class.As a caveat, though, we can't use the
additionalProperties: falseoption with this mechanism (see why here), therefore we cannot force objects to only have the properties of the schema. There is a workaround, by listing again all "inherited" properties in the last class (explained at the end of this answer). Nevertheless, I believe it's better to just warn users about this through cjio validation, than really forcing them to follow the schema. After all, the whole point of JSON is to be more flexible.