Greetings!

Working on a minor release of the schema and users manual for later this 
month. We are going to try going to a quarterly release cycle, two bug 
cycles with one minor and one major release (end of the year).

Any suggestions for either the schema or the users manual?

Hope everyone is having a great day!

Patrick
[...]

Patrick,

Recently, I have been working on Sword's KJV OSIS module. The following 
have come up as part of that effort.

I'd like to see a type="p" added to milestone, with marker="¶" in an 
example. (e.g. instead of <milestone type="x-p" marker="¶"/>) This is 
needed to encode a traditional KJV which has paragraph marks in the 
text, but does not have paragraphs.

Clarify <divineName>Lord</divineName>. What are the valid contents
of 
divineName? Is it meant for YHWH only? (See 
http://www.hebrew4christians.com/Names_of_G-d/El/el.html
for the Hebrew 
of other "divine names".) Should type='x-yhwh' be used for translations 
of YHWH? (as is given in one example) Should there be an indication that 
the traditional rendering is in small caps? Should it be assumed, or 
should the text be in all caps?

How should the acrostic of Ps 119 be encoded in the KJV. The ALEPH is a 
transliteration of א. How should the original be included?

I have noticed that some are using <l/> to represent a line break. 
Clarify that this is a container for the text of a line. And that <lb/> 
is the line break. Also clarify when <lb/> should be used and when 
<milestone type="line"/> should be used. These appear to be equivalent 
in the latest schema as they can be positioned anywhere. Formerly, <lb/> 
was greatly restricted.

Fix the allowable content of <w> to match that of <seg>, when it
makes 
sense. Specifically, <w> does not allow <transChange> but
<seg> does. 
However <w> allows for <seg>. Thus <w><seg>a 
<transChange>big</transChange> house</seg></w> is
allowed. To say it 
another way, one can include all the content that <seg> allows in a
<w> 
by nesting. This should not be necessary.

DM

Patrick Durusau wrote:[...]

Hi Patrick,
 
I'm coding a Strong's dictionary-like file, but also including derivatives  
of the words.  It would be really helpful to have a <note  type="deriv">
or 
some such attribute.  

Peace,

David

David,

DavidTroidl(at)aol.com wrote:
[...]

Hmmm, but is it a "note" as we would think of the structure of the 
original text?

Understand that one could code it as you suggest, but since we really 
want to address dictionaries more generally (hopefully by the major 
release late this year) I would rather not do something that is going to 
introduce confusion later on.

Is there a version of Strong's that would show the derivatives? Suspect 
it has other information about the words as well, yes?

Thanks for the suggestion. Hopefully we can get some information on what 
else one is likely to see and either provide a temporary mechanism or 
fold it into a more general one to appear later this year.

Hope you are having a great day!

Patrick

[...]

[...]

DM,

DM Smith wrote:
[...]
could key on <p marker="¶"> for rendering?

I think in terms of traditional analysis it really is a paragraph, even 
though marked with ¶ instead of the usual formatting for a paragraph, 
leading indent plus space before and after.

I lean against adding type="p" to milestone primarily since the p 
element is the default container element against which others cross. I 
suspect that adding p to milestone could lead to cases where other 
elements are no longer commonly treated as crossing p. Not an 
insurmountable problem but in terms of deriving common stylesheets that 
will work with "most" OSIS texts, it could be a problem.

Anyone else have any thoughts on this?

Curious about any thoughts on the broader issue of making the marker 
attribute more widely available? Afterall we can't anticipate how every 
division of text will be denoted in a text and having a way to easily 
include that information might be a useful general feature to add to 
OSIS. It does cross the line into recording display and not simply text 
structure, but we have done that on several occassions already.

My markup tendencies are to rely on markup structures only but I also 
realize there are people doing real translations that need easy handles 
for producing a text that will be useful to their readers. Or to put it 
another way, the goal of OSIS has never been to be the best theoretical 
encoding system for Bibles but a useful one.
[...]
broadly, in part because for research purposes I would be interested in 
all occurrences and would rely upon either the string so marked or 
attributes to handle the rendering. This will be clarified in the next 
version of the users manual.
[...]
the first letter in the verse proper? But rendered in the KJV as a 
header or title.

When you say the "original" you actually mean ALEPH, yes? Or do you mean 
א? Either way I think you have a good question.

Hmmm, well, if you are using <div>s for each Psalm, then use <div> 
children of <div> with <head> to capture that information.

How are you encoding the Psalms generally?
[...]

Good points.
[...]

Hope you are having a great day!

Patrick
[...][...][...][...]

On Jun 9, 2006, at 7:07 AM, Patrick Durusau wrote:
[...][...][...]

In the case of the 1769 and earlier KJV, the first verse of a chapter  
never has a  � marker. Rather it has a large, drop case letter for  
the first letter. Paragraph markers are at the start of verses, after  
the verse number. Only the OT, Gospels and Acts have paragraph  
markers. The rest of the bible has none.

The simplest way to encode the text would have been to put a  �  
literally in the text.

There are some problems with using <p marker=" �">..

1) It implies that one can properly position </p>. One would have to  
make two large assumptions: That chapters always have an implicit  
beginning paragraph which does not contain the mark and that chapters  
end with a paragraph mark. Further compounding this, the </p> cannot  
be place immediately preceding the <p marker=" �"> since that would  
place the verse marker in the prior paragraph. The verse marker needs  
to immediately precede the marker. Further, verse endings can have  
semantic rendering meaning. So one would need to determine whether  
the end paragraph should be placed inside the previous verse at the  
end or between the verses. Thus the markup might look like:

	.....</verse></p><verse osisID="Gen.1.2"><p marker="
�">....

I don't think this is

2) Rendering of a paragraph by software is problematic and various  
systems handle it differently. Generally, a paragraph is represented  
by the insertion of a blank line. Typically this is after the  
paragraph end. But some systems do it at paragraph begin. Some may  
apply indentation either in place of a blank line or in addition to  
it. I have seen a couple of modules that try to work around this by  
using an empty tag <p/> at the place where a blank line should be  
inserted. (Which I think is entirely improper)

The other problem is that of rendering a verse number. Conceptually,  
a typical paragraph would surround several verses. This would argue  
that the <p> should precede the <verse>. In the case of the KJV, it
 
does not surround verses, but surrounds verse text.

3) Existing software may not handle verse spanning elements. In the  
case of SWORD, if the <p> or </p> tags are outside of the verse,
the  
module making software ignores the content. (Which is a bug) The  
nature of a Sword module is that, with a couple of well-defined  
exceptions, only the content of a verse is preserved. That is what is  
between <verse> and </verse>.

Another system JSword (a Sword variant) processes verses one at a  
time and any verse that is not well formed is treated as being in an  
error state, needing recovery.

So my take on it is that the  � is merely something that should  
appear at the proper location. The simplest way today, is to inject  
it at particular points in the text. This is the nature of a milestone.

[...]

Traditional analysis would have surrounded the verse elements with  
the paragraph (yes, paragraphs can start and end mid verse.) But this  
would not work with the KJV without special processing.

With the marker attribute (and also the n attribute), I think it  
merely should be rendered in the place the attribute is found.
[...]

Patrick,

One thing I'd like to see is an expansion of the predefined values for
the "type" attribute of the <name> element.

The current values are: geographic, holiday, nonhuman, person, ritual.

There are a few others that I think would be helpful:

* object - e.g., Urim and Thummim, Asherim (Asherah poles), the
occasional named altar (Josh 22:34)
* peopleGroup - e.g., Israelites, Amorites
* memberOfPeopleGroup - an unnamed person (e.g., Israelite, Amorite)
that is nevertheless a proper name; could perhaps be subsumed under the
"person" type
* bookTitle - e.g., Book of the Wars of the Lord, Chronicles of the
Kings of Israel
* songTitle - in Psalm titles, e.g., "according to The Doe of the Dawn"
* language - e.g., Aramaic when referred to as a language (as in Ezra
4:7)
* month - e.g., Adar, Nisan
* religion - NT references to "the Way" and Judaism

Stephen Smith
Webmaster
Good News / Crossway
ssmith(at)gnpcb.org

-----Original Message-----
From: Patrick Durusau [mailto:patrick(at)durusau.net] 
Sent: Wednesday, June 07, 2006 4:20 PM
To: osis-user(at)whi.wts.edu
Subject: [osis-user] Corrections?

Greetings!

Working on a minor release of the schema and users manual for later this

month. We are going to try going to a quarterly release cycle, two bug 
cycles with one minor and one major release (end of the year).

Any suggestions for either the schema or the users manual?

Hope everyone is having a great day!

Patrick
[...]

DM Smith wrote:[...][...]
>>>
>>> Recently, I have been working on Sword's KJV OSIS module. The 
>>> following have come up as part of that effort.
>>>
>>> I'd like to see a type="p" added to milestone, with marker="�" in
an 
>>> example. (e.g. instead of <milestone type="x-p"
marker="�"/>) This is 
>>> needed to encode a traditional KJV which has paragraph marks in
the 
>>> text, but does not have paragraphs.
>>>[...]

This is what I would like to see, if anything at all is done. Maybe it 
is time for global marker and/or rend attributes.

This is just a rendering issue for paragraphs and there is no excuse for 
using some other markup when we have already defined the <p> element for 
that purpose. The issue is how to render them, one option being 
marker="�" for non-chapter-initial paragraphs along with rend="drop-cap" 
on the first letter of chapter-initial paragraphs.
[...]

I just searched through the full text of the 1611 edition of the KJV 
from Chadwyck-Healey (the He Version). Every single chapter except one 
begins with a bolded initial word (signal that it is a new paragraph). 
The only exception is Psalm 70, which is probably just a typesetting or 
copying error. This shows that every chapter begins a new paragraph, 
therefore we also know every chapter ends a paragraph and that every 
pilcrow marks the end of a chapter and the beginning of the next.
[...]

Verses are contained within the paragraphs, so proper markup should be 
something like:
  .....</verse></p><p marker="�"><verse
osisID="Gen.1.2">....

Placing the pilcrow after the verse number mark is a rendering issue.
[...]

The pilcrow mark follows the verse mark, but semantically, the verses 
are still contained within paragraphs.
[...]

(In case it wasn't apparent, I agree entirely.)
[...]

Paragraphs never start/end mid-verse in the KJV. (I just checked.)

--Chris

Hi Patrick,
 
Another suggestion.  The <hi> element seems to be there to  replace
<i> and 
<b>, but it has no option for 'emphasis' or strong  emphasis.  I'm
working on a 
New Testament translation, that I hope to  eventually get into OSIS.  Where 
the Greek explicitly uses the first person  pronoun, it indicates an emphatic 
use, and I set it in italics.  Could we  have an 'emphasis' attribute on the 
<hi> element?  (Or better yet,  change its name to something more
suggestive!)
 
A value of 'strong', or some such thing, would probably also be useful for  
those situations that require strong emphasis, but don't fit into the existing 

categories.  This wouldn't be a style distinction, but indicating a quality  
of the text.  

Peace,

David

David,

The <hi> element has the following enumerated values for its type 
attribute (in addition to allowing "x-" values):

acrostic

bold

emphasis

illuminated

iitalic

line-through

normal

small-caps

sub

super

underline

Courtesy of the OSIS editorial team and users who have made suggestions 
during the OSIS project.

Work has been discussed for more detailed markup for linguistic use.

Hope you are at the start of a great week!

Patrick


DavidTroidl(at)aol.com wrote:
[...]

[...]