[sword-devel] OSIS links

[DM Smith]

On 01/19/2011 01:00 PM, Karl Kleinpaste wrote:
> Summarizing...
> 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.
>
> So...
> 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 1.2.5.3 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.

In Him,
     DM