Proposed Features and Milestones

[stephenfuqua]

The development team would like to define meaningful milestones toward 1.0. These should have the aim of demonstrating a new and important function at the end of the milestone. Any community member should be able to run the software, verify the functionality, and provide feedback on each milestone.

We propose the following initial set of milestones:

Milestone	Functional Goals
0.1	Compliant Discovery API, Descriptor API, and Resource API definition (except GET by query): able to run bulk upload, smoke test. Includes JSON validation based on API schema file. Fake OAuth (1).
0.2	Reference validation, Streaming, and Profiles: rejects POST, PUT, and DELETE requests that would violate referential integrity. Streaming data out. Build basic Profiles support (2).
0.3	GET by query and cascading updates: use search engine or relational DB to fulfill GET by query requests. Support cascading updates on allowed resources.
0.4	Namespace authorization: real OAuth; JWT inspection; duplicate ODS/API's namespace authorization. First release of the Configuration Service.
0.5	Data model flexibility and Concurrency: extensions, choosing between DS 4 and DS 5, swapping data standards at start up (not compile). Dynamic Discovery API definition, based on actual Data Standard/extensions. Full support for eTag-based concurrency.
0.6	Dynamic profiles and multitenancy: full-fledged support for XML-based dynamic profiles, and for ODS/API 7 style multi-tenant routing and database segmentation.
0.7	Ed-org based authorization. (3)
0.8	Change queries.

(1) Discovery API may be partially hard-coded. "Fake OAuth" in milestone 0.1: existing tools expect to be able to authenticate, so we must present an OAuth endpoint of some sort. At this stage, the application can throw away the credentials.
(2) Support of Profiles at this early stage is not truly necessary. However, we need to validate the architecture early on to ensure that the concept of Profiles will be workable.
(3) This is waiting a long time before delivery of critical functionality. Why wait? To give us time to work on the next generation approach to authorization. We need to propose mechanisms and vet carefully with the community.

Other features not yet described:

• Identity API
• Enrollment or Assessment Rostering API
• link definitions in GET requests - probably remove them.
• Snapshots

[vimayya]

0.1 Shall we call out Descriptor API as well here? Could we also callout basic DMS schema made availalbe at this stage? While streaming might be advisable for downstream processes, it's worth noting that on-premise deployments might not be immediately ready for it and may be interested in the DMS schema.
0.2 Does this include full set of 400 and 409 level validations? Profile & Streaming data out is probably not ncessary this early, A POC could suffice.
0.6 In ODS API, there is a concept of multi-tenancy (it maps to having separate EdFi_Config data store per tenant in Tanager), as well as database segmentation options for single tenant deployments. Are they both covered here?

ODS API has a dependency endpoint (not part of the spec) that is useful to API clients (API publisher uses it)

[stephenfuqua]

I've updated the description with some answers and will talk through this in more detail during the sprint review. The "dependency endpoint" is part of the Discovery API.