Participants

...

Notes

Strictness

• Data type: should allow inference. Adding too much friction to the data exchange process if you fully enforce this.
• Datetime: yes, should require time, with a timezone offset.
  • Cannot rely on norm of "use UTC" - need to require that offset in order to be universally understood.
  • Input/output should be standardized to an ISO format for each read and write.
• JSON schema:
  • Initially supportive, except need to allow (TPDM) extension to be posted when not expected, so that code doesn't need to change between two installations that only differ in that extension.
  • After more discussion, realized the challenges around that exception, and realized again the friction that could result from being strict.
  • Conclusion: consider a hybrid approach of sending a 200 response with a warning message. That is, continue allowing extra properties. (All of the SIS vendors present agreed on this)
• Case sensitivity:
  • PostgreSQL and SQL Server differ in their defaults.
  • Cannot assume case sensitivity is in place. If even one vendor using the API assumes insensitive while using SQL Server, then there can be problems when the data are received in an insensitive fashion.
  • Apparently some SIS vendors like to put everything in caps.
  • Insensitive is the safer approach. 
  • Searches: PostgreSQL indexes can be insensitive, even while the collation remains sensitive. Allows insensitive LIKE. Changing the collation breaks LIKE.
    • We already shipped a product that does not conform. What now?
    • If we allow both, API metadata should state which way the particular implementation goes.
    • Need a POC on ODS/API indexes changes, then consider making permanent change to insensitive. Would we consider that breaking or non-breaking?
  • URI/resource: we may prefer case sensitive routes, but should accept insensitive. Don't treat "/ed-fi/STUDENTS" different from "/ed-fi/students".

Features

• Etag
  • Yes, the value should be in the response body. Pattern: GET all, then check etag against stored value to confirm that nothing has changed.
  • Escalate this feature to a requirement of an Ed-Fi API.

Action Items

•  StephenF to work on formal presentation of proposed changes and determine next steps for formalizing changes.
•  StephenF to report back to the Technical Advisory Group (TAG).