-
Notifications
You must be signed in to change notification settings - Fork 20
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
Valid identifiers #9
Comments
I believe the context for this issue is "dot child" (e.g. For consensus on digits as first identifier character, dot_notation_with_number and especially dot_notation_with_number_object are relevant. @remorhaz is currently investigating the use of identifier syntax as part of #5 and may wish to comment. |
See also cburgmer/json-path-comparison#42 |
☝️ possible duplication |
It depends whether we're looking at the main path or in filter predicates. In the main path, as in
there is a consensus to support a dash in identifiers. However, in filter predicates, as in
there is no such consensus. Only 13 out of 41 implementations support a dash in identifiers in filter predicates. Most do not. |
I am more in the camp of the non-dash supporters ... |
Closed in #102 |
What was the resolution? Do we allow hyphens? Was a PR needed to change anything? |
A valid identifier rule (for "dot child" and recursive descent) should be discussed.
[a-zA-Z_][a-zA-Z0-9_]*
key-dash
)$.-key
and$.key-
has not been investigated$.屬性
Proposal
\s
,\t
,$
,.
,*
, etc... This approach allows writing regexp similar to[^'".*()$?,>=<\-\:\@\[\]\s\t\n\r]*
. If this approach is confirmed a list of disallowed codepoints should be identified.-
should not be allowed as first identifier character[0-9]
as first identifier character should be investigated and discussed.The text was updated successfully, but these errors were encountered: