[sword-devel] Getting stuff done (Re: External links)
Troy A. Griffitts
scribe at crosswire.org
Tue Nov 25 17:36:39 MST 2008
A few probably-abrasive (pre-apologies) comments on this thread.
OSIS is not meant for display layout markup.
Since our engine supports multiple output formats, screen sizes, layout
methodologies, etc., our module data should not be marked up in display
I understand why Karl uses ThML-- because gnomesword supports it. I
would ask him and others to consider supporting other frontends better,
and our general goal to move toward a 'semantically' marked up text
rather than a display oriented markup because of all the obvious
reasons-- linguistic research of the text, display abstraction and
customization, common interchange format between orgs, etc.
The practical matter is that it should be quite painless, after the
initial learning curve hit (which should prove itself to be short via
#sword discussions on irc) to convert thml markup to osis. But at
least, if there is no time for the extra work, to still consider it our
ideal to support a semantic markup.
support for external links:
There is currently no programmatic features in the engine which help or
hinder external links. Historically there has been a common conceptual
agreement that a 'reference' is to that of a 'general Bible'.
This needs to change, we all agree.
The agreed extension is to:
implement support for the key prefix on OSIS tag <reference
use the prefix to specify a sword module.
determine a set of meta modules like:
default the prefix, if absent to 'bible:' so current modules still work.
None of this requires engine changes, but rather that we extend the
historical conceptual idea of a reference beyond bible:key.
This is a frontend change. Just as gnomesword decomposes a reference
from ThML sword://module/key, it should also decompose a reference from
OSIS module:key and accommodate the meta modules above accordingly... as
should all frontends.
Now, the engine COULD definitely be extended to HELP the frontend
developers decompose these keys by pushing a common concept from our
frontends of 'user preferred strong dictionary', 'user preferred Bible',
etc. down into the engine, and then adding a 'module' component to a
key. This could have the effect of letting our verse parser take care
of the prefix and hand back a ListKey of entries each with appropriate
module components filled in. But this is just a first thought of how we
can help frontend developers support extending the reference concept.
The fact is, currently MOST frontends, when they see a reference pull up
the user's preferred Bible and show the reference. This logic needs to
change in the frontends.
Matthew Talbert wrote:
>> The point I was making was not that you can't encode it, but you lose the
>> semantic significance of it. The user can tell that <i>test</i> was added,
>> but the program can't - unless that is the only way <i> is ever used - which
>> it isn't. If you use italic formatting for anything else, you have lost
>> information - not presentation information - but the actual meaning is now
>> inaccessible to the program, as it can't necessarily tell what a particular
>> <i> means. If I want to mark translator added words in violet, or even allow
>> omitting them altogether, this is now not easily possible.
> I've been around long enough to know there is some disagreement here,
> but not long enough to really understand the issues. So my question
> isn't intended to create an argument, I just want to understand.
> If encoding in OSIS means that presentation information intended to be
> there by the publisher is lost, then why is that the preferred format?
> I would think that it would be really important to a publisher (or
> just to a module creator like me) that things are presented as they
> want them to be. Are you saying OSIS doesn't really allow that? If so,
> then shouldn't something else be used?
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel