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