<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/27/2017 08:33 PM, Daniel Owens
wrote:<br>
</div>
<blockquote type="cite" cite="mid:59CC436B.3090801@pmbx.net">It
would be ideal if all the front-ends supported the same format so
modules would work the same way everywhere.</blockquote>
<br>
<font face="FreeSerif">Two things:<br>
<br>
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.<br>
<br>
2. The real fundamental problem in Strong's search is semantic:<br>
<br>
Either the number is a NUMBER, or the number is a tokenized
STRING.<br>
<br>
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).<br>
<br>
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 <i>that</i>
entertaining semantic leap take place, and why is it specific to
the eventual dictionary lookup, rather than to the search itself?<br>
<br>
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.<br>
<br>
I'm not sure I can count the number of semantic conflicts all this
represents.<br>
<br>
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.<br>
<br>
But God help us, if we wait for the solution to this in Sword now,
it'll be <i>another</i> 3 years before a release.<br>
</font>
</body>
</html>