[sword-devel] OSIS:What is the future? Who is using it now?

[Chris Little]

To make a long story short, OSIS is the best format for everything that 
Sword needs to do. It encodes Bibles richly and explicitly. It can 
contain every other type of book we handle (though none of these require 
the same level of richness in markup). And it's open and it's XML. And 
if there are problems with it, we can make recommendations for the next 
version to improve it.

GBF and ThML are incapable of the richness of markup that OSIS provides. 
ThML isn't especially good for Bibles (for which it was not really 
designed). GBF is a proprietary format and non-XML. XGBF still lacks 
richness and openness. (U)SFM, at the time we chose to standardize on 
OSIS, was a proprietary, not publicly documented, non-XML, 
non-standardized format; when we asked for documentation and offered to 
implement SFM in Sword, our offer was declined. USFX is proprietary and 
not a standard.

Of the above, the ONLY format a corpus of texts that is at all useful to 
Sword is ThML. (Before we planned to standardize on OSIS, we were more 
or less in the process of standardizing on ThML.) ThML texts are also 
available from CCEL in OSIS format, so we're safe in simply moving to OSIS.

The idea that standardization on OSIS will somehow slow development of 
Sword is unfathomably and absurdly illogical. There are a lot of things 
I would rather do than write a full new set of filters AGAIN for another 
new markup format, plus 2 for each existing data format for conversion 
purposes. Standardizing on a single format means providing a consistent 
feature set with all texts, rather than one set for one format and a 
lagging subset for another.

--Chris



Kahunapule Michael Johnson wrote:
> DM Smith wrote:
>> There is a simple advantage to supporting OSIS as the only format
>> going forward: Standardization.
> Standardization is sometimes a good thing. Sometimes it is a bad thing.
> 
> Suppose that I proposed a new standard for electrical power
> distribution, world-wide. Instead of 120 VAC 60 Hz, 220 VAC 50 Hz, and
> 250 VAC 50 Hz, depending on where you go, with all kinds of different
> plugs and sockets, that I proposed a new standard of 190 VAC, 100 Hz,
> with a new socket design different from all the current ones, so as not
> to cause problems with people plugging into the wrong voltage by
> mistake.  Would that be a good thing? It would provide lower
> electrocution hazard to the places where 220 VAC is the standard, lower
> fire hazard to places where 120 VAC is the standard, and would allow for
> less expensive transformers and less flicker in fluorescent lighting.
> Those are all good things. Could I sell it? Not likely, due to
> incompatibilities with existing power generation, power distribution,
> and power consuming equipment. It would just cost too much, and the
> benefits, though very real, would not be enough to counterbalance the cost.
> 
> Suppose that I declared that all lighting anywhere in a particular city
> must be done with the same kind of 38 watt fluorescent tube, no
> exceptions. Would that be good? It would certainly be standard.
> 
> A good standard is one that says something like, "if you want to connect
> your telephone to the public switched telephone network, you must use
> these signaling levels and specifications and this kind of connector."
> It doesn't prohibit alternate communication paths or prevent innovation,
> but it does allow competition and compatibility at the same time for
> people making telephones.
> 
> A bad standard is one that takes a suboptimal solution to a problem and
> makes it the only solution, or one that doesn't provide adequate
> compatibility with previous or future solutions.
> 
> I don't believe that it has to be all or nothing. Data format converters
> are cheaper than the hardware required to convert electrical
> distribution standards. Isn't one of the claimed advantages of OSIS ease
> of conversion to other formats? Without that, OSIS is pretty useless. Of
> course, OSIS has underlying philosophy differences with competing
> standards that make conversions more difficult-- kind of like changing
> frequency and voltage of an electrical power system. Just changing
> voltage is easy-- use a transformer or autotransformer. Changing
> frequency too  requires a motor-generator or solid state rectification
> and sine wave reconstruction. Changing philosophy of what and how to
> represent Scripture texts requires some manual intervention or very
> complex programming, instead of just simple transformations. That is one
> reason OSIS is a tough sell. Another is its excessive complexity.
> Another is its ambiguity, which is almost like trying to code to
> multiple standards anyway.
> 
> So, shall we standardize on the Commodore-64 for all of our computing needs?
> 
> OSIS has been around for a few years. Why isn't it being used more?
> 
> I'm not really totally anti-OSIS. I have used it enough to believe that
> I know what I'm talking about, and I have contributed feedback that I
> believe has helped improve OSIS. I just don't think it is the best
> solution for most of the Scripture-encoding uses involved in the work I
> do. If you want to work in OSIS, that is fine. In the still-hypothetical
> case that I encounter an OSIS text that I need to do something useful
> with, I could convert it to a format more suitable for the task at hand.
> It would take a little more work than dealing with some of the more
> common formats, and there is a high risk that some important information
> might be misinterpreted, but it would be something I could do. I would
> rather work with a better format.
> 
> A few years ago, XSEM was THE promoted XML Scripture standard. Why
> didn't we standardize on it and be done with it? There were many people
> who thought it could be improved upon, erg OSIS.
> 
> Now OSIS 2.1.1 is it... BUT it isn't good enough. OSIS 2.5 and OSIS 3.0
> are coming.
> 
> No, I don't think I buy the argument that standardization alone is a
> very good selling point for OSIS. It has to be demonstrated to be good
> for its intended purposes in use. It has to be accepted by more than a
> few software developers and publishers to be worth putting up with its
> imperfections. With wide enough use, millions of people put up with
> flickering fluorescent lighting. Maybe we should remove the flickering
> before setting a new standard?
> 
>> It gives us the opportunity to develop a rich and full architecture
>> rather than supporting a multitude of formats. We can focus on text
>> quality and quality delivery in a feature rich environment.
> Yes, but couldn't we do all of that more effectively with a better, less
> ambiguous, less complex, less lossy standard?
>> Ultimately this means that we make the Word of God more accessible.
>> Which is what I think we are all about.
> No argument there... just about the best way to do that.
>> Michael, thank you so much for your contributions to WEB and to the
>> sapphire cipher.
> You are welcome. :-)
> 
> 
> _______________________________________________
> 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