-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Conversation
Thanks for catching this. However, I don't think what you have is quite what I intended either. 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
Excellent, the absence of |
Wait, which regex variant do you use? ;) |
@webron I use this tool http://ultrapico.com/Expresso.htm which uses .net's regex engine :-) |
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). |
@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. |
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. |
@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. |
Currently the expression given matches everything