Consider the scope of test vectors

[KendallWeihe]

Originally from this PR https://github.com/TBD54566975/tbdex/pull/269

Generally wondering whether our current vectors provide any additional utility compared to simply writing tests that:

• create a specific message or resource kind
• use the json schemas to validate said message or resource
• assert no validation errors.

not discounting the value of vectors in general. moreso just feeling like our current vectors feel a bit duplicative given that the json schemas could act as the source of truth for message structure. I realize we're also doing sig verification as part of our consuming the current vectors but we may be able to narrow the scope of the vectors themselves. anyway, random thoughts. will open an issue to track if relevant

This ticket is intended to open discourse around this topic. I'll start out with a proposal:

• Rely on JSON Schemas for "data structure testing"
• Rely on test vectors for "value testing"
  • example: cryptographic signatures
  • example: multistep behavioral expectations, AKA stateful values, wherein a value in one message relies on a value in a previous message, such as the metadata.protocol first established in the RFQ whereafter it must be identical

("data structure testing" and "value testing" are my own made-up terms)

Argument in favor of: JSON Schemas are widely adapted, and which we lean into in many cases already, so our test vectors are a roll-our-own solution which is generally unfavorable.

Argument in favor of: JSON Schemas are used in production environments for runtime so we have a stronger assurance to the correctness (higher stakes implies stronger assurance).

Argument opposed to: JSON Schemas don't solve all of our problems, and introducing them adds an additional component of dimensionality and therefore complexity.

Questions:

• Will the specification doc itself directly link-to our JSON Schemas?
• We recently ran into a cross-language (client in tbdex-kt and server in tbdex-js) incompatibility across the http-api implementations; could we somehow codify test vectors for the HTTP APIs? Would we introduce something new?

[KendallWeihe]

This is not a priority whatsoever as proposed changes could be made without impacting the tbdex protocol version

[KendallWeihe]

This made me just question: should we also version the tbdex http-api spec? And how would that be implemented? Perhaps we should open a new ticket? Again, not a priority at this moment, but if anyone else agrees, 👍 and/or go ahead and open a new ticket for discussions.

[phoebe-lew]

should we also version the tbdex http-api spec?

No, we contemplated this in the initial versioning proposal and decided against it. The HTTP API is included in the versioning of the overall protocol, so if there are changes to it (new endpoint, removing an endpoint, etc.), it will also result in a version bump. This decision was made to reduce the already numerous version numbers floating around.