[sword-devel] Getting stuff done (Re: External links)

[Troy A. Griffitts]

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 
layout markup.

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 
osisRef="module:key"> syntax.

use the prefix to specify a sword module.
determine a set of meta modules like:
bible:
strong:
self:

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?
> 
> Matthew
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page