[sword-devel] Strong's Numbers Standards

[Karl Kleinpaste]

On 09/27/2017 08:33 PM, Daniel Owens wrote:
> It would be ideal if all the front-ends supported the same format so
> modules would work the same way everywhere.

Two things:

1. Any idea that needs to be carried out in "all the front-ends" is
stillborn.  If you ask for it today, you'll be lucky if it happens in
"all" of them by 2025.  Bear in mind that the zombie NASB is held up by
some mysterious support that isn't yet implemented in (I think) JSword
apps...going on 14 years delayed.

2. The real fundamental problem in Strong's search is semantic:

Either the number is a NUMBER, or the number is a tokenized STRING.

James Strong et al created a dictionary system using numbers, not
character strings.  But Strong's numbers are mis-treated as strings by
Sword because all keys and content of modules are strings, leading to
all manner of conflict over whether or not to pad -- and what is this
StrongsPadding thing that I never heard of until this evening? -- and by
how much (i.e. Hebrew single 0 prefix [e.g. H01, cf. KJV Gen.2.24] -vs-
exactly 5 ASCII digit characters, and so forth).

If the engine itself considered that a Strong's NUMBER is in fact a
NUMBER, then it would be simple enough to accept any NUMBER search
argument, parse it internally as the integer it actually is, to whatever
is convenient (and then I suppose StrongsPadding would make sense),
ignoring the incoming make-up of the string-formatted NUMBER. 
Interestingly, search of KJV for H01 finds Gen.2.24, but H1 does not,
nor does H00001; yet the successful discovery of H01 in Gen.2.24 then
leads to a clickable link in that verse that correctly references key
"00001" in a Strong's Hebrew dictionary module.  Where and how did
/that/ entertaining semantic leap take place, and why is it specific to
the eventual dictionary lookup, rather than to the search itself?

The user should be able to search for any of H1, H01, H001, H0001,
H00001, or H000000000000000000000001 to find Gen.2.24.  That's because
the absolute dumbest Sword app user is smarter than Sword itself,
because he knows that this "1" thing is a NUMBER, not a STRING, so that
all forms of "H followed by a bunch of zeroes followed by a 1" are
semantically the same, and he doesn't give a rat's patootie about the
evil machinations going inside the black box that provides search
results, or in the conflicted peculiarities of module markup.

I'm not sure I can count the number of semantic conflicts all this
represents.

The semantic flaw is in Sword, and that is where it needs to be
corrected.  Once corrected in Sword, all the front-ends will fly just
fine, and you'll be able to find KJV Gen.2.24 with a search for H1 or
H000000000000000001, because the fix will operate under the front-ends'
hoods.

But God help us, if we wait for the solution to this in Sword now, it'll
be /another/ 3 years before a release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20170927/7132377f/attachment.html>