This may be outside of the scope of this particular effort,
but a data contract should, ideally,
also specify
a) expiration terms
b) additive vs destructive changes schema handling obligations.
c) there is a benefit of describing the schema right in the contract, but
there are also benefits of referring to a data dictionary, allowed query requests, etc
d) Clearly, some interactions are protocol-based rather than an API call. (Eg FIX protocol, SIP protocol).
It would be great if data contract spec included these kinds of interactions as well.
e) there should be reference to data classification models (to help with compliance-related data management).
f) there should be labels allowing consumers to establish data lineage and provenance (this may be more relevant for internal / within large enterprise use cases). This is important to establish business ownership of the data, and who is the technical custodian of the data.
This may be outside of the scope of this particular effort, but a data contract should, ideally, also specify
a) expiration terms
b) additive vs destructive changes schema handling obligations.
c) there is a benefit of describing the schema right in the contract, but there are also benefits of referring to a data dictionary, allowed query requests, etc
d) Clearly, some interactions are protocol-based rather than an API call. (Eg FIX protocol, SIP protocol). It would be great if data contract spec included these kinds of interactions as well.
e) there should be reference to data classification models (to help with compliance-related data management).
f) there should be labels allowing consumers to establish data lineage and provenance (this may be more relevant for internal / within large enterprise use cases). This is important to establish business ownership of the data, and who is the technical custodian of the data.