Skip to content
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

Unclear which edition of ECMA-262 is used as regex format #1687

Closed
dvh opened this issue Sep 14, 2018 · 6 comments
Closed

Unclear which edition of ECMA-262 is used as regex format #1687

dvh opened this issue Sep 14, 2018 · 6 comments

Comments

@dvh
Copy link

dvh commented Sep 14, 2018

While issue #880 links to http://www.ecma-international.org/publications/standards/Ecma-262.htm (just as JSON Schema does, the OpenAPI Specification deeplinks to the 5.1 edition in https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#schema-object. Is this a typo or is edition 9.0 not supported (yet)?

@MikeRalphson
Copy link
Member

Edition 9.0 appears to have been released 11 months after OpenAPI 3.0.0, so it should not be a surprise that it is not supported. 🙂

It may be that a baseline version was chosen to achieve the broadest tooling compatibility ❓

@dvh
Copy link
Author

dvh commented Sep 25, 2018

I don't think this is made very clear in the docs. Perhaps adding the specific version to the docs (not only in the deeplink) will help.

@MikeRalphson
Copy link
Member

A PR for discussion would be warmly welcomed.

@handrews
Copy link
Contributor

This got revisited and (assuming the PR is accepted) resolved in issue #1985 and PR #1987.

@handrews
Copy link
Contributor

@MikeRalphson perhaps close this in favor of #1985 since it has more details?

@MikeRalphson
Copy link
Member

Agreed.

webron added a commit that referenced this issue Feb 21, 2020
* 3.0.3 prep

* Update README.md

* Update README.md

* Removed confusing comment

* Updated text for OperationRef

* Clarified supported Ecma edition for regex

Added supported Ecma edition (5.1) for regular expressions in the link text and used the formal name: [Ecma-262 Edition 5.1](https://www.ecma-international.org/ecma-262/5.1/).

See also: #1687

* Make ABNF for runtime expressions complete

* json-schema.org and commonmark.org now support https

* Update 3.0.2.md

fixed typo

* Update 3.0.2.md

fixed typo

* Fixed typo

* Update 3.0.3.md

fixed typo

* Update 3.0.2.md

fixed typo

* explicit 'forward slash'

* add back quotes

* fix difference between yaml and json in Response Object Examples

* fix typo in Callback Object

* Update 3.0.2.md

* yaml.org supports https, but www.yaml.org is misconfigured

* allow, but discourage, requestBody for GET, HEAD, DELETE

* spelling error

* retain typo in v3.0.2; fix for v3.0.3 (#1899)

* Corrected pattern regex dialect link

* TSC 2019-10-03 Feedback

This sentance was meant to paraphrase semver for clarifty, but ended up suggesting a confusion situation where new things essentially cannot really happen.

@webron has context on this.

* Ron's wording for Darrels feedback

* ted updates

* backticks

* Improved callback examples

* fix #2053: `style` keyword is not supported inside Schema object

* Resolved undocumented nullable behavior (#2046)

* Resolved undocumented nullable behavior

OpenAPI Schema Objects and JSON Schema have a few fundamental differences, and this clears up a bit of confusion about one of them.

* Added ted updates from oct 31st TSC

Co-Authored-By: Ted Epstein <ted.epstein@reprezen.com>

* Update versions/3.0.3.md

Co-Authored-By: Darrel <darrmi@microsoft.com>

* Fix 'Security Scheme Object' definition with OAuth 2.0 grant types. (#2006)

* The examples keyword is not supported inside schema (#2042)

* examples not supported inside schema

* figured it out

* a tiny little edit

* Replace 'application' by 'API' within the 'Info Object' definition. (#2004)

* OpenAPI not Open API

* Revert "allow, but discourage, requestBody for GET, HEAD, DELETE"

* Clarify constraints on Security Scheme Object Scheme Property (#1880)

* Wording around scheme extensions

* Clarified that securitySchemeScheme is only a SHOULD be registered scheme

* Fix formatting errors in example (#2132)

* Server Variable Object clarifications (#1809)

* Server Variable Object clarifications

* Toned language down for proper semver versioning

* Path Templating Clarification - proposed fix for #1830.  (#1831)

* Proposed fix for #1830. Each variable expression in a path must have a corresponding path parameter.

* #1830 - Removed 'at least once' to defer the question about repeated references to a single path parameter.

* Update #1830 fix with suggestion from Darrel

@darrelmiller suggestions we use "template expression" instead of "variable expression" to align with RFC6570. Good idea.

* Clarify the spec to allow optional or unspecified OAuth scopes (#1888)

* Referencing issue #513. Clarify the spec to accommodate OAuth schemes where scope may be unspecified (optional scope) or where scope is not used at all.

* Removed the provision for default scope represented as empty string. This introduces some ambiguities in the Security Requirement Object that would need to be addressed.

* For #513, adjusting language and removing examples

For #513, adjusting language and removing examples as suggested by @webron.

* removed unnecessary example header

Co-authored-by: Ron <ron@swagger.io>

* Clarify empty Security Requirement Object usage and validity (#1886)

* Clarify empty Security Requirement Object usage and validity

* Reorder sentences to make clearer.

* Remove wrong text.

* Removed unneeded text.

Co-authored-by: Ron <ron@swagger.io>

* fix a typo in the Security Filtering section (#1837)

* fix a typo in the Security Filtering section

* Security filtering slight reword

Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>

* minor clarification for operationId usage in link objects (#1733)

* minor clarification

it's a bit confusing that both the id and the reference are called "operationId", so this tweak makes the text a bit more explicit.

* use right terminology

Co-Authored-By: Mike Ralphson <mike.ralphson@gmail.com>

Co-authored-by: Ron <ron@swagger.io>
Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>

* Explain unclear semantics of property `$ref` in Path Item Object (#1964)

* Explain unclear semantics of property `$ref` in Path Item Object

Currently, as explained in #1038 (comment) the description of `$ref` in [Path Item Object](https://github.com/OAI/OpenAPI-Specification/blob/3.0.2/versions/3.0.2.md#pathItemObject) is unclear about the semantics behing it. I took the explaination from issue #1038 to make it more clear.

* Update versions/3.0.3.md

Co-authored-by: Ron <ron@swagger.io>

* Update 3.0.3 for release (#2149)

* Update README.md for release

* Update release date for 3.0.3

Co-authored-by: Darrel <darrmi@microsoft.com>
Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>
Co-authored-by: Sergej <sergej2705@users.noreply.github.com>
Co-authored-by: Seiya <r108338@yahoo.co.jp>
Co-authored-by: Alan Crosswell <alan@crosswell.us>
Co-authored-by: Rich Ellis <ricellis@users.noreply.github.com>
Co-authored-by: Phil Sturgeon <me@philsturgeon.uk>
Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
Co-authored-by: Ted Epstein <ted.epstein@reprezen.com>
Co-authored-by: Patrice Krakow <patrice.krakow@gmail.com>
Co-authored-by: Marsh Gardiner <marsh.gardiner@gmail.com>
Co-authored-by: Henry Andrews <andrews_henry@yahoo.com>
Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>
Co-authored-by: Erik Wilde <dret@users.noreply.github.com>
Co-authored-by: Carsten Brandt <mail@cebe.cc>
philsturgeon pushed a commit to philsturgeon/OpenAPI-Specification that referenced this issue Feb 18, 2021
* 3.0.3 prep

* Update README.md

* Update README.md

* Removed confusing comment

* Updated text for OperationRef

* Clarified supported Ecma edition for regex

Added supported Ecma edition (5.1) for regular expressions in the link text and used the formal name: [Ecma-262 Edition 5.1](https://www.ecma-international.org/ecma-262/5.1/).

See also: OAI#1687

* Make ABNF for runtime expressions complete

* json-schema.org and commonmark.org now support https

* Update 3.0.2.md

fixed typo

* Update 3.0.2.md

fixed typo

* Fixed typo

* Update 3.0.3.md

fixed typo

* Update 3.0.2.md

fixed typo

* explicit 'forward slash'

* add back quotes

* fix difference between yaml and json in Response Object Examples

* fix typo in Callback Object

* Update 3.0.2.md

* yaml.org supports https, but www.yaml.org is misconfigured

* allow, but discourage, requestBody for GET, HEAD, DELETE

* spelling error

* retain typo in v3.0.2; fix for v3.0.3 (OAI#1899)

* Corrected pattern regex dialect link

* TSC 2019-10-03 Feedback

This sentance was meant to paraphrase semver for clarifty, but ended up suggesting a confusion situation where new things essentially cannot really happen.

@webron has context on this.

* Ron's wording for Darrels feedback

* ted updates

* backticks

* Improved callback examples

* fix OAI#2053: `style` keyword is not supported inside Schema object

* Resolved undocumented nullable behavior (OAI#2046)

* Resolved undocumented nullable behavior

OpenAPI Schema Objects and JSON Schema have a few fundamental differences, and this clears up a bit of confusion about one of them.

* Added ted updates from oct 31st TSC

Co-Authored-By: Ted Epstein <ted.epstein@reprezen.com>

* Update versions/3.0.3.md

Co-Authored-By: Darrel <darrmi@microsoft.com>

* Fix 'Security Scheme Object' definition with OAuth 2.0 grant types. (OAI#2006)

* The examples keyword is not supported inside schema (OAI#2042)

* examples not supported inside schema

* figured it out

* a tiny little edit

* Replace 'application' by 'API' within the 'Info Object' definition. (OAI#2004)

* OpenAPI not Open API

* Revert "allow, but discourage, requestBody for GET, HEAD, DELETE"

* Clarify constraints on Security Scheme Object Scheme Property (OAI#1880)

* Wording around scheme extensions

* Clarified that securitySchemeScheme is only a SHOULD be registered scheme

* Fix formatting errors in example (OAI#2132)

* Server Variable Object clarifications (OAI#1809)

* Server Variable Object clarifications

* Toned language down for proper semver versioning

* Path Templating Clarification - proposed fix for OAI#1830.  (OAI#1831)

* Proposed fix for OAI#1830. Each variable expression in a path must have a corresponding path parameter.

* OAI#1830 - Removed 'at least once' to defer the question about repeated references to a single path parameter.

* Update OAI#1830 fix with suggestion from Darrel

@darrelmiller suggestions we use "template expression" instead of "variable expression" to align with RFC6570. Good idea.

* Clarify the spec to allow optional or unspecified OAuth scopes (OAI#1888)

* Referencing issue OAI#513. Clarify the spec to accommodate OAuth schemes where scope may be unspecified (optional scope) or where scope is not used at all.

* Removed the provision for default scope represented as empty string. This introduces some ambiguities in the Security Requirement Object that would need to be addressed.

* For OAI#513, adjusting language and removing examples

For OAI#513, adjusting language and removing examples as suggested by @webron.

* removed unnecessary example header

Co-authored-by: Ron <ron@swagger.io>

* Clarify empty Security Requirement Object usage and validity (OAI#1886)

* Clarify empty Security Requirement Object usage and validity

* Reorder sentences to make clearer.

* Remove wrong text.

* Removed unneeded text.

Co-authored-by: Ron <ron@swagger.io>

* fix a typo in the Security Filtering section (OAI#1837)

* fix a typo in the Security Filtering section

* Security filtering slight reword

Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>

* minor clarification for operationId usage in link objects (OAI#1733)

* minor clarification

it's a bit confusing that both the id and the reference are called "operationId", so this tweak makes the text a bit more explicit.

* use right terminology

Co-Authored-By: Mike Ralphson <mike.ralphson@gmail.com>

Co-authored-by: Ron <ron@swagger.io>
Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>

* Explain unclear semantics of property `$ref` in Path Item Object (OAI#1964)

* Explain unclear semantics of property `$ref` in Path Item Object

Currently, as explained in OAI#1038 (comment) the description of `$ref` in [Path Item Object](https://github.com/OAI/OpenAPI-Specification/blob/3.0.2/versions/3.0.2.md#pathItemObject) is unclear about the semantics behing it. I took the explaination from issue OAI#1038 to make it more clear.

* Update versions/3.0.3.md

Co-authored-by: Ron <ron@swagger.io>

* Update 3.0.3 for release (OAI#2149)

* Update README.md for release

* Update release date for 3.0.3

Co-authored-by: Darrel <darrmi@microsoft.com>
Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>
Co-authored-by: Sergej <sergej2705@users.noreply.github.com>
Co-authored-by: Seiya <r108338@yahoo.co.jp>
Co-authored-by: Alan Crosswell <alan@crosswell.us>
Co-authored-by: Rich Ellis <ricellis@users.noreply.github.com>
Co-authored-by: Phil Sturgeon <me@philsturgeon.uk>
Co-authored-by: nasa9084 <nasa9084@users.noreply.github.com>
Co-authored-by: Ted Epstein <ted.epstein@reprezen.com>
Co-authored-by: Patrice Krakow <patrice.krakow@gmail.com>
Co-authored-by: Marsh Gardiner <marsh.gardiner@gmail.com>
Co-authored-by: Henry Andrews <andrews_henry@yahoo.com>
Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>
Co-authored-by: Erik Wilde <dret@users.noreply.github.com>
Co-authored-by: Carsten Brandt <mail@cebe.cc>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants