Alternative Schema Update based on TSC Comments #1913
Conversation
Re-sync with OpenAPI master
This commit contains the markup for the Alternative Schema Proposal and some supporting documention. A directory structure is proposed so that the supporting data for a proposal is all in the same place.
Updated the Alternative Schema proposal to follow the Apple SWIFT pattern.
Additional Cleanup to the Alternative Schema Proposal
Moved proposal document up one level. Added numeric pre-fixes to proposal files. Per TSC meeting of April 18, 2019
Fixed broken links and typos. Changed names of the proposal phases based on TSC direction.
|
@cmheazel , thanks. FYI, it looks like this PR has merge conflicts. I'm not sure if you can resolve those or of someone with write access has to assist. Also, it might be helpful to state explicitly that, even after this feature graduates into the OpenAPI specification, tools will not be required to support any alternative schema types. Tools MAY choose to support any of the registered alternative schema types, but support for native OpenAPI schemas is the only requirement for compliance with the OpenAPI specification. There seemed to be some confusion about this, and maybe a false perception that the native OpenAPI Schema Object is being deprecated or replaced by JSON Schema. That might be an eventual, de facto outcome if tools overwhelmingly support JSON Schema, users adopt it, and it becomes the preferred schema format. But that is not goal of introducing alternative schemas. And to the extent that the TSC wants to continue incrementally towards converging OpenAPI Schema with JSON Schema, that work continues on a parallel track. TSC members, I hope I've stated that correctly. Please comment and let me know if I have got the wrong impression. |
|
refs #1532 |
|
The conflicts are due to errors in the original pull request that were corrected in the update. I suggest that someone with write access update master. That should resolve the conflicts. |
| allOf: | ||
| - x-oas-draft-alternativeSchema: | ||
| type: xmlSchema | ||
| location: ./xmlSchema.xsd |
There was a problem hiding this comment.
How to support entities in an xsd? Would this work?
type: xmlSchema
location: schema.xsd#/person
There was a problem hiding this comment.
Whole files only I believe, as it would be tough to support XML Path, JSONPath and Protobufpath wait there is no protobuf path. Better not use paths. :)
There was a problem hiding this comment.
imho location value could support path only for some type. The type could dictate the location patterns.
Not having paths could be problematic.
|
@cmheazel can you just do a |
Agreed. It's been said out loud and on the calls and in PRs, but it should be in the actual proposal somewhere. The first bit of feedback I get when talking about it is "I dont want to have to write schematron code!" 🙄 |
Changes status value
Added { } around cmheazel
Changed "registry" to "registries" in registry URL
Added incorrect hyperlink for for registry in attempt to resolve conflict.
Re-sync with OAI
|
Conflicting files have been deleted. I will submit them in a separate pull request once this PR has been merged.
|
000_OAS-proposal-template.md and 001_Alternative-Schema-Proposal.md were removed to fix conflict when merging back into OAI master.
Resync with OAS 20190722
July 22, 2019
Registry URL was causing a conflict with the master branch.
|
superseded by #1993 |
Changed the proposal stages to Draft, Pilot, Graduated, Abandoned
Fixed broken URLs.
Minor editorial fixes.