Open kkuo opened 1 year ago
Adding comment from @GranataJBH
Following up on some of the actions from last week's meeting, my plan is to kick off a discussion in the beta GitHub with the below. Want to get your feedback before making the post. From there, we can start @'ing folks to weigh in. "Starting a discussion to work through what rules we would like to establish around the customization of the SSC API(s). Ultimately, our goal is to provide an API that has a common experience across providers, but acknowledge there will be instances where a TMS may want to customize the experience to a degree in order to meet certain pre-existing conditions. As such, we'd like to propose these general rules that, if others agree, we will continue to refine with additional detail and include as a part of the Standard. General rules for customization: A TMS may make changes to the API Header for both required and optional information and still be considered compliant with the Standard. A TMS may make changes to the API request/response body for optional information and still be considered compliant with the Standard. If a TMS makes changes to the API request/response body with required information, a TMS would be considered non-compliant with the Standard."
Summarizing some conversation over slack on why we can't realistically force TMSs to implement the request and response bodies faithfully and only consider those who did to be in compliance.
There is very little to gain and a lot more downsides to force request and response compliances if we also ignore points 1-4 from above.
Action item: add language saying request body/response extensions by TMS are not guaranteed to be supported in future spec revisions.
Wanted to start a thread on defining and communicating compliance so we're all aligned.
Compliance:
Feature sets:
We can then work with TMSs on increasing their feature set score and their compliance scores over time.