[sword-devel] Scope/NoParagraphs

[DM Smith]

On Jun 5, 2013, at 4:07 AM, Chris Little <chrislit at crosswire.org> wrote:

> On 6/3/2013 2:20 PM, DM Smith wrote:
>> 
>> On Jun 3, 2013, at 3:53 PM, Chris Little <chrislit at 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