Sean Lilley

Personally I find an explicit `normalized` property to be clearer. Also I'm not sure I would group `normalized` in the value transform category since I think of it as part...

> And one of these requirements here is that `offset` and `scale` may only be present when `normalized` is `true`. `offset` and `scale` can also apply to `FLOAT32` and `FLOAT64`...

One idea: could metadata availability be encoded in implicit tiling? Also CC #136 - storing metadata in external buffers

This CesiumJS PR adds a per-tile availability range: https://github.com/CesiumGS/cesium/pull/8488 - an approach to consider for 3D Tiles Next.

Also see [TileDB](https://docs.tiledb.com/main/) which which has support for sparse data and time dynamic data. CC https://github.com/CesiumGS/3d-tiles/issues/580#issuecomment-982627927.

There are a few capabilities of the older [Batch Table](https://github.com/CesiumGS/3d-tiles/tree/master/specification/TileFormats/BatchTable) that do not have a direct counterpart in [EXT_mesh_features](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_mesh_features): * JSON properties * Properties of mixed types * Class hierarchies...

Also consider having an upgrade path from the older [EXT_feature_metadata](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_feature_metadata) to [EXT_mesh_features](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_mesh_features).

@onsummer yes, that would be a welcome contribution! You might want to wait until version 1.1 is more stable. That should happen in the next few months.

* [ ] Make polyline heights optional. When heights are omitted the polyline should be clamped to the surface by the client.

* [ ] Support textured polygons.