On Jun 3, 2013, at 3:53 PM, Chris Little <chris...@crosswire.org> wrote:
> On 6/3/2013 5:55 AM, DM Smith wrote: >> I saw that Scope was yanked from the wiki with a comment that it had >> been rejected. I really don't remember it being rejected. I just >> remember that the discussion never went anywhere so it was dropped. I >> documented the desire of that discussion by putting an entry into the >> wiki. Even if engine support is given for determining this by >> examining a module, it will be far slower than having a declaration >> in the conf. On phones (low powered devices), such discovery is much >> too expensive and needs to be cached on a per module basis so that it >> is not recomputed. >> >> I still think that it is very needed. I'm getting tired of how such >> discussions go. > > This is the message in which I would say that scope gets rejected: > http://www.crosswire.org/pipermail/sword-devel/2012-February/037148.html I certainly didn't read it that way. > > None of Troy's concerns are addressed, Troy merely listed a few things and said he didn't like each. He didn't say why so there was no opportunity for further discussion. > and the rest of the thread devolves into off-topic irrelevancy. The rest of the thread was off topic for the question at hand, but not regarding Scope (called coverage there). It was quite on topic. > Scope has certainly not risen to the level of being a part of our .conf spec. Right. That's why the wiki had it marked as proposed. It had not been agreed to. It contained the last state of the proposal. It meant that at a later date the conversation could be continued. > > If you feel that Scope should still be under consideration, I encourage you > to address Troy's objections. Answer to all objections: It can be handled automatically just like InstallSize. If it is there great. If not assume the entire v11n. He offered to whip up a speedy computation. There was concern expressed that it wouldn't be speedy enough for older iPhones. This has been recently discussed on another thread, with suggested API and a bump to get it in there. Once there, we'll empirically see whether it is fast enough. I'm working on similar for JSword. > >> I'm not at all clear why NoParagraphs was added as a Feature for the >> frontends to use. I don't remember any discussion of it here. I don't >> see the need for it. A frontend can examine each and every verse to >> see if there is paragraphing or other such structural elements that >> imply paragraphing. I have no intention of using it for the KJV. At >> least not without community discussion and buy-in. This paragraph was mean. I should not have said it this way at all. I was upset that Scope was pulled from the wiki when it had been there for over a year and NoParagraphing was added (based on a discussion that was further back than I could remember). Again my apologies. >> >> How is NoParagraphs any different than NoIntroductions (or >> Introductions) !!!!! > > They're quite different. There are an order of magnitude more verses than > introductions. Knowing whether to render a particular chapter (or other view > scope) as VPL or paragraphed would require doing a substring search through > every single verse of the module in order to maintain consistent rendering > across chapters. So that would make it about a 3-4 orders of magnitude more > work than checking for introductions at run time. (Compare the number of > bytes per Bible times the number of paragraphing elements to the number of > chapters per Bible. That's the difference in the order of work.) Chapter N, Verse 0 will have content in most new OSIS modules. Osis2mod retains pretty much everything. It will probably contain: <chapter osisID="xxxx"> <title>Genesis N</title> (Though it might not have the title.) This has no introduction. It does have content: Markup and titles. The only way to tell that it doesn't have an introduction is to parse it. I mentioned this in an earlier post. How is this any harder than parsing to see if there is are elements related to paragraphing? > > > Feature=NoParagraphs was discussed in 2009. Literally no one disagreed with > the proposal to add *something*. David asked about a feature like this a few > weeks back, prompting me to add the discussed and generally approved-of > feature to the wiki. I went with NoParagraphs rather than Paragraphs because > it's clearly the marked case and the fallback behavior for existing content > will be the current behavior. > > Original discussion thread here: > http://www.crosswire.org/pipermail/sword-devel/2009-November/033058.html I re-read the thread and there were objections. I don't think they were addressed before the thread stopped. The biggest was that people didn't want the module version number to be bumped when the only change was to the conf. The other big one was that the real problem with VPL was for modules that had paragraphing. (The desire was for frontends to know when to expect paragraphing so that VPL would not introduce so much blank lines. The whitespace issue is being worked. I don't know if it is encompassing the VPL whitespace issue.) I don't think we reached any more conclusion regarding the feature than for scope/coverage. > > It's informational for front end developers, so there are no implied > conformance requirements. If you want to render the KJV incorrectly by > default in Bible Desktop, that's your choice. Chris, in an earlier response, I apologized for my tone. I repeat that apology here. I really don't care one way or the other whether Feature=(No)Paragraphing is added to the conf. As far as I know, every frontend renders the KJV incorrectly by default. Together In Christ, DM _______________________________________________ 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
