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.<br><br>There are a few points I'd like to make in regards to putting a validator in things such as osis2mod:
<br>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<br>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.)
<br><br>I assume that LcdBible does not have tools such as osis2mod, xml2gdb, etc packaged with it? Or am I incorrect on this?<br><br>Of course, the benefits to not including a validator in the tool chain are:<br>a) smaller toolchain that someone with a dinosaur computer in the 3rd world can work with when making modules for their native language
<br>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?<br>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?
<br><br><br>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.<br><br><br>Option 3: we write our own light weight validator (assuming we can find someone willing to?)
<br><br>-DJ<br><br><br><div><span class="gmail_quote">On 4/26/07, <b class="gmail_sendername">Jan Knepper</b> <<a href="mailto:jan@knepper.net">jan@knepper.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
DM Smith wrote:<br>> For the record, I think,<br>><br>> It is the responsibility of the module developer to ensure that the<br>> input to osis2mod is valid. Since there have been several versions of<br>> the OSIS spec (currently at
2.1.1) it might be a reasonable question<br>> as to which the minimum version we would accept. I'd go with 2.0 or<br>> later. As long as Chris is the "pumpkin holder" of module creation,<br>> it is not a big deal. But without validation being done by osis2mod,
<br>> there is no way to ensure this.<br>><br>That depends I would tend to think on how the generic<br>definitions/requirements for a module are written/defined.<br>In the C/C++ world there is a LINT too... :-)<br>But I am relatively new to the list, so do not take this too seriously.
<br>> Even with xml validation, it is very possible that an OSIS document<br>> is not valid OSIS. Part of this is due to the milestoneability of<br>> some elements, but no schema imparts semantics. So while schema
<br>> validation is important, it is not sufficient. Osis2mod needs to<br>> ensure that the OSIS is sufficiently valid for the current front-ends.<br>><br>If this is the case I guess XML validation should be extended with
<br>additional validation to make sure that the data contained in the XML is<br>actually valid.<br>> However, my suggestion that osis2mod use a real parser, was not<br>> predicated on the need for validation. But rather the need to support
<br>> all well-formed inputs.<br>><br>> Perhaps, I am biased by Java, but I think it can be done without<br>> impacting program size significantly. In Java, the xml parser is an<br>> implementation of an interface. At runtime it is possible to specify
<br>> an available implementation. I think that if we were to do something<br>> similar in C++, perhaps choosing a SAX interface, we could wrap<br>> XMLTag by it. And then one could link in either Xerces, Sword, or
<br>> some other implementation. Then the size/performance cost would be<br>> appropriate for the use.<br>><br>I guess the solution could be a standard parser interface which could be<br>used by several parsers. I personally happen to like expat. It is small
<br>and fast. But as long as the interface is made *pluggable* in someway<br>one could even decided to use a NULL interface that does no<br>checking/validation at all. Could be done in via a dynamic library<br>interface were a defined set of functions is being exported.
<br><br>God bless,<br>Jan<br><br>--<br>ManiaC++<br>Jan Knepper<br>Phone: 609-628-4260<br>FAX : 609-628-1267<br>Y! : janknepper<br><br><a href="http://www.janknepper.com">www.janknepper.com</a><br><br>But as for me and my household, we shall use Mozilla...
<a href="http://www.mozilla.org">www.mozilla.org</a><br>Get legal - Get OpenOffice.org... <a href="http://www.openoffice.org">www.openoffice.org</a><br><br><br>_______________________________________________<br>sword-devel mailing list:
<a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page
<br></blockquote></div><br>