[sword-devel] osis2mod

[DJ Ortley]

I don't have too much of an opinion one way or another in regards to
implementing a full out validator in any of the utilities.  I think it would
generally be better than not.

There are a few points I'd like to make in regards to putting a validator in
things such as osis2mod:
a) If its not part of the Sword API, file size shouldn't matter since one
would not be expecting non-developers to be using this stuff
b) If a full out parser is added to some of the utilities, I would make that
a line in the sand saying, "don't reuse this code for the API"  Since the
idea is to keep the API as fast/minimalistic/general as possible (from what
I've gathered.)

I assume that LcdBible does not have tools such as osis2mod, xml2gdb, etc
packaged with it?  Or am I incorrect on this?

Of course, the benefits to not including a validator in the tool chain are:
a) smaller toolchain that someone with a dinosaur computer in the 3rd world
can work with when making modules for their native language
b) assuming the *nix ideal of, "programs that do one thing well" is a good
one, would a validator be a good fit for some of these tools or not?
c) are there unforeseen problems with validators?  If such and such a
validator can handle UTF-8/16/32, what about someone who's work is done in
some obscure code page? (I don't know much about validators, so this may not
be a big deal.)  Or what about the possibility that a validator doesn't
compile on such and such a system?


I'm sure between Chris and DM, many of these issues have been brought up,
but I think a public pros and cons list might be good for the discussion.


Option 3: we write our own light weight validator (assuming we can find
someone willing to?)

-DJ


On 4/26/07, Jan Knepper <jan at knepper.net> wrote:
>
> DM Smith wrote:
> > For the record, I think,
> >
> > It is the responsibility of the module developer to ensure that the
> > input to osis2mod is valid. Since there have been several versions of
> > the OSIS spec (currently at 2.1.1) it might be a reasonable question
> > as to which the minimum version we would accept. I'd go with 2.0 or
> > later. As long as Chris is the "pumpkin holder" of module creation,
> > it is not a big deal. But without validation being done by osis2mod,
> > there is no way to ensure this.
> >
> That depends I would tend to think on how the generic
> definitions/requirements for a module are written/defined.
> In the C/C++ world there is a LINT too... :-)
> But I am relatively new to the list, so do not take this too seriously.
> > Even with xml validation, it is very possible that an OSIS document
> > is not valid OSIS. Part of this is due to the milestoneability of
> > some elements, but no schema imparts semantics. So while schema
> > validation is important, it is not sufficient. Osis2mod needs to
> > ensure that the OSIS is sufficiently valid for the current front-ends.
> >
> If this is the case I guess XML validation should be extended with
> additional validation to make sure that the data contained in the XML is
> actually valid.
> > However, my suggestion that osis2mod use a real parser, was not
> > predicated on the need for validation. But rather the need to support
> > all well-formed inputs.
> >
> > Perhaps, I am biased by Java, but I think it can be done without
> > impacting program size significantly. In Java, the xml parser is an
> > implementation of an interface. At runtime it is possible to specify
> > an available implementation. I think that if we were to do something
> > similar in C++, perhaps choosing a SAX interface, we could wrap
> > XMLTag by it. And then one could link in either Xerces, Sword, or
> > some other implementation. Then the size/performance cost would be
> > appropriate for the use.
> >
> I guess the solution could be a standard parser interface which could be
> used by several parsers. I personally happen to like expat. It is small
> and fast. But as long as the interface is made *pluggable* in someway
> one could even decided to use a NULL interface that does no
> checking/validation at all. Could be done in via a dynamic library
> interface were a defined set of functions is being exported.
>
> God bless,
> Jan
>
> --
> ManiaC++
> Jan Knepper
> Phone: 609-628-4260
> FAX  : 609-628-1267
> Y!   : janknepper
>
> www.janknepper.com
>
> But as for me and my household, we shall use Mozilla... www.mozilla.org
> Get legal - Get OpenOffice.org... www.openoffice.org
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20070426/6258cb9a/attachment.html