[sword-devel] OSIS links
dmsmith at crosswire.org
Wed Jan 19 11:35:53 MST 2011
On 01/19/2011 01:00 PM, Karl Kleinpaste wrote:
> a. The regex is a horror.
> b. The manual's definition is inconsistent, re: multiples.
> c. The () -vs-  syntax is wrong.
> d. Whitespace isn't allowed at all.
> e. Ignoring [d], there is a transform to something that ought to work,
> but it's not known whether it actually does work.
> 1. It's no surprise that the OSIS filters are never complete or correct.
> 2. And still people wonder that I won't use OSIS up to this point.
> Genbooks having whitespace in their keys is /de rigeur/. Nearly all
> genbooks have such keys. And yet now I learn that there is literally
> not supposed to be any way to reference such keys in an osisRef.
I think you summarized it well.
The OSIS reference is well designed for a biblical reference. It does
not work well for an arbitrary book reference.
Either one needs to have the OSIS reference extended to allow arbitrary
text for each part of the hierarchy or one needs to create a
well-defined mapping for it.
That . is used instead of / is a nit. But it means that a period in a
hierarchical part needs to be escaped. (Just as a / in a hierarchical
part would need to be escaped.) The engine would need to handle such
escaping, in either case. Without looking at the code, I don't know if
SWORD does either. JSword does neither.
Since the GenBook key tree is well defined a simple numerical mapping
would work. It would be up to the engine to understand 18.104.22.168 as
chapter 1, section 2, sub-section 5, paragraph 3, or whatever. Again,
SWORD and JSword would need to handle it, if it doesn't already.
Maybe it'd be good to do both: a) fix osis to allow spaces in parts and
b) allow numerical reference of a tree.
Regarding your point #1, the only way to have the SWORD OSIS filters and
code related to parsing OSIS references to work properly is to code them
to the spec. As it is they are incrementally changed on an as needed
basis to solve a particular problem that actually exists in a module.
Regarding this and point e, a robust test facility that defines "all"
possible inputs and their expected outputs would help.
Anyway, just thinking outloud.
More information about the sword-devel