hyphens are also characters used in book titles a lot. the space replacement should be underscores, which are not. i think that the spaces aren't a problem because of the separator character, and the spaces technically are part of the title, and that's how users will write them. it seems burdensome to me.
Okay, updated. What do you think?
Colons in titles aren't really a problem, as the tags are all formulated like d-tags, but I like using pipe to separate out the optional stuff.
Trying to keep chapter and verse notation Biblical, as lots of people are familiar with that.
https://wikistr.imwald.eu/nkbip-08*645eb808ac7689f08b5143fbe7aa7289baad2e3bf069c81d2a22a0d3b3589c18
Discussion
I could allow the alternative of using quotations, instead of hyphens.
`book:: Bible | "Song of Solomon" 5:1 | KJV`
`book:: "2 Ezra" preface:2-21`
`book:: "Wuthering Heights" "Ch XI":Preamble-8`
The books and chapters in the DRB have prefaces and preambles, not only verses.
that's not a big addition of complexity to parsing that field, seems reasonable.
yeah, not sure, not often appearing in titles but then you can escape them. familiar to json but not really exactly familiar to wikilinks. most wikilinks refer to URLs so they are without spaces but ... well, idk, it really depends. the point i'm making is that the [[]] and the | separators serve as anchors for segmenting and parsing the text, so spaces are bounded within it already. writing a scan through text for this is simple, first you look for [[ then once you find that you are looking for ]]. if you hit the end of the event } then nothing was found.
i really see no reason to not make it as human friendly as possible that what someone would write off the top of their head is likely in the tags as the "proper" version.
it needs a special parser. we aren't bound by the limitations of JSON. what's more important is we are bound by the lowest common denominator of the user interested in attempting to craft a valid reference token.