DM:<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">But what we really need is not a parser but a tokenizer. I'm thinking
about writing one (my degree work was in compiler writing). Basically,
we repeat the same tokenization code in several places. It should be
trivial to write a complete, accurate one.<br></blockquote><br>I've also been wanting to work on a tokenizer. At Open Scriptures, the text of a work is currently represented by two <a href="http://github.com/openscriptures/api/blob/master/models.py">models</a> (database tables): <a href="http://github.com/openscriptures/api/blob/master/models.py#L242">Token</a> and <a href="http://github.com/openscriptures/api/blob/master/models.py#L315">Structure</a>. Tokens are the smallest divisible units of text, such as words, punctuation, and whitespace; and structures are the spans of tokens that form logical units, such as verses, paragraphs, quotes, etc. The structures are standoff-markup for the tokens. With the underlying data stored in this way, it can then be serialized in whichever hierarchy desired (book-section-paragraph, book-chapter-verse, all-milestoned, etc) or whichever data format is needed (OSIS, SWORD Module, XHTML, etc.)<br>
<br>So what I'm currently rumenating on is the process of importing the raw data into the Token and Structure models. I wrote an <a href="http://github.com/openscriptures/api/blob/master/importers/Tischendorf-2.5.py">importer</a> for the Tischendorf GNT data which does everything both tokenizing and parsing, but obviously there is going to be a lot of code in common with other importers that are written. So I too am thinking about how these importers can be reduced to the bare minimum to handle the unique aspects of the raw data (i.e. normalize it), and then stream the tokens back to a central importer that parses the input and stores it into the Token and Structure models. This central importer facility could be a web service.<br>
<br>I've love to collaborate with you on this. We could come up with a common tokenizer that can be used by both SWORD and Open Scriptures. The importer web service could take tokens as input and as output generate a SWORD module and also populate the Open Scriptures models at the same time.<br>
<br>Thoughts?<br><br>Weston<br><br><br><br><div class="gmail_quote">On Mon, Apr 5, 2010 at 10:24 AM, Daniel
Owens <span dir="ltr"><<a href="mailto:dhowens@pmbx.net">dhowens@pmbx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Yes, I agree, and if there
were a feedback mechanism for the module creator to let them know how
to start fixing an OSIS file or conf file, it would save Chris (or
whoever else approves modules) time on the basic stuff.<br><font color="#888888">
<br>
Daniel</font><div class="im"><br>
<br>
On 4/5/2010 11:09 AM, DM Smith wrote:<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
This is a great idea. Rather than emailing source to modules at
crosswire dot org, one could upload it via a web service. We could have
stages of validation (xmllint) and construction (osis2mod). Such a
service could evaluate the quality of the submission.<br>
<br>
In Him,<br>
DM<br>
<br>
On 04/05/2010 12:01 PM, Weston Ruter wrote:<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
Why not turn osis2mod into a web service? Then it wouldn't matter how it
is implemented since it would be abstracted away by the web service
interface. It could use the best XML libraries available today and
written in the programming language of choice, both of which would make
maintenance and the addition of new features much easier.<br>
<br>
Weston<br></div></blockquote></blockquote></blockquote></div><br><br><br><div class="gmail_quote">On Mon, Apr 5, 2010 at 9:05 AM, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On 04/05/2010 09:03 AM, Dmitrijs Ledkovs wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 5 April 2010 13:55, Manfred Bergmann<<a href="mailto:manfred.bergmann@me.com" target="_blank">manfred.bergmann@me.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi DM.<br>
<br>
Am 05.04.2010 um 13:21 schrieb DM Smith:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Regarding using a "real" parser, it is a good idea. But we don't want SWORD to be dependant on an external parser.<br>
<br>
</blockquote>
What's the reason for that?<br>
I could understand if it would mean for the user to install certain libraries manually but when the sources can be integrated into the project and has the appropriate licence then why not?<br>
<br>
<br>
Manfred<br>
<br>
<br>
</blockquote>
IMHO there is no harm in bringing in libxml or a much more lightweight<br>
parser like GMarkup. The build system just needs to be adjusted to<br>
link e.g. libxml for the osis2mod binary and not shared sword library.<br>
in can be even called a new tool osisxml2mod for example and make it<br>
be build optionally such that you can still have full sword dev<br>
environment without libxml.<br>
<br>
Tools for creating modules do not have be linked with sword or even<br>
live in sword taball / svn. Although it does help consistent<br>
distribution of tools.<br>
<br>
</blockquote></div>
I don't remember all of Troy's reasoning when I argued for a true parser.<br>
<br>