PyPI - sc-oa - Versions diffs - 0.7.0.14__tar.gz → 0.7.0.16__tar.gz - Mend

sc-oa 0.7.0.14tar.gz → 0.7.0.16tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Potentially problematic release.

This version of sc-oa might be problematic. Click here for more details.

Files changed (162) hide show

{sc_oa-0.7.0.14 → sc_oa-0.7.0.16}/PKG-INFO RENAMED Viewed

@@ -1,11 +1,10 @@
-Metadata-Version: 2.1
+Metadata-Version: 2.4
 Name: sc-oa
-Version: 0.7.0.14
+Version: 0.7.0.16
 Summary: Fork of the OpenAPI (fka Swagger) spec renderer for Sphinx
 Home-page: https://github.com/olivier-heurtier/sphinxcontrib-openapi/tree/mymaster
-Author: Ihor Kalnytskyi
-Olivier Heurtier
-Author-email: ihor@kalnytskyi.com
+Author: Olivier Heurtier
+Author-email: olivier.heurtier@github.com
 License: BSD
 Classifier: Topic :: Documentation
 Classifier: Topic :: Documentation :: Sphinx
@@ -34,3 +33,4 @@ Requires-Dist: m2r2
 Requires-Dist: picobox
 Requires-Dist: deepmerge
 Requires-Dist: setuptools
+Dynamic: license-file

{sc_oa-0.7.0.14 → sc_oa-0.7.0.16}/sc_oa.egg-info/PKG-INFO RENAMED Viewed

@@ -1,11 +1,10 @@
-Metadata-Version: 2.1
+Metadata-Version: 2.4
 Name: sc-oa
-Version: 0.7.0.14
+Version: 0.7.0.16
 Summary: Fork of the OpenAPI (fka Swagger) spec renderer for Sphinx
 Home-page: https://github.com/olivier-heurtier/sphinxcontrib-openapi/tree/mymaster
-Author: Ihor Kalnytskyi
-Olivier Heurtier
-Author-email: ihor@kalnytskyi.com
+Author: Olivier Heurtier
+Author-email: olivier.heurtier@github.com
 License: BSD
 Classifier: Topic :: Documentation
 Classifier: Topic :: Documentation :: Sphinx
@@ -34,3 +33,4 @@ Requires-Dist: m2r2
 Requires-Dist: picobox
 Requires-Dist: deepmerge
 Requires-Dist: setuptools
+Dynamic: license-file

sc_oa-0.7.0.16/sc_oa.egg-info/SOURCES.txt ADDED Viewed

@@ -0,0 +1,160 @@
+.gitignore
+.gitmodules
+.mailmap
+.pre-commit-config.yaml
+CHANGES
+LICENSE
+MANIFEST.in
+README.rst
+pyproject.toml
+setup.cfg
+tox.ini
+.github/workflows/pypi.yml
+.github/workflows/tests.yml
+docs/conf.py
+docs/index.rst
+docs/specs/openapi.yml
+sc_oa.egg-info/PKG-INFO
+sc_oa.egg-info/SOURCES.txt
+sc_oa.egg-info/dependency_links.txt
+sc_oa.egg-info/not-zip-safe
+sc_oa.egg-info/requires.txt
+sc_oa.egg-info/top_level.txt
+sphinxcontrib/__init__.py
+sphinxcontrib/openapi/__init__.py
+sphinxcontrib/openapi/__main__.py
+sphinxcontrib/openapi/_lib2to3.py
+sphinxcontrib/openapi/directive.py
+sphinxcontrib/openapi/openapi20.py
+sphinxcontrib/openapi/openapi30.py
+sphinxcontrib/openapi/schema_utils.py
+sphinxcontrib/openapi/utils.py
+sphinxcontrib/openapi/locale/openapi.pot
+sphinxcontrib/openapi/locale/es_ES/LC_MESSAGES/openapi.mo
+sphinxcontrib/openapi/locale/es_ES/LC_MESSAGES/openapi.po
+sphinxcontrib/openapi/locale/fr_FR/LC_MESSAGES/openapi.mo
+sphinxcontrib/openapi/locale/fr_FR/LC_MESSAGES/openapi.po
+sphinxcontrib/openapi/renderers/__init__.py
+sphinxcontrib/openapi/renderers/_description.py
+sphinxcontrib/openapi/renderers/_httpdomain.py
+sphinxcontrib/openapi/renderers/_httpdomain_old.py
+sphinxcontrib/openapi/renderers/_model.py
+sphinxcontrib/openapi/renderers/_toc.py
+sphinxcontrib/openapi/renderers/abc.py
+tests/conftest.py
+tests/test_description.py
+tests/test_model.py
+tests/test_openapi.py
+tests/test_schema_utils.py
+tests/test_spec_examples.py
+tests/test_toc.py
+tests/OpenAPI-Specification/.gitignore
+tests/OpenAPI-Specification/.travis.yml
+tests/OpenAPI-Specification/CONTRIBUTORS.md
+tests/OpenAPI-Specification/DEVELOPMENT.md
+tests/OpenAPI-Specification/GOVERNANCE.md
+tests/OpenAPI-Specification/IMPLEMENTATIONS.md
+tests/OpenAPI-Specification/LICENSE
+tests/OpenAPI-Specification/MAINTAINERS.md
+tests/OpenAPI-Specification/README.md
+tests/OpenAPI-Specification/package.json
+tests/OpenAPI-Specification/examples/v2.0/json/api-with-examples.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-expanded.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-minimal.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-simple.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-with-external-docs.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore.json
+tests/OpenAPI-Specification/examples/v2.0/json/uber.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-separate/common/Error.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-separate/spec/NewPet.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-separate/spec/Pet.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-separate/spec/parameters.json
+tests/OpenAPI-Specification/examples/v2.0/json/petstore-separate/spec/swagger.json
+tests/OpenAPI-Specification/examples/v2.0/yaml/api-with-examples.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-expanded.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-minimal.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-simple.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-with-external-docs.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/uber.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-separate/common/Error.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-separate/spec/NewPet.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-separate/spec/Pet.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-separate/spec/parameters.yaml
+tests/OpenAPI-Specification/examples/v2.0/yaml/petstore-separate/spec/swagger.yaml
+tests/OpenAPI-Specification/examples/v3.0/api-with-examples.yaml
+tests/OpenAPI-Specification/examples/v3.0/callback-example.yaml
+tests/OpenAPI-Specification/examples/v3.0/link-example.yaml
+tests/OpenAPI-Specification/examples/v3.0/petstore-expanded.yaml
+tests/OpenAPI-Specification/examples/v3.0/petstore.yaml
+tests/OpenAPI-Specification/examples/v3.0/uspto.yaml
+tests/OpenAPI-Specification/guidelines/EXTENSIONS.md
+tests/OpenAPI-Specification/guidelines/v2.0/EXTENSIONS.md
+tests/OpenAPI-Specification/guidelines/v2.0/README.md
+tests/OpenAPI-Specification/guidelines/v2.0/REUSE.md
+tests/OpenAPI-Specification/schemas/v1.2/README.md
+tests/OpenAPI-Specification/schemas/v1.2/apiDeclaration.json
+tests/OpenAPI-Specification/schemas/v1.2/authorizationObject.json
+tests/OpenAPI-Specification/schemas/v1.2/dataType.json
+tests/OpenAPI-Specification/schemas/v1.2/dataTypeBase.json
+tests/OpenAPI-Specification/schemas/v1.2/infoObject.json
+tests/OpenAPI-Specification/schemas/v1.2/modelsObject.json
+tests/OpenAPI-Specification/schemas/v1.2/oauth2GrantType.json
+tests/OpenAPI-Specification/schemas/v1.2/operationObject.json
+tests/OpenAPI-Specification/schemas/v1.2/parameterObject.json
+tests/OpenAPI-Specification/schemas/v1.2/resourceListing.json
+tests/OpenAPI-Specification/schemas/v1.2/resourceObject.json
+tests/OpenAPI-Specification/schemas/v2.0/README.md
+tests/OpenAPI-Specification/schemas/v2.0/schema.json
+tests/OpenAPI-Specification/versions/1.2.md
+tests/OpenAPI-Specification/versions/2.0.md
+tests/OpenAPI-Specification/versions/3.0.0.md
+tests/OpenAPI-Specification/versions/3.0.1.md
+tests/OpenAPI-Specification/versions/3.0.2.md
+tests/doc/conf.py
+tests/doc/index.rst
+tests/doc/petstore.yaml
+tests/lib2to3/conftest.py
+tests/lib2to3/test_convert.py
+tests/lib2to3/test_convert_operation.py
+tests/lib2to3/test_convert_parameter.py
+tests/lib2to3/test_convert_parameters.py
+tests/lib2to3/test_convert_path.py
+tests/lib2to3/test_convert_paths.py
+tests/lib2to3/test_convert_request_body.py
+tests/lib2to3/test_convert_request_body_formdata.py
+tests/lib2to3/test_convert_response.py
+tests/lib2to3/test_convert_responses.py
+tests/renderers/httpdomain/conftest.py
+tests/renderers/httpdomain/test_render.py
+tests/renderers/httpdomain/test_render_json_schema_description.py
+tests/renderers/httpdomain/test_render_operation.py
+tests/renderers/httpdomain/test_render_parameter.py
+tests/renderers/httpdomain/test_render_parameters.py
+tests/renderers/httpdomain/test_render_paths.py
+tests/renderers/httpdomain/test_render_request_body.py
+tests/renderers/httpdomain/test_render_request_body_example.py
+tests/renderers/httpdomain/test_render_response.py
+tests/renderers/httpdomain/test_render_response_example.py
+tests/renderers/httpdomain/test_render_responses.py
+tests/renderers/httpdomain/test_render_restructuredtext_markup.py
+tests/renderers/httpdomain/rendered/v2.0/api-with-examples.yaml.rst
+tests/renderers/httpdomain/rendered/v2.0/petstore-expanded.yaml.rst
+tests/renderers/httpdomain/rendered/v2.0/petstore.yaml.rst
+tests/renderers/httpdomain/rendered/v2.0/uber.json.rst
+tests/renderers/httpdomain/rendered/v2.0/uber.yaml.rst
+tests/renderers/httpdomain/rendered/v3.0/api-with-examples.yaml.rst
+tests/renderers/httpdomain/rendered/v3.0/petstore-expanded.yaml.rst
+tests/renderers/httpdomain/rendered/v3.0/petstore.yaml.rst
+tests/renderers/httpdomain/rendered/v3.0/uspto.yaml.rst
+tests/testdata/foo.json
+tests/testdata/foo.yaml
+tests/testspecs/v2.0/api-with-examples.yaml
+tests/testspecs/v2.0/petstore-expanded.yaml
+tests/testspecs/v2.0/petstore.yaml
+tests/testspecs/v2.0/uber.json
+tests/testspecs/v2.0/uber.yaml
+tests/testspecs/v3.0/api-with-examples.yaml
+tests/testspecs/v3.0/petstore-expanded.yaml
+tests/testspecs/v3.0/petstore.yaml
+tests/testspecs/v3.0/uspto.yaml

{sc_oa-0.7.0.14 → sc_oa-0.7.0.16}/setup.cfg RENAMED Viewed

@@ -1,8 +1,7 @@
 [metadata]
 name = sc-oa
-author = Ihor Kalnytskyi
-	Olivier Heurtier
-author_email = ihor@kalnytskyi.com
+author = Olivier Heurtier
+author_email = olivier.heurtier@github.com
 license = BSD
 description = Fork of the OpenAPI (fka Swagger) spec renderer for Sphinx
 url = https://github.com/olivier-heurtier/sphinxcontrib-openapi/tree/mymaster

{sc_oa-0.7.0.14 → sc_oa-0.7.0.16}/sphinxcontrib/openapi/openapi30.py RENAMED Viewed

@@ -144,7 +144,8 @@ def _parse_schema(schema, method):
                             del example[k]
                 ret = collections.OrderedDict(example)
                 # XXX should be True to be compliant with OpenAPI
-                if schema.get('additionalProperties', False) and '...' not in example:
+                if (schema.get('additionalProperties', False) or 'type' not in schema) and \
+                        '...' not in example:
                     # materialize in the example the fact that additional properties can be added
                     ret['...'] = '...'
                 return ret
@@ -160,7 +161,7 @@ def _parse_schema(schema, method):
                 results.append((name, result))
         # XXX should be True to be compliant with OpenAPI
-        if schema.get('additionalProperties', False):
+        if schema.get('additionalProperties', False) or 'type' not in schema:
             # materialize in the example the fact that additional properties can be added
             results.append(("...", "..."))

{sc_oa-0.7.0.14 → sc_oa-0.7.0.16}/sphinxcontrib/openapi/renderers/_model.py RENAMED Viewed

@@ -245,9 +245,7 @@ def _process_one(prefix, schema, mandatory, entities, convert):
 def _build(name, schema, entities, convert, options):
-    if 'type' not in schema:
-        schema['type'] = 'object'
-    if schema.get('type', '') not in ['object', 'array']:
+    if 'type' in schema and schema['type'] not in ['object', 'array']:
         return ''
     yield ''
@@ -257,27 +255,32 @@ def _build(name, schema, entities, convert, options):
     yield options['header'] * len(name)
     yield ''
     D = _get_description(schema, convert)
+    if 'type' not in schema and not (set(['oneOf', 'allOf', 'anyOf']) & schema.keys()):
+        D += '\n' + _('Any type of content is accepted (number, string or object).')
     if D:
         yield D
         yield ''
-    yield '.. list-table:: ' + name
-    yield '    :header-rows: 1'
-    yield '    :widths: 25 25 45 15'
-    yield '    :class: longtable'
-    yield ''
-    yield '    * - ' + _('Attribute')
-    yield '      - ' + _('Type')
-    yield '      - ' + _('Description')
-    yield '      - ' + _('Required')
-    for item in _process_one([], schema, False, entities, convert):
-        if str(item[0]):
-            yield '    * - ``' + str(item[0]) + '``'
-        else:
-            yield '    * - ' + _('N/A')
-        yield '      - ' + textwrap.indent(str(item[1]), '        ').lstrip()
-        yield '      - ' + textwrap.indent(str(item[2]), '        ').lstrip()
-        yield '      - ' + _('Yes') if item[3] else '      -'
+    if 'type' not in schema and not (set(['oneOf', 'allOf', 'anyOf']) & schema.keys()):
+        pass
+    else:
+        yield '.. list-table:: ' + name
+        yield '    :header-rows: 1'
+        yield '    :widths: 25 25 45 15'
+        yield '    :class: longtable'
+        yield ''
+        yield '    * - ' + _('Attribute')
+        yield '      - ' + _('Type')
+        yield '      - ' + _('Description')
+        yield '      - ' + _('Required')
+        for item in _process_one([], schema, False, entities, convert):
+            if str(item[0]):
+                yield '    * - ``' + str(item[0]) + '``'
+            else:
+                yield '    * - ' + _('N/A')
+            yield '      - ' + textwrap.indent(str(item[1]), '        ').lstrip()
+            yield '      - ' + textwrap.indent(str(item[2]), '        ').lstrip()
+            yield '      - ' + _('Yes') if item[3] else '      -'
     if 'example' in schema or 'examples' in schema:
         N = 1
@@ -289,7 +292,8 @@ def _build(name, schema, entities, convert, options):
             N += 1
             # validate the example against this schema
             try:
-                validate(instance=ex, schema=schema)
+                if 'type' in schema:
+                    validate(instance=ex, schema=schema)
                 yield ''
                 yield '.. code-block:: json'
                 yield ''

sc_oa-0.7.0.16/tests/OpenAPI-Specification/.gitignore ADDED Viewed

@@ -0,0 +1,8 @@
+.idea
+*.iml
+*.ipr
+*.iws
+target
+atlassian-ide-plugin.xml
+node_modules/
+Gemfile.lock

sc_oa-0.7.0.16/tests/OpenAPI-Specification/.travis.yml ADDED Viewed

@@ -0,0 +1,6 @@
+sudo: false
+language: node_js
+node_js:
+  - "node"
+script:
+  - node node_modules/mdv/mdv versions/3.*.md

sc_oa-0.7.0.16/tests/OpenAPI-Specification/CONTRIBUTORS.md ADDED Viewed

@@ -0,0 +1,9 @@
+* Darrel Miller [@darrelmiller](https://github.com/darrelmiller)
+* Jason Harmon [@jharmn](https://github.com/jharmn)
+* Jeremy Whitlock [@whitlockjc](https://github.com/whitlockjc)
+* Kris Hahn [@KrisHahn](https://github.com/krishahn)
+* Marsh Gardiner [@earth2marsh](https://github.com/earth2marsh)
+* Mike Ralphson [@MikeRalphson](https://github.com/mikeralphson)
+* Rob Dolin [@RobDolinMS](https://github.com/robdolinms)
+* Ron Ratovsky [@webron](https://github.com/webron)
+* Tony Tam [@fehguy](https://github.com/fehguy)

sc_oa-0.7.0.16/tests/OpenAPI-Specification/DEVELOPMENT.md ADDED Viewed

@@ -0,0 +1,118 @@
+## Development Guidelines
+This document intends to establish guidelines which build a transparent, open mechanism for deciding how to evolve the OpenAPI Specification. The OpenAPI Technical Steering Committee (TSC) will initially follow these processes when merging changes from external contributors or from the TSC itself. This guideline document will be adjusted as practicality dictates.
+## OAI Specification Driving factors
+The OpenAPI Specification should be use-case driven. We can specify support for hypothetical use cases as we see fit, but specifications should be backed by realistic scenarios.
+## Specification Change Criteria
+The specification *will evolve over time*. Changes  may be made when any of the following criteria are met:
+* Clarity. The current "way" something is done doesn't make sense, is complicated, or not clear.
+* Consistency. A portion of the specification is not consistent with the rest, or with the industry standard terminology.
+* Necessary functionality. We are missing functionality because of a certain design of the specification.
+* Forward-looking designs. As usage of APIs evolves to new protocols, formats, and patterns, we should always consider what the next important functionality should be.
+* Impact. A change will provide impact on a large number of use cases. We should not be forced to accommodate every use case. We should strive to make the *common* and *important* use cases both well supported and common in the definition of the OAI Spec. We cannot be edge-case driven.
+## Specification Change Process
+For each change in the specification we should *always* consider the following:
+* Migration. Is this a construct that has a path from the existing 2.0 specification? If so, how complicated is it to migrate to the proposed change?
+* Tooling. Strive to support code generation, software interfaces, spec generation techniques, as well as other utilities. Some features may be impossible to support in different frameworks/languages. These should be documented and considered during the change approval process.
+* Visualization. Can the specification change be graphically visualized somehow in a UI or other interface?
+Spec changes should be approved by a majority of the committers. Approval can be given by commenting on the issue itself, for example, "Approved by @webron" however at least one formal GitHub-based  flow approval must be given. After voting criteria is met, any committer can merge the PR. No change should be approved until there is documentation for it, supplied in an accompanying PR.
+## Tracking Process
+* GitHub is the medium of record for all spec designs, use cases, and so on.
+* As with 2.0, the **human readable** document is the source of truth. If using a JSON Schema again to document the spec, it is secondary to the human documentation. The documentation should live in a *.md file, in parallel to the 2.0 document (versions/3.0.0.md for example).
+* At any given time, there would be *at most* 4 work branches. The branches would exist if work has started on them. Assuming a current version of 3.0.0:
+    * master - Current stable version. No PRs would be accepted directly to modify the specification. PRs against supporting files can be accepted.
+    * v3.0.1-dev - The next PATCH version of the specification. This would include non-breaking changes such as typo fixes, document fixes, wording clarifications.
+    * v3.1.0 - The next MINOR version.
+    * v4.0.0 - The next MAJOR version.
+* The master branch shall remain the current, released OpenAPI Specification. We will describe and link the work branch(es) on the **default** README.md on master.
+* Examples of how something is described *currently* vs. the proposed solution should accompany any change proposal.
+* New features should be done in feature branches/forks which, upon approval, are merged into the proper work branch.
+* Use labels for the workflow of specification changes. Examples of labels are proposed, housekeeping, migration-review, tooling-, needs documentation, review (candidate for upcoming TSC mtg), rejected, and needs approval. These labels must be assigned by project committers. Style is lowercase with dashes in place of spaces.
+* An issue will be opened for each feature change. Embedded in the issue, or ideally linked in a file via pull-request (PR), a document about use cases should be supplied with the change.
+* A PR will be used to describe the *proposed* solution and linked to the original issue.
+* Not all committers will contribute to every single proposed change. There may be many open proposals at once, and multiple efforts may happen in parallel.
+* When the work branch is ready and approved, the branch will be merged to master.
+## Release Process
+A release requires a vote on the release notes by TSC members within the voting period. Major or minor release voting periods will be announced by the Liaison in the Slack channel and noted on the calendar at least 6 days in advance. During this time, TSC members who have not yet voted must note their approval on the GitHub pull request for the release notes. Patch releases happen at the first TSC meeting of a calendar month. The Liaison is responsible for coordinating the actual merge to Master with marketing support, if any.
+* Patch-level releases require majority approval by TSC members. (Max voting period 3 days)
+* Minor: requires approval by 66% of TSC members. (Max voting period 7 days)
+* Major: requires approval by 66% of TSC members. (Max voting period 14 days)
+## Draft Features
+Where suitable, features will be introduced as draft but OAI approved extensions.
+By introducing new features this way we enable new features to be designed, documented and then implemented by tools that are interested in the feature, without putting the burden of implementation on all tooling.
+If the feature is successfully implemented and there is demonstrable value added by the feature, it will become a candidate for inclusion in a future release of the specification, at which point all tools will be expected to support the feature.
+Draft feature extensions are identified by the `x-oas-draft-` prefix and can only be used where existing extensions are permitted.
+This ensures no existing tooling will affected by the introduction of the draft feature.
+If the feature is deemed appropriate for inclusion in the OAS, the `x-oas-draft-` prefix will be removed.
+Tooling that supports draft features should plan for the future removal of the prefix.
+When tooling adds support for a later version of OAS that includes the final implementation of the feature, it MUST not support the use of the draft prefix for that feature.
+Draft features will only be promoted into minor or major releases of the specification and therefore will be transparent to OpenAPI description writers and tooling providers who choose not to use the feature while in its draft state.
+Draft features will be documented as GitHub issues and labeled with the `draft-feature` label and will be initially labelled as `draft:proposal`. When the proposal is considered sufficiently stable for pilot implementation, it will be labeled `draft:pilot`.
+If during the development of a draft feature, it is determined that the feature needs to change in a way that may break existing draft implementations, the extension name itself may be versioned with a version suffix. e.g. `-v2`
+When a draft feature becomes part of a future update to the specification any version suffix will be removed.
+Draft features that are deemed not appropriate for inclusion MUST be marked with the `draft:abandoned` label.
+Draft-features that are considered suitably specified and have had successful pilot implementations will be marked with the `draft:graduated` label.
+Not all future new features will be introduced in this way.
+Some new features impact the specification in ways that cannot be encapsulated in an extension.
+However, where a new feature can be introduced in this way, it should be.
+## Transparency
+The process should be as transparent as possible. Sometimes there will be discussions that use customer names, sensitive use cases, and so on. These must be anonymized, discussed in a private repository, or conducted offline. General discussions should happen on the GitHub issues for this project.
+## Participation
+While governance of the specification is the role of the TSC, the evolution of the specification happens through the participation of members of the developer community at large. Any person willing to contribute to the effort is welcome, and contributions may include filing or participating in issues, creating pull requests, or helping others with such activities.
+## Community Roles
+While these developer community roles are informal, there are many ways to get involved with the OpenAPI community, such as:
+* Contributor: Includes but is not limited to any [contributor to the specification](https://github.com/OAI/OpenAPI-Specification/graphs/contributors) via an accepted pull request or who participates in issues or TSC calls.
+* Implementer: any person involved in the creation or maintenance of tooling that leverages the current OpenAPI Specification
+* Ambassador: represents the OpenAPI Specification to the developer community. This could be through talks at conferences or meetups, blog posts, or answering questions in places like Twitter, Stack Overflow, or the GitHub repo.
+* Supporter: uses the specification and appreciates its value.

sc_oa-0.7.0.16/tests/OpenAPI-Specification/GOVERNANCE.md ADDED Viewed

@@ -0,0 +1,31 @@
+# Governance
+The OpenAPI Specification is a project of the Open API Initiative (OAI), under the auspices of the Linux Foundation. For governance of the OAI, review the [OAI's charter](https://www.openapis.org/participate/how-to-contribute/governance).
+# Processes and procedures of the Technical Steering Committee (TSC)
+The TSC is a self-organizing sub-group of the OAI. Herein are its principles and guidelines.
+## 1. The establishment of roles and the responsibilities for each role
+Roles:
+* [Liaison](https://www.merriam-webster.com/dictionary/liaison) — Elected by TSC members in a plurality vote (oral count). Liaison represents the TSC to the OAI's Business Governing Board (BGB) at board meetings (though this itself does not confer voting rights) and is the public facing mouthpiece of the TSC.
+* [Maintainer](https://www.merriam-webster.com/dictionary/maintainer) — all and only members of the TSC are maintainers, and are responsible for approving proposed changes to the specification. If membership drops below 3, work is suspended until the BGB can re-establish the minimum. To maintain agility, the TSC should be capped at a maximum 9 members, though that number can be reconsidered by the TSC in the future. Past members will be noted as emeritus status once they are no longer members.
+* [Rick](https://www.youtube.com/watch?v=dQw4w9WgXcQ) — Responsible for not giving up or letting down. Requires plurality vote of TSC members.
+## 2. Adding members to the TSC
+A call-for-nominations period may be agreed upon by the TSC voting members and announced in a timely manner through [@OpenApiSpec](https://twitter.com/OpenApiSpec) on Twitter, assuming the TSC membership is not already at its maximum. A candidate may be nominated through a motion by a voting TSC member in a closed TSC meeting. A nominee must not receive opposition votes of more than 25% of the TSC voting membership via a confidential vote held electronically within a week following the nomination meeting. Approved nominees become provisional members and are expected to comport themselves as full members of the TSC during the provisional period of 4-6 weeks (to be determined at start of each nominating period), though nominees have no voting rights. The provisional period is concluded by a second, confidential vote similar to the nomination period's vote. At most there are four voting periods per year (no more than one every three months), with a minimum of one per year.
+## 3. Removal of membership from the TSC
+In dire situations, it may be necessary to remove a TSC member, such as behavior that violates the code of conduct (NB: whether non-participation merits removal is a decision left to the TSC voting members). 75% vote (confidential, electronic) of the other TSC members is required to remove a member. Otherwise, TSC members are removed when they renounce their position by informing the Liaison of their effective resignation date.
+## 4. Criteria for decisions
+The group will strive to achieve all decisions via unopposed consensus. When not possible, unresolved conflicts will be raised to the OAI's Technical Oversight Board (TOB).
+The TSC will maintain a publicly available document specifying the process in the contributor guidelines for how proposed changes are merged into the specification. The TSC will document and publicize the schedule of merge parties and release parties for the benefit of the developer community.

sc_oa-0.7.0.16/tests/OpenAPI-Specification/IMPLEMENTATIONS.md ADDED Viewed

@@ -0,0 +1,73 @@
+### Implementations
+Below is a list of known tooling that implements the 3.0.0 specification. While support for the 3.0.0 specification matures,  refer to the details of projects listed below for any notes about stability and roadmap.  The process to improve the 3.x specification includes feedback from end-users and tooling creators. We strongly encourage draft tooling be made available for early users of OAS drafts.
+These tools are not endorsed by the OAI.
+#### Low-Level tooling
+| Title          | Project Link | Language |Description                          |
+|----------------|--------------|----------|---------------------|
+| swagger-parser | [github/swagger-api](https://github.com/swagger-api/swagger-parser) | Java | Swagger 1.0, 1.1, 1.2, 2.0 to OpenAPI Specification converter |
+| swagger-models | [github/swagger-api](https://github.com/swagger-api/swagger-core/tree/master/modules/swagger-models) | Java | OpenAPI 3.0 Java Pojos |
+| KaiZen OpenAPI Parser | [github/RepreZen/KaiZen-OpenAPI-Parser](https://github.com/RepreZen/KaiZen-OpenAPI-Parser) | Java | High-performance Parser, Validator, and Java Object Model for OpenAPI 3.x |
+| openapi3-ts | [github/metadevpro/openapi3-ts](https://github.com/metadevpro/openapi3-ts) | TypeScript | TS Model & utils for OpenAPI 3.0.x contracts |
+| swagger2openapi | [github/mermade/swagger2openapi](https://github.com/mermade/swagger2openapi) | Node.js | An OpenAPI / Swagger 2.0 to OpenAPI 3.0.x converter and validator |
+| Microsoft.OpenApi.net | [github/microsoft/OpenApi.net](https://github.com/microsoft/openapi.net/) | dotnet | C# based parser with definition validation and migration support from V2 |
+| odata-openapi | [github/oasis-tcs/odata-openapi](https://github.com/oasis-tcs/odata-openapi) | XSLT | OData 4.0 to OpenAPI 3.0.0 converter |
+| openapi3_parser | [github/kevindew/openapi3_parser](https://github.com/kevindew/openapi3_parser) | Ruby | A Ruby implementation of parser and validator for the OpenAPI 3 Specification |
+| oas_parser | [github/Nexmo/oas_parser](https://github.com/Nexmo/oas_parser) | Ruby | An open source OpenAPI Spec 3 Definition Parser writen in Ruby |
+| oas3-remote-refs | [github//OverSpeedIO/oas3-remote-refs](https://github.com/OverSpeedIO/oas3-remote-refs) | Node.js | Tool to pull remote refernences and merge them into the definitions of the provided OpenAPI3 speicfication.
+| go-openapi | [github/nasa9084/go-openapi](https://github.com/nasa9084/go-openapi) | Go | Golang struct model for OpenAPI 3.x. |
+| openapi | [github/wzshiming/openapi](https://github.com/wzshiming/openapi) | Go | OpenAPI 3 Specification for golang |
+| kin-openapi | [github/getkin/kin-openapi](https://github.com/getkin/kin-openapi) | Go | OpenAPI 3.x implementation for Go (parsing, converting, validation) |
+#### Editors
+| Title          | Project Link | Language |Description                          |
+|----------------|--------------|----------|---------------------|
+| Apicurio Studio | [github/Apicurio/apicurio-studio](https://github.com/Apicurio/apicurio-studio) | Java/Typescript | Web-Based **visual designer** for OpenAPI 2.0 and 3.0.0. |
+| KaiZen OpenAPI Editor | [github/RepreZen/KaiZen-OpenAPI-Editor](https://github.com/RepreZen/KaiZen-OpenAPI-Editor) | Java | Eclipse Editor for OpenAPI 2.0 and 3.0 |
+| RepreZen API Studio | [RepreZen.com/OpenAPI](https://www.reprezen.com/OpenAPI) | Java | Commercial desktop IDE for API design, documentation & development |
+| OpenAPI-gui | [github/Mermade/openapi-gui](https://github.com/Mermade/openapi-gui) | Node.js | GUI / visual editor for creating and editing OpenAPI definitions |
+| SwaggerHub | [swaggerhub.com](https://swaggerhub.com) | | API Design and Documentation Platform, Built For Teams
+| swagger-editor | [github/swagger-api](https://github.com/swagger-api/swagger-editor) | JavaScript | Web-Based editor for creating, editing, validating and testing OpenAPI\Swagger definitions |
+#### User Interfaces
+| Title          | Project Link | Language |Description                          |
+|----------------|--------------|----------|---------------------|
+| openapi-viewer | [github/koumoul/openapi-viewer](https://github.com/koumoul-dev/openapi-viewer) | Vue.js | Browse and test a REST API described with the OpenAPI 3.0 Specification. |
+| swagger-ui | [github/swagger-api](https://github.com/swagger-api/swagger-UI) | JavaScript | Web-Based interface for visualizing and testing OpenAPI\Swagger definitions |
+| lincoln | [github/temando/open-api-renderer](https://github.com/temando/open-api-renderer)| React.js| A React renderer for OpenAPI v3 |
+| WebSphere Liberty | [Download jar](https://developer.ibm.com/wasdev/downloads/) | JavaScript | Includes a native OpenAPI v3 UI which allows for customization of its banners and URL |
+| Widdershins | [github/Mermade/widdershins](https://github.com/Mermade/widdershins) | Node.js | Generate Slate/Shins markdown from OpenAPI 3.0.x |
+| angular-swagger-ui | [github/angular-swagger-ui](https://github.com/Orange-OpenSource/angular-swagger-ui) | AngularJS | An angularJS implementation of Swagger UI |
+#### Mock Servers
+| Title          | Project Link | Language | Description |
+| -------------- | ------------ | -------- | ----------- |
+| API Sprout     | [github/danielgtaylor/apisprout](https://github.com/danielgtaylor/apisprout) | Go | Lightweight, blazing fast, cross-platform OpenAPI 3 mock server with validation |
+#### Server Implementations
+| Title          | Project Link | Language |Description                          |
+|----------------|--------------|----------|---------------------|
+| Vert.x Web API Contract | [github/vert-x3/vertx-web](http://vertx.io/docs/#web) | Java, Kotlin, JavaScript, Groovy, Ruby, Ceylon & Scala | Create an API endpoint with Vert.x 3 and OpenAPI 3 with automatic requests validation
+| Fusio | [github/apioo/fusio](https://github.com/apioo/fusio) | PHP, JavaScript | Build API endpoints based on OpenAPI 3
+| Modern | [github/modern-project/modern-ruby](https://github.com/modern-project/modern-ruby) | Ruby | OpenAPI 3-based Rack framework with automatic OAS generation and requests/response validation
+| Koa2-OAS3 | [github/OverSpeedIO/koa2-oas3](https://github.com/OverSpeedIO/koa2-oas3) | Node.js | OpenAPI 3 request validation middleware for Koa2 based apps.
+| Exegesis | [github/exegesis-js/exegesis](https://github.com/exegesis-js/exegesis) | Node.js | OpenAPI 3 server-side framework for express and other frameworks.
+| PHP-CRUD-API | [github/mevdschee/php-crud-api](https://github.com/mevdschee/php-crud-api) | PHP | Automatic CRUD API with OpenAPI 3 docs
+#### Code Generators
+| Title          | Project Link | Language |Description                          |
+|----------------|--------------|----------|---------------------|
+| baucis-openapi3 | [github/metadevpro/baucis-openapi3](https://github.com/metadevpro/baucis-openapi3) | Node.js | [Baucis.js](https://github.com/wprl/baucis) plugin for generating OpenAPI 3.0 compliant API contracts. |
+| Google Gnostic | [github/googleapis/gnostic](https://github.com/googleapis/gnostic) | Go | Compile OpenAPI descriptions into equivalent Protocol Buffer representations. |
+| Gen | [github/wzshiming/gen](https://github.com/wzshiming/gen) | Go | Generate OpenAPI 3, client, and route based on golang source code. |
+| serverless-openapi-documentation | [github/temando/serverless-openapi-documentation](https://github.com/temando/serverless-openapi-documentation) | Typescript | Serverless 1.0 plugin to generate OpenAPI V3 documentation from serverless configuration |
+| zero-rails_openapi | [github/zhandao/zero-rails_openapi](https://github.com/zhandao/zero-rails_openapi) | Ruby | Provide concise DSL for generating the OpenAPI Specification 3 documentation file for Rails application |
+| slush-vertx | [github/pmlopes/slush-vertx](https://github.com/pmlopes/slush-vertx) | Java, Kotlin & Groovy | Generate server skeleton for [Vert.x Web API Contract](http://vertx.io/docs/#web) and API Client based on [Vert.x 3 Web Client](http://vertx.io/docs/#web)
+| WebSphere Liberty | [Download jar](https://developer.ibm.com/wasdev/downloads/) | Java EE | Generates OpenAPI v3 documentation from Java EE applications |
+| swagger-node-codegen | [github/fmvilas/swagger-node-codegen](https://github.com/fmvilas/swagger-node-codegen) | Node.js | Generates a Node.js/express server, but also has a template engine for creating any templates needed. |

sc-oa 0.7.0.14__tar.gz → 0.7.0.16__tar.gz

Potentially problematic release.

sc-oa 0.7.0.14tar.gz → 0.7.0.16tar.gz