Page History

...

1. Multiple instances of AAI running with entirely separate schemas
2. Scenario where an attribute is changed interactively by the user - system engineer or dev for testing/proof of concept - and then how to commit that change to the schema service to make it permanent
3. Differences between build-time and run-time dependencies - current function, user updates schema file(s) and/or edge rules.  This is a run-time interface to a static configuration.  Even though it can be set/changed at run-time, for Dublin, the schema/edge rules will remain a build-time dependency for the schema service but is a run-time dependency for the internal AAI microservices that consume the schema service.
4. AAI clients that use XSD will consume the schema service artifacts, and will not consume an XSD via REST API
5. What happens when we have conflicts - what conflicts can arise and how they detected and remediated
   1. Auditing on multi-oxm overlap / conflicts
   2. Multi-oxm to split administrative types from inventory types
   3. Does the mutli-oxm which allows the same java-type in more than one file make sense?
6. Impact on history feature - follow up with William Reehil and Robby Maharajh, invite them to next week's call to discuss
   1. Only impacts Chameleon &  Champ, changing how they retrieve the schema information, they would now retrieve from the schema service. How Champ loosens it's constraints is up for discussion.

Proposed Design :

1. A mS called Schema Service will hold and load all the schema (OXM and edge rules)  at start up 
2. The Schema Service will hold and load the custom query document at start up
3. The Schema Service will provide REST  endpoints via GETs such as  /aai/schema-service/{api-version}. Consumer mS, such as resource, traversal should use the updated ingest library to make REST calls to the Schema Service
4. The REST endpoint for providing the schema will support a "format" query parameter which will describe what format it is requested in eg. GET /aai/schema-service/v1/nodes?version={version}&format=OXM
5. The REST endpoints such as /aai/schema-service/v1/nodes?version={version} and /aai/schema-service/v1/edgerules?version={version} will provide a complete schema from multiple files
6. The REST endpoint such as /aai/schema-service/v1/list will provide the list of documents stored 
7. The REST endpoint such as /aai/schema-service/v1/nodes?version={version}, /aai/schema-service/v1/edgerules?version={version} and /aai/schema-service/v1/stored-query will provide the individual document
8. The REST endpoint will provide the associations between documents via query parameter "version"
9. The schema jar will continue to be provided as an artifact for consumers of XSD and POJOs 

...