Your post deserves a longer response which I will write later, but to just this specific point: this kind of non-compliance is easy to detect, but another kind of much more pernicious non-compliance is possible: having valid values for certain keys associated with a standard, but not actually implementing the semantics which that standard is supposed to imply. For example, what does it mean for a resource to have an owner? I would say something like: no changes can happen to the resource without the explicit consent of the owner. Determining whether a particular resource logic (an arbitrary function) implements these semantics is not even decidable (in the computer science sense), let alone detectable (which to me implies some efficient algorithm).
This “semantic compliance” is the kind of compliance which:
- actually matters for safe interoperability (what the fields are called does not matter), and
- requires some form of formal verification
In particular, let’s imagine what a kind of “semantic standard” of ownership would entail:
- A semantic standard is not associated with a particular named field. Rather, a semantic standard is a test that can tell us, given a defined semantics, that a particular resource logic with respect to that semantics and a particular field, either:
a. implements those semantics (satisfies the standard in all cases)
b. does not implement those semantics (there exists a case where the standard is not satisfied)
c. we don’t know (no proof of either (a) or (b) was provided) - Other parties who rely on correct adherence to these semantic standards would use this test (which will rely on proofs stored in various places, but we can elide those details for now) to determine what to do - for example, how to show state to the user in a UI, or how to show in an intent creation UI what certain fields “mean” (and here the word “owner” would come into play).