-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overlay support spec doc #1598
base: dev
Are you sure you want to change the base?
Overlay support spec doc #1598
Changes from 2 commits
e4ec871
4c4c8ff
5001a73
93db0c6
8020e10
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,106 @@ | ||
# Feature Specification: Overlays Support | ||
|
||
## Objective | ||
Support use of Overlays for enabling developers to enhance existing OpenAPI description files without changing the original file. | ||
|
||
## Problem Statement | ||
Existing OpenAPI documents used for AI plugin creation might lack necessary properties or require modifications for them to provide a high quality AI plugin. Direct editing of the original OpenAPI document is often undesirable or impractical. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not AI plugin, but I'd even say referenced OpenAPI descriptions that participate in the GPTs and Plugins ecosystem. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, you have phrased it better. I'll rephrase in the spec to capture this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why restrict the use-case of overlays to AI plug-ins when OpenAPI.NET library caters to a diverse range of users? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @adhiambovivian has a good point. What sparked this discussion was definitely AI plugins. But it's absolutely true that overlays are more than just for AI plugins, we see it everyday in Kiota. Let's frame it as a more generic scenario and support it with real world examples, like AI plugins, client code generation, etc. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And for the copilot use-cases, could you please provide more specific details about the copilot use-cases? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure @adhiambovivian . For copilot scenarios we might would want to provide instructions to the orchestrator on how to use the certain function (/createSong as an exmaple), add localization, provide information on how to present the response to the user (like using adaptive cards or other rendering) etc. Having the possibility to augment OpenAPI documents with overlays and provide more information to AI orchestratos/Copilot will unclock several scenarios. |
||
|
||
## Solution Overview | ||
Overlays provide a flexible mechanism for extending OpenAPI documents without directly modifying the original files. This allows necessary properties to be added, existing values modified, and the OpenAPI description tailored for effective AI plugin development. | ||
|
||
## Functional Requirements | ||
1. **Overlay File Format Support** | ||
- Support overlay files in accordance with the Overlay Specification (v1.0.0), available at [Overlay Specification](https://github.com/OAI/Overlay-Specification/blob/3f398c6/versions/1.0.0.md). | ||
- Support both YAML and JSON formats for overlay files. | ||
njaci1 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
2. **Overlay Application** | ||
- Apply overlay file to an existing OpenAPI document to produce a hybrid of the overlay file and the original OpenAPI description file without changing the original file. | ||
- Ensure resulting hybrid OpenAPI document remain valid according to the OpenAPI Specification. | ||
|
||
3. **Overlay Operations** | ||
- Support addition, modification, and removal of properties to the target OpenAPI document. | ||
|
||
## Example: Applying Overlay to Modify OpenAPI Description File | ||
|
||
**Original OpenAPI Description File** | ||
|
||
```yaml | ||
openapi: 3.0.0 | ||
info: | ||
title: Sample API | ||
version: 1.0.0 | ||
paths: | ||
/users: | ||
get: | ||
summary: Get a list of users | ||
responses: | ||
'200': | ||
description: Successful response | ||
/users/{id}: | ||
get: | ||
summary: Get a user by ID | ||
parameters: | ||
- name: id | ||
in: path | ||
required: true | ||
description: User ID | ||
responses: | ||
'200': | ||
description: Successful response | ||
``` | ||
|
||
**Overlay File (overlay.yaml)** | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This overlay doesn't use JSON Path to define the structure. Are we saying that this is our MVP for now? Only structured overlays vs. targeted overlays would be supported? https://github.com/OAI/Overlay-Specification/blob/main/versions/1.0.0.md#targeted-overlays I'm honestly OK at this point for either, but make it clear would be better and provide a more appropriate debate! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You can't really separate the two. Targeted overlays use a merge patch at the target. Structured overlays are just the trivial case of targeted. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @sebastienlevert is your question whether we will support either structured or targeted rather than both? We will support both cases. |
||
|
||
```yaml | ||
overlay: 1.0.0 | ||
info: | ||
title: Sample Overlay | ||
version: 1.0.0 | ||
actions: | ||
- target: "$" | ||
update: | ||
info: | ||
x-overlay-applied: sample-overlay | ||
paths: | ||
"/users": | ||
get: | ||
summary: "Retrieve all users" | ||
"/users/{id}": | ||
get: | ||
parameters: | ||
- name: id | ||
description: "Unique identifier of the user" | ||
responses: | ||
'404': | ||
description: "User not found" | ||
``` | ||
|
||
**Resulting OpenAPI document** | ||
|
||
```yaml | ||
openapi: 3.0.0 | ||
info: | ||
title: Sample API | ||
version: 1.0.0 | ||
paths: | ||
/users: | ||
get: | ||
summary: Retrieve all users # Updated summary from overlay | ||
responses: | ||
'200': | ||
description: Successful response | ||
/users/{id}: | ||
get: | ||
summary: Get a user by ID # Unchanged summary from original description | ||
parameters: | ||
- name: id | ||
in: path | ||
required: true | ||
description: Unique identifier of the user # Updated description from overlay | ||
responses: | ||
'200': | ||
description: Successful response | ||
'404': | ||
description: User not found # New response added from overlay | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the spec include customer application and target audience?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have revised the objective statement to try capture the target audience.