Catching up here. >From Eduard's doc [1], it seems that at the end of the day, the capability boils down to whether an end point is implemented by the server or not. Therefore, I feel we could simplify things by skipping the categorization/grouping (e.g., tables, views, udfs, etc) and just allow servers to declare whether an end point is implemented or not. We could have a discussion around how to assign identities to endpoints. I think skipping the categorization has some benefits: * It removes one concept that servers and client implementations need to be aware of. It also removes one level of indirection. * It transitively removes the "capability version" concept, since with the capabilities solution, it seems within each category we should group some APIs into versions. It is not clear what the process is around creating versions and what group of APIs qualify as a version. It sounds there will be a dedicated process to create those. * It allows us to future-proof the concept of capabilities since it will be clearly correlated with endpoints and we do not have to come up with new terms for new capabilities and retro-fit them to existing capabilities.
I am trying to see if we could simplify how to think about compatibility in Iceberg since there are quite a set of moving parts such as Iceberg library version number, table format version number, REST spec version number, REST endpoint root version number, etc, all of those interacting with reader, writer, server versions (which is a topic that I think is worth discussing but possibly in another thread). Thanks, Walaa. [1] https://docs.google.com/document/d/1F1xh6SJhS-opgWRe1pPvWh01j8VHNHRocfCCFttKNf0/edit
