[sword-devel] Scope/NoParagraphs

[Chris Little]

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.

>>> 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.)

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).

--Chris