On Wed, Nov 26, 2008 at 6:46 AM, Karl Kleinpaste <span dir="ltr"><<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
All you do is to convince me, again and again, not to generate OSIS.<br>
<br>
I absolutely do not care if it wouldn't pass muster "within an osisRef<br>
attribute." It passes muster NOW in ThML TODAY, because what I generate<br>
gets USED by people who wanted it YESTERDAY.<br>
<br>
ThML, to me, is about Getting Stuff Done, and using tools that<br>
facilitate Getting Stuff Done, as opposed to wanking over whether I've<br>
accommodated the Syntax Purity Demigods.<br>
</blockquote><div>I'd have to say that I don't like ThML. Too much like html. ThML makes it much harder for the frontend developer (me) who wants to process the text a bit more... <br><br>BPBible 0.4 uses an XML parser to parse text for indexes - well, for ThML and OSIS modules anyway (when can we get rid of GBF?). By having osisRef's which are consistent much processing time can be saved. With ThML there are two different forms of the passage tag, and they can really have whatever the writer wants in them. This then has to be parsed, etc. I also noticed that ThML modules are also much more likely to be invalid XML - which most parsers can't really handle. And then if they aren't XML, the fallback mechanism doesn't allow searching on xrefs and strong's numbers.<br>
<br>The sync tag is another thing I don't like about ThML. Rather than wrapping round the text, it occurs at the end. And rather than having 1 tag with (say) 2 strong's numbers and 2 morph numbers, it will have 4 empty tags at the end. Much harder to process if you want the user to be able to search on combinations of strong's and morph.<br>
<br>Also, using ThML makes it harder to guess what the meaning of the markup - rather than saying we have a catchWord, for example, we may put it in italics. And if we have included text (like in the KJV) and put that in italics as well, we presumably can't tell which is which. This type of thing makes advanced searches like "find the word "..." where it is added by the translator" impossible. OSIS lets you do extra formatting more easily. For example, BPBible displays poetry more like a print Bible would. Rather than having complicated markup in the module, all it needs is a <lg> tag and then <l> tags within it. <br>
<br>Another example - I've been wondering about using the ESV quote data to put different people's quotes in different colours. This would be quite easy to do as the ESV clearly marks what is a quote. There is still the question of what to do for nested quotes, but the actual inserting the colours would be easy.<br>
<br>However, I can see that ThML may be better for user editable content, as they just want to see bold text. But as we know, in this case the user would be wrong ;)<br><br>What really needs to be done, is to finalize how we are going to use osisRefs.<br>
I'd like to see modules being able to contain some mapping from osis ids to display names. I don't show the user Gen.2.2 in my application (or /Gen/2/2), why should I show them Ant.1.8.2 or (/Ant/1/8/2)?</div><div>
<br clear="all"></div>God Bless,<br>Ben<br>-------------------------------------------------------------------------------------------<br>Multitudes, multitudes,<br> in the valley of decision!<br>For the day of the LORD is near<br>
in the valley of decision.<br><br>Giôên 3:14 (ESV)<br></div><br>