[sword-devel] osis2mod

[Jan Knepper]

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