Init implementation for the Open API validation#125
Conversation
| /// <summary> | ||
| /// Extension name MUST start with "x-". | ||
| /// </summary> | ||
| private static readonly ValidationRule<IOpenApiExtensible> ExtensionNameMustStartWithXDollar = |
There was a problem hiding this comment.
XDollar? Do you mean XDash?
|
@xuzhg I understand why a developer should be able to create validation for extensions, however I'm not sure why we would want to be able to create custom validation for standard elements. Do you have any examples of this? |
|
@darrelmiller I don't mean to create custom validation, I mean to create custom rule. For example, some customers want to make sure all the path item name meet a pattern, they can create their own rules to validate. |
|
@xuzhg Creating rules that validate OpenAPI documents against some kind of business specific guidelines feels out of scope for the core library to me. Is there some specific stuff that you want to be able to do for OData that is driving this? |
|
If you don't think the Core lib should have the ability to extend its functionality for the validation. We can just make the However, the whole rule/ruleset structural makes us easy to add the validation logic for the DOM classes. |
|
@darrelmiller @PerthCharern I don't see It's in scope of Preview. Let's have a discussion after that. |
|
Darrel, I don't think extending rules is out of scope per se. One purpose of the core + readers libs is to be the "base" for other things that can be built (e.g. more types of readers), and in this case, types of validation rules. Given that we make the "default rule set" public and with the overload Sam is providing for the entry point, I think we can allow our customers to build their own rules if needs be. They might want to restrict certain sets of strings (path strings, etc.) to enforce consistency just among their sets of APIs. In reply to: 351419521 [](ancestors = 351419521) |
|
I understand though that this extensibility is kind of a stretch (since extensions in other dimensions like the reader still adheres strictly to OpenAPI spec), but I don't see the harm of providing this potentiality. In reply to: 351804977 [](ancestors = 351804977,351419521) |
| internal void Pop() | ||
| { | ||
| this._path.Pop(); | ||
| } |
There was a problem hiding this comment.
Can we make _path a property and simply call Push/Pop on _path itself? I don't think we need to make these methods on the context.
There was a problem hiding this comment.
@PerthCharern I make them as internal and the methods itself can let me coding less character. 😆
| /// <returns>The error string.</returns> | ||
| public override string ToString() | ||
| { | ||
| return "ErroCode: " + ErrorCode + ", " + ErrorPath + " | " + ErrorMessage; |
There was a problem hiding this comment.
"ErroCode: " + ErrorCode + ", " + ErrorPath + " | " + ErrorMessage; [](start = 19, length = 67)
This is a little awkward. Maybe we don't need this?
There was a problem hiding this comment.
Don't you think it's helpful for debug?
|
@PerthCharern Thanks! Ok, Let me continue on this PR (even though I think #133 is better. 😆 ). |
|
@PerthCharern @darrelmiller I have to close this because the origin link failed. I created a new PR to continue: #152 |
3 participants
@PerthCharern @darrelmiller
I want to implement the validation logic for the Open API element. Here's my design (it's not finished).
General design:
Can validation each part individually. for example, Developer create a object, he can call the validate api to validate the created object.
Validate rule can be customized. For example, developer can create their own validation rules.
Detail:
OpenApiElementValidator.cs has the public apis
.\Validations\Visitors has the visitor classes for each element.
.\Validations\Rules has the rule classes for each element.
Please have a look and give me some feedback.