On Jun 5, 2013, at 4:07 AM, Chris Little <chris...@crosswire.org> wrote:
> On 6/3/2013 2:20 PM, DM Smith wrote: >> >> On Jun 3, 2013, at 3:53 PM, Chris Little <chris...@crosswire.org> >> wrote: >> >>> 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. > > Like Nic, I saw the gatekeeper's rejection of Scope as an end to the > issue--given that no one countered his rejection or offered solutions. > > If something programmatic can be done to populate Scope--either on the > client side or the server--then I could conceive of the proposal becoming > viable once again. > > I never had a dog in the Scope fight. I think my only two comments were that > I preferred Scope over Coverage as the name for the attribute and that I > truly hated the idea of using Scope to define ad hoc versification systems. I > don't object to a Scope attribute in general, but at this point in time, it's > not part of Sword and shouldn't be part of the .conf documentation. That > being said.... > >>> 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. > > I've brought the Scope documentation back to the .conf article's Talk page. > It can be archived there (or amended as necessary) until there's actually > some consensus on what, if anything, should be added to .confs to reflect > scope. Thanks for putting it in the talk page. Often a topic that has been quite for a while will come back up. I think it is a good idea to capture state of the conversations in the wiki, perhaps with links to threads, so that we don't rehash old as new. > >>>> 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. > > Not to worry, no offense was taken. I'm happy to discuss > Feature=NoParagraphs to make sure everyone is happy, within reason. > >>> 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? > > That seems like a reasonable argument, and I might be amenable to the > addition of a feature to indicate presence of actual introductory text. > That's not how I read the initial request, but it was somewhat vague. > >>> 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. > > Indeed, there were concerns raised that were completely irrelevant. > > Whether we increment .conf version numbers has no bearing on whether we add a > new Feature value. We've had a standard practice of incrementing only the > third most significant digit of module Version numbers in cases where only > the .conf file needs to be re-downloaded. (You can search the archives for > discussion, but this has been our (my) standard practice for quite a few > years now. It wasn't noted in the .conf documentation, but I've now amended > the description of Version to reflect this.) We've had conf documentation for quite a while. I moved it to the wiki, way back when. The version number from the earliest day was documented as a number. Major.Minor. The latest release of the JSword engine was based upon that documentation and stores it as a decimal value. If it is not, an exception is reported and the default of 1.0 is used. The next release (and what AndBible and STEP currently use) change this to a 3 part number. It still expects each part to be numeric so that it can sort each part. I did notice that they are being used this way. If we want to use version for this purpose, I have no objection. I did notice that they are being used this way. I like the clarity that the third part refers to conf changes that do not require the module to be downloaded again. However, I think that non of the current front-ends use that third part to distinguish what modules need to be downloaded and what does not. > > Rendering of modules with paragraphing obviously has no bearing on treatment > of modules with Feature=NoParagraphs. The addition of excess whitespace is an > entirely different issue from what I'm hoping to address with this feature. I > specifically and explicitly only want to indicate to the front end author > that a module with Feature=NoParagraphs has no paragraphing information and > should, as a result, probably be rendered with newlines at the end of each > verse by default. > >>> >>> 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. > > Yep. ;) And that's what I'm hoping we can fix (or at least provide a solution > to fix in the future). And yes, I'll have it (or whatever is ultimately decided) in the KJV conf. :) In Him, 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
