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.

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

_______________________________________________
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

Reply via email to