Skip to content

Fix the component name regular expression #994

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

Merged
merged 1 commit into from
Mar 27, 2017

Conversation

MikeRalphson
Copy link
Member

Currently the expression given matches everything

@darrelmiller
Copy link
Member

Thanks for catching this. However, I don't think what you have is quite what I intended either.
I think we want ^[a-zA-Z0-9\.\-_]+$

The tool I was using didn't require the period to be escaped, so I didn't. The slash prior to the hyphen was an escape character, not an allowance of slashes!

Currently the expression given matches everything
@MikeRalphson
Copy link
Member Author

MikeRalphson commented Mar 15, 2017

Excellent, the absence of \\ makes the regex easy enough to read without needing any explanatory text I think. Commit amended.

@webron
Copy link
Member

webron commented Mar 15, 2017

Wait, which regex variant do you use? ;)

@darrelmiller
Copy link
Member

@webron I use this tool http://ultrapico.com/Expresso.htm which uses .net's regex engine :-)

@webron
Copy link
Member

webron commented Mar 15, 2017

I'd just suggest we keep it to http://json-schema.org/latest/json-schema-validation.html#rfc.section.5.8 compliance across the doc (not that we have that many regular expressions in it, thankfully).

@MikeRalphson
Copy link
Member Author

@webron @darrelmiller it would be nice to be able to state that regular expressions SHOULD be interpreted as per ECMA 262 (Perl-5 style). But the reality is most tooling will use their native regexp parser, which may be POSIX BRE for example.

@webron
Copy link
Member

webron commented Mar 15, 2017

See #880.

If tooling will choose to use a different regex parser, they'd be non-compliant. Since we agreed our standard is based on JSON Schema, it is what it is. Can't guarantee cross-platform functionality without it.

FWIW, we've had similar issues in the past in some tooling and but us and the community ended up fixing those.

@ePaul
Copy link
Contributor

ePaul commented Mar 15, 2017

@MikeRalphson I think for expressions in the specification document (i.e. static ones), tool implementation authors can translate them easily to whatever their library supports. So we are free to choose whatever we want here, as long as we make it clear what it is.

For expressions appearing in an API definition document (i.e. in schemas), it is not so easy ... but we still should make clear in the spec which regexp flavor we want there (the same as JSON schema, I guess). If implementations don't support this, they will be not fully functional then.

@webron webron merged commit 6f24bb1 into OAI:OpenAPI.next Mar 27, 2017
@handrews handrews added this to the v3.0.0-rc1 milestone Feb 8, 2024
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

Successfully merging this pull request may close these issues.

5 participants