Fix the component name regular expression#994
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