Over here, @ju-sh posed a few questions. I'll repost them here and follow up with an answer.
I had a doubt. Wasn't sure which would be the right place to ask.
From the website, I see that.
[ g . h . i ]聽is same as聽[g.h.i].
But how will
[ g h . i ]聽be parsed.
Will聽g h聽be considered as the first part of the key (not sure if I'm using the right terms (-: )?
Or is it an error?
And in table arrays, are white spaces allowed between the double braces. Is something like聽[ [ product]]聽valid?
Hi @ju-sh,
Each part of a table's key must be valid. Not counting dots, you need either a quoted or unquoted key. But space are not allowed in unquoted keys, so g h will raise an error.
Table arrays use double square brackets, and based on toml.abnf, the left brackets must appear together, and the right brackets must appear together. No whitespace is permitted between them.
I was gonna transfer the issue over, but I guess this is also fine?
I didn't know the protocol for issues like this, except we really haven't had issues like this. In any case, I wanted to offer an answer quickly. The Stack Overflow way of doing things says to ask and answer your own question if you think it would help, so I was influenced by that.
@ju-sh Hopefully this helped. Did it clear things up for you?
Thanks for the answer!
So if we need a key component with 'g h ' (with the space at the end), we can use ['g h '.i], right?
Or mixing quoted and unquoted key components not allowed?
And is there an online TOML validator that we can use to figure the correctness of our toml files?
The wiki mentions a few validators but it seems we need them installed. I mean, an online validator would be easier (if there's one).
I did find some online validators on searching the internet but wasn't sure they conformed to the specification closely enough.
Thanks for the answer!
So if we need a key component with 'g h ' (with the space at the end), we can use
['g h '.i], right?Or mixing quoted and unquoted key components not allowed?
Mixing keys as in the example you have there is completely valid, and works exactly as you described.
It's potentially a bit visually confusing if your keys get more complex, but technically correct all the same.
Okay, thanks. That's clear to me now.
And regarding dates and times, can they be inside quotes?
ie, like ld1 = "1979-05-27" instead of ld1 = 1979-05-27?
And regarding dates and times, can they be inside quotes?
ie, like
ld1 = "1979-05-27"instead ofld1 = 1979-05-27?
Nope. Adding quotes makes it a string that _just so happens_ to contain a correctly-formatted RFC 3339 date, but it's still a string value, and a conformant parser won't interpret it as a date.
I find the title of this issue rather alarming, as if the whole toml language is at peril (so I rushed over to check what was up, fire hose ready). Maybe change it like the original Q, like "doubts related to table keys in toml"?
@abelbraaksma @pradyunsg Either rename it, or close it if all questions are answered. I didn't intend for this to be an open-ended thread. And since we can continue the conversation here if it's warrented, or open new issues, probably we can close this issue sooner than later.
@ju-sh Thanks for your questions. If you have questions that the website or this spec don't seem to answer, feel free to ask. Even if they have ready answers, questions like these do help us consider improvements to make things more obvious.
Now that GitHub allows issues to be 'pinned' not unlike forum posts, perhaps a pinning "TOML questions here!" Issue would be useful.
Either rename it, or close it if all questions are answered.
@eksortso You're the owner of the issue, only you can edit or close, I don't have those rights.
But not a big deal either way ;)
Most helpful comment
Nope. Adding quotes makes it a string that _just so happens_ to contain a correctly-formatted RFC 3339 date, but it's still a string value, and a conformant parser won't interpret it as a date.