Allow keys (names) to have non alpha numeric characters

[JoeyShapiro]

I am trying to create a key in an object like this

{
    "events(24hrs)": 3,
    "event": 3
}

I have to use the parens because of supporting legacy code.

However, when I do this with wjelement, I get an object with NULL. The key events(24hrs) or its value are never added to the object. I did some digging in the code and found out that this is caused by an alnumx check for each key. If the key is invalid, it bails and returns NULL.

The JSON interchange format is specified in RFC 7159. Section 4 says an object's "name" is a string, and Section 7 for strings gives a grammar for them to follow. They are a few rules for escaping certain characters, but most are allowed just as they are. In my case, the parens.

I tried to implement a new check to allow this, which is the subject of my Pull Request, and it works for my case just fine. However, I noticed that when you use WJEInt32 it is not asking for the key, but the path of the key. This means there is some advanced logic for characters like [].*/ and so on. So I do not think my idea will not properly work.

So I am wondering if you have a better idea, or are willing to help me think through a solution. Maybe add a function for using key instead of path, even though path would still have the problem of not supporting some characters.

I can implement this as a feature, I just really need your approval, and any ideas you have about this.

[penduin]

Just checking first things first - have you played with WJEChild() ? It bypasses our "selector" syntax and just uses the raw string to access keys. If that doesn't do what you need, then I'll take the time to look through your patch more thoroughly. It may be that we can be better about handling additional characters even in the functions that use our path/selector syntax rather than direct names.

…

On Thu, Sep 4, 2025 at 4:30 PM JoeyShapiro ***@***.***> wrote: I am trying to create a key in an object like this { "events(24hrs)": 3, "event": 3 } I have to use the parens because of supporting legacy code. However, when I do this with wjelement, I get an object with NULL. The key events(24hrs) or its value are never added to the object. I did some digging in the code and found out that this is caused by an alnumx check for each key. If the key is invalid, it bails and returns NULL. The JSON interchange format is specified in RFC 7159 <https://datatracker.ietf.org/doc/html/rfc7159>. Section 4 says an object's "name" is a string, and Section 7 for strings gives a grammar for them to follow. They are a few rules for escaping certain characters, but most are allowed just as they are. In my case, the parens. I tried to implement a new check to allow this, which is the subject of my Pull Request, and it works for my case just fine. However, I noticed that when you use WJEInt32 it is not asking for the key, but the path of the key. This means there is some advanced logic for characters like [].*/ and so on. So I do not think my idea will not properly work. So I am wondering if you have a better idea, or are willing to help me think through a solution. Maybe add a function for using key instead of path, even though path would still have the problem of not supporting some characters. I can implement this as a feature, I just really need your approval, and any ideas you have about this. ------------------------------ You can view, comment on, or merge this pull request online at: #113 Commit Summary - d9463d7 <d9463d7> idea for names File Changes (1 file <https://github.com/netmail-open/wjelement/pull/113/files>) - *M* src/wjelement/search.c <https://github.com/netmail-open/wjelement/pull/113/files#diff-c09a2d5cc05de311f77f89c6d3a255887cda2dfe9af35c9b4b339df1a17a7946> (17) Patch Links: - https://github.com/netmail-open/wjelement/pull/113.patch - https://github.com/netmail-open/wjelement/pull/113.diff — Reply to this email directly, view it on GitHub <#113>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJGVU4BBEPC46BJJWIWMHT3RCVQXAVCNFSM6AAAAACFVIZ5BGVHI2DSMVQWIX3LMV43ASLTON2WKOZTGM4DKNJTGMYDQMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JoeyShapiro]

could you give an example of how I could use WJEChild. I couldn't find anything on it. I need it to be something like WJEInt32

[penduin]

https://github.com/netmail-open/wjelement/wiki/WJElement-API *WJEChild* - Find, create or update an element by name instead of path. This allows access to elements that would be difficult to reference by path. No selector syntax is used, so only direct children of the element can be found. WJElement WJEChild(WJElement container, char *name, WJEAction action); Type specific actions may be done by passing the resulting WJElement and a NULL path to WJEBool(), WJENumber(), WJEString(), WJEObject(), WJEArray() or WJENull().

…

On Fri, Sep 5, 2025 at 3:36 PM JoeyShapiro ***@***.***> wrote: *JoeyShapiro* left a comment (netmail-open/wjelement#113) <#113 (comment)> could you give an example of how I could use WJEChild. I couldn't find anything on it. I need it to be something like WJEInt32 — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJGVU46O7QBQJDC2G2I6GD3RHX57AVCNFSM6AAAAACFVIZ5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENJZGY4DMMRZGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[JoeyShapiro]

so yeah, I can do something like WJEInt32(WJEChild(obj, "name()", WJE_SET), NULL, WJE_SET, 3);
a little cumbersome, but it does allow more characters in the name.

the path does not allow all characters, and some are used for the path processing.

[minego]

Yes, that is the intended way of doing that. The paths are meant to make it easy to use, but it is impossible to have pathing rules that allow any values since any string may be used as a key. I agree it is more cumbersome when dealing with objects that have less common characters in the name, but that was the trade off we made with the design of the API.

…

On Mon, Sep 8, 2025, at 9:02 AM, JoeyShapiro wrote: *JoeyShapiro* left a comment (netmail-open/wjelement#113) <#113 (comment)> so yeah, I can do something like `WJEInt32(WJEChild(obj, "name()", WJE_SET), NULL, WJE_SET, 3);` a little cumbersome, but it does allow more characters in the name. the path does not allow all characters, and some are used for the path processing. — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADSRCG32X6UNCCTHNBEBED3RWSCZAVCNFSM6AAAAACFVIZ5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENRWHE4DGMZTGQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JoeyShapiro]

alright, that is understandable, and I totally see the awkwardness it leads to. I can close my PR, unless you want to create a new set of functions that take the name instead of path.

[minego]

Thanks. I think it would be nice to have a good way to do this that would be less awkward. One option would be to define a special character to use in a path to indicate that the rest of the path should be taken as a literal value. That would mean you could simply prepend your name with that, and pass it directly. The rules for parsing paths would otherwise be applied normally, so that would even allow complex paths, but only the last portion could be a literal value.

…

On Mon, Sep 8, 2025, at 9:10 AM, JoeyShapiro wrote: *JoeyShapiro* left a comment (netmail-open/wjelement#113) <#113 (comment)> alright, that is understandable, and I totally see the awkwardness it leads to. I can close my PR, unless you want to create a new set of functions that take the name instead of path. — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADSRCAQZ6MMUSSX4A42GS33RWTBDAVCNFSM6AAAAACFVIZ5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENRXGAYTGMJXGA>. You are receiving this because you commented.Message ID: ***@***.***>

[JoeyShapiro]

I'm also debating allowing more characters to be used. currently you can only use characters in a path name that pass alnumx but only a handful of characters are keywords for the path.

maybe allow any character, and if you want to do path processing, then you need to escape it, or something.

I'm not sure if the path ones should be left alone, and only add new functions for non path parameters. And if the path versions are modified, do we have to worry about backwards compatibility