In regards to the lowest common denominator comment you made, that's one of the things I thought would probably come up. Which is a thing I can understand. I didn't know that there was a lot of focus on speed, but it makes sense. I've been impressed with how fast Sword seems to work at times.
<br><br>I don't know much about how Sword stores its modules as there is no documentation I can find, and I've yet to actually ask whats going on. Right now I'm still working through the API trying to understand what's happening with the goal of finding a suitable way to implement access to the various Deuterocanons. Looking through the archives, I come to the conclusion that implementing such changes, as long as they are done the right way, are mostly acceptable to the community.
<br><br>The thing that prompted me to ask about DOM support was when I was looking through the source in the utilities folder. It seemed that a lot of work could be saved if some library were used.<br><br>Maybe things could be broken into two parts. The core API and the utilities, with the utilities having greater allowance for use of third party libraries that might not necessarily be suitable for a hand held... One isn't going to be using a handheld to make modules anyways (well, hopefully not at least.)
<br><br>Just a thought. Maybe not a good one, but there it is.<br><br>By the way, aside from poking around through the code, is there some sort of documentation or outline (aside from the API primer) of whats going on anywhere? If not, could someone give me a quick and dirty sketch of some sort?
<br><br>Thanks.<br><br>-DJ<br><br><br><div><span class="gmail_quote">On 3/9/07, <b class="gmail_sendername">DM Smith</b> <<a href="mailto:dmsmith555@yahoo.com">dmsmith555@yahoo.com</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;">
DJ Ortley wrote:<br>> Looking through the source code, it seems to me (which are key words<br>> that indicate this is only an opinion, one which may not be worth<br>> much) that using a library such as Xerces or some sort of XML DOM like
<br>> library would be of benefit.<br>><br>> I was wondering if any thought had been given to that previously?<br><br>This is the approach that JSword uses. We actually use JAXP which is an<br>interface layer over a plug-in implementation of XML. So in some cases
<br>we use Crimson and in others we use Xerces. It all depends upon what is<br>bundled with the user's JDK. SAX is a better model for most processing<br>than DOM, as most processing does not need an object representation of
<br><br>That said, I think that there are significant advantages and also<br>disadvantages to using it.<br>To me the most significant advantages are that it is a full<br>implementation of an XML parser and we don't need to maintain it.
<br><br>Disadvantages:<br>It is a full implementation of the XML parser. Sword doesn't need a full<br>implementation of the parser. Our documents have a well defined<br>vocabulary (i.e. the DTD specs) and we only need a parser sufficient to
<br>parse that vocabulary.<br><br>Parsing serves two purposes: search/indexing, i.e. stripping out only<br>the text from the "verse" and display, i.e. converting the module raw<br>source into some kind of presentation source. The former benefits from
<br>being very fast. Sword's "stripping" routines are built for speed. It<br>would be a huge performance loss to use a true XML parser. For the most<br>part, parsing for converting to a display representation can be slower
<br>because it will likely be fast enough.<br><br>The other thing is that the Sword library has taken a least common<br>denominator approach to its requirements. It is targeted to small<br>handhelds (phones, pdas and the like) and to computers of all ages,
<br>colors and creeds. Introducing a fairly large library would need to be<br>optional (like curl, icu4c and lucene) and it would still leave the need<br>for the current custom parsing.<br><br>Earlier I submitted a patch to make the parser more accurate and it was
<br>rejected as a performance hit and too big/risky of a change. And these<br>were the reasons that I was given.<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>