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 <[EMAIL PROTECTED]> 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@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
