Your implementation is simple enough, but it requires that people reference the verse as being part of the Prayer of Azariah, verse 2 or verse 8 or so on. In all of the print copies I've seen of the book of Daniel that include the Prayer of Azariah, the verses of the prayer simply part of the verses of chapter 3 of Daniel so that the chapter is expanded out to about 100 or so verses. I have never seen the repetition of numbering, except when the complete version is giving the alternate schemes. When I have seen it, the verses have been along the lines of
1 2 3 . . . 23 24 - The prayer begins here, or at whichever verse 25 26 27 . . . 96 97 - Here is the end of the prayer (or at whatever actual verse # it is) 98 or 24* 99 or 25* . . . The * usually references a footnote where the explanation that the Hebrew does not contain the prayer, and so it uses the second numbering scheme. The Prayer of Azariah is not a separate work nor included as its own chapter. What would the module behave like if someone references Daniel 3:88, which is beyond the scope of the chapter in versions that Protestants and Hebrews use, and therefore is not available because the module creator used your numbering scheme? Or, what if your proposed scheme is used and someone references Daniel 3: 30, which appears in the Hebrew/Protestant as the last verse in the chapter or in the Greek/Catholic as an early portion of the prayer of Azariah? That could either be left to the VerseTreeKey implementor to give these specifics, or there could be some mechanism designed so that the module creator could specify that. Which is preferable? I would tend toward allowing the module creator implement whatever scheme they desire, but make standardized recommendations (those already made in the OSIS doc referenced earlier) for possible mappings that could be made specifically for cases like these. Then, if the module creator decided to, when a verse was referenced as PrAzar 1:8, it could be automatically translated into Daniel 3:31, or, at the module creator's discretion, a reference to Daniel 3:31 could be translated to PrAzar 1:8. Then, in this case, we might recommend that the person specify mappings so that, if PrAzar was implemented as separate from Daniel 3, then Daniel 3:24-30 KJV -> Daniel 3:97-104 (again, or whatever the real verses are) Daniel 3:24-96 -> PrAzar 1:1-72 If the module creator had implemented the Prayer as part of Daniel 3 then the mappings could specify PrAzar 1:1-72 -> Daniel 3:24-96 Daniel 3:24-30 KJV -> Daniel 3:97-104 Alternatively, the module creator could just not specify any mappings, and if someone references the passage in a manner that is not available in the module's implementation, then they are out of luck. It might not be entirely elegant, but it does allow for flexibility. And certainly the mappings file could contain nearly any mappings that the module creator suggested. I think that the more leeway we give the module creators, then the more appealing the implementation will be, as long as it's not inaccessibly complicated. On 3/12/07, Chris Little <[EMAIL PROTECTED]> wrote: > RawGenBook can hold out-of-order IDs without issue. So if a Bible puts > Daniel 3:4 before 3:3--or even Daniel 4 before Daniel 3--that's no > issue. The module maintains its own data ordering, unlike VerseKey > modules, which use a static ordering. > > But it definitely can't handle multiple instances of the same ID like > you describe. I can't necessarily even think of a good solution in which > such a beast might be managed. But I don't believe we're talking about > two instances of Daniel 3:24, rather one of Daniel 3:24 and another of > Azariah 24 > > One solution is simply to extract Azariah from Daniel 3 and put it in > its own book. > > Perhaps a nicer solution would be to embed Azariah within Daniel 3 in > the tree structure like this: > > Dan > |-1 > |-2 > |-3 > | |-1 > | |-... > | |-23 > | |-PrAzar > | | |-1 > | | |-1 > | | |-... > | | |-90 > | | > | |-24 > | |-... > | |-33 > > So the two identified identical IDs would be /Dan/3/24 and > /Dan/3/PrAzar/1/24. 'Dan 3:24' points at the former and 'PrAzar 24' > points at the latter. > > Front-ends, when they get either reference and want to display a full > chapter at a time, should travel up the tree until they find the second > level (/Dan/3) and then travel through all of that node's descendants to > compose the output--maybe with a little "Prayer of Azariah" title where > it crosses into the embedded book. (Basically the same behavior as they > already do for GenBooks with a DisplayLevel set.) > > Now that I look at it, maybe that is a fairly elegant solution and not > overly difficult to implement. > > --Chris > > > Jeremy Brown wrote: > > One thing I thought of regarding the indexing for a RawGenBook that is > > being talked about, and using a book/chapter/verse keying scheme. I don't > > know if this is a problem, but I have seen at least one version that used > > the some verse numbers twice in the same chapter. In a Croatian > > translation of Daniel 3, which includes the Prayer of Azariah, the text is > > numbered from 1 to 90, and then (after the Prayer of Azariah is over) > > starts numbering again from 24 to 33. So there are two different verses > > called Daniel 3:24, and they are separated from each other by 66 verses. > > The same for Daniel 3:25, 3:26, ... 3:33. > > > > In Unbound Bible I've "solved" this by chopping Prayer of Azariah out of > > Daniel and putting it in its own "book". But it seems if you want to > > really make the text and the verse system the same as it originally was, > > putting two of the same book:chapter:verse indexes in the text could be > > problematic. > > > > Maybe this is too esoteric or fringe-case to consider though, or maybe the > > indexes that are being used don't have to be unique, but since I thought > > of it I thought I'd share. > > > > Jeremy > > > > sword-devel@crosswire.org on Monday, March 12, 2007 at 3:04 PM -0800 wrote: > >> There's some skeletal code in the VerseTreeKey class. > >> > >> We have VerseKey, which represents the key type of verse-based modules > >> (Bibles & commentaries). And we have TreeKey, which represents the key > >> type of hierarchical tree-based modules (RawGenBook). RawGenBook modules > >> can contain anything, as long as it is organized as a hierarchical tree. > >> > >> Since Bibles are arranged as hierarchical trees of verses within > >> chapters within books, we can use the RawGenBook storage format to hold > >> Bibles and TreeKeys to access their contents, giving us much more > >> flexibility in terms of versification. > >> > >> Now we want to use VerseTreeKey to interface RawGenBook-type Bible > >> modules the same way we do RawVerse-type Bibles. > >> > >> > >>> When I hear and think of this project I come up with thoughts such as: > >>> > >>> --There should be no restriction on the names of books, the numbers of > >>> chapters and/or verses, or even the need to have discretized verses. > >>> These should be taken directly from the input OSIS file itself when > >>> the work is imported under the new scheme. > >>> > >>> --Since there is no restriction on the names of books, non-standard > >>> books (as-in, those not in the standard Protestant or Catholic > >>> scriptures), books like 3rd and 4th Maccabees, The Gospel of Thomas, > >>> the various books in the Book of Mormon, etc, would need to have > >>> allowable abbreviations specified in a configuration file distributed > >>> with the module > >> More or less. 3 & 4 Maccabees are part of the Bible. Thomas and the Book > >> of Mormon are not. If we want to change the goals at a later date, we > >> can, but the immediate objective is just to support books of the Bible. > >> Furthermore, since we need to use standard abbreviations, we shouldn't > >> be attempting to cram books into these modules for which abbreviations > >> are not defined. > > > > > > _______________________________________________ > > sword-devel mailing list: sword-devel@crosswire.org > > http://www.crosswire.org/mailman/listinfo/sword-devel > > Instructions to unsubscribe/change your settings at above page > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
