[Fwd: [sword-devel] Re: [osis-editors] OSIS 2.0.1 modules updated]

[Michael Paul Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you, Todd, for your input. Using something like <q n="" 
who="Jesus" sID="uniqueID"/>"Direct quotation of Jesus"<q n="" 
eID="uniqueID">, where setting n to an empty string means "use nothing 
for a quote mark" would solve the serious problem. Note that I used 
the n parameter in both start and end milestones, since starting and 
ending quotation marks may be different (typographic start and end 
quotes, for example). That would be awkward for non-milestoned markers 
that included quotation marks, but I would never use those, anyway. 
Just having a "standard" way to turn off the unwanted quotation mark 
generation currently associated with <q> and <speech> would be a 
much-welcomed change to OSIS. It would also save me a lot of work.

At 04:12 19-03-04, Todd Tillinghast wrote:
>Michael and Patrick,
>
>(Michael, Patrick forwarded this to me to get my thoughts.)
>
>The main point: For the language dependant issues (as well as for the
>suggested style-dependant issue for quotes, which lean away from a 
>style
>issue), it is possible to use the "n" attribute to provide a 
>suggestion
>as to how the quote mark should be rendered.  If n="" is used then no
>quote mark.  If n='"' then use the supplied character.  Naturally 
>these
>can be ignored by the processor.  This practice is used for the
>"presentation" value of a verse if it would be difficult to "compute" 
>as
>in n="2-6a" and for languages where the preferred number system and
>numeral characters may not be readily identifiable.
>
>If you want to create a suggestion for both ends of a quotation then 
>use
>a <q> milestone container.
>
>This is a slight stretch for the use of the "n" attribute in that it 
>is
>not a number, but can solve the presented problem AND is consistent 
>with
>how the "n" attribute is actually being used in practice.
>
>See more comments below.
>
>Michael, would this solve your problem?  (If accepted by the OSIS 
>core
>group we would add it to the User Manual as a standard practice.)

Yes, if I understand your suggestion.

>There are certainly language AND style-dependent rendering issues.
>Because there are style-dependant issues it is NOT appropriate to 
>encode
>those style preference in the OSIS document.

Some "style" (in the sense of linguistic style, not typographic style) 
decisions affect the actual text of the Bible. Those must be encoded. 
Typographic style decisions are best left to rendering processes, but 
linguistic style decisions, such as placement of commas before "and" 
or not and usage of colon, double-dash, and quotation marks, are part 
of the text and I will encode them.

>As for the language dependant issues (as well as for the suggested
>style-dependant issue for quotes, which lean away from a style 
>issue),
>it is possible to use the "n" attribute to provide a suggestion as to
>how the quote mark should be rendered.  If n="" is used then no quote
>mark.  If n='"' the use the supplied character.  Naturally these can 
>be
>ignored by the processor.  This practice is used for the 
>"presentation"
>value of a verse if it would be difficult to "compute" as in n="2-6a"
>and for languages where the preferred number system and numeral
>characters may not be readily identifiable.

The n parameter is most useful for chapter and verse markers in some 
languages and some special cases. If properly documented, it would be 
essential to the way I use <q>.

>What is "âEUR^(TM)"?

That is what happens to a Unicode single closing quote or apostrophe 
(same character) when sent through non-Unicode mail systems. The 
original, of course, was a typographic single closing quote (like ', 
but curly).

>> The other difficulty is that I am not yet convinced that the proper
>> punctuation marks would be reconstituted by software that reads 
>> OSIS
>> files.</p>
>
>There are different rendering styles for just about every 
>translation.
>Some do different things for punctuation.
>
>Some require that lines of poetry never wrap, some require that lines 
>of
>poetry always wrap to a third level indentation, some require that 
>lines
>of poetry wrap to a level of indentation one level more indented than
>the start of the line that is wrapping, some right justify section
>titles, some center section titles as bold text, some right justify
>section titles and then start the first verse of the section on the 
>same
>line as the section title.
>
>Some put inscriptions in their own block while others flow 
>inscriptions
>within the surrounding text.
>
>THESE ARE ALL PERSENTION STYLE ISSUES.  And YES if you want to 
>present a
>specific translation in a specific style you must follow the style
>guidelines of the rendering organization.

Yes, they are presentation style issues in a way, but they are unique 
in that they are not at all like other presentation style issues. They 
are tied much more closely to the actual text than to the translation. 
They are translational issues as far as the translators and publishers 
are concerned. Are you willing to alienate them by demanding that they 
not encode their preferences in OSIS?

>HOWEVER, this is not an artifact of OSIS.  PRIOR to OSIS the majority 
>of
>Bible agencies used some form of SFM files which did NOT include 
>these
>sorts of style information.  When they go to RENDER the Bible they 
>apply
>the style rules required by THEIR typesetting department.

The SFM files that I'm familiar with properly encode all quotation 
marks exactly where they should be rendered, usually as << for opening 
double quote, < for opening single quote, >> for closing double quote, 
and > for closing single quote. USFM allows either those or the actual 
punctuation. This IS a unique problem with OSIS.

>There is an accommodation for the continuation quote marks already
>present in the standard and enhanced with OSIS 2.1.  If there is a 
>need
>to mark some quotes as not having quote marks when rendered the 
>encoder
>is free to use subType to indicate that use.
>
>I would caution the use of the "type" attribute on <q> and <speech> 
>for
>this purpose because they will need if for other purposes.
>
>I would recommend against the encoding of presentation related
>information that does not change the meaning AND can be accomplished
>through the rendering style.

I would recommend against changing the punctuation of the translation. 
Period.

>The words of Jesus should be marked as <q who="Jesus"> or <speech
>who="Jesus">.

I know that is your preference, and I sort of did that. The serious 
problem arises in that I reject your philosophy of quotation 
rendition, and you have tied those markers to that philosophy.

>      <p>OSIS does not currently support footnote start anchors.
>> Therefore, these
>> start anchors have been represented with milestone elements, in 
>> case
>> someone
>> might like to use them, for example, to start an href element in a
>> conversion
>> to HTML.</p>
>
>There is no need for anchors because the <note> element should be 
>placed
>where the note marker should occur.  IF you want to mark the range of
>the catchword in the text file you can use <catchWord> with an 
>osisRef
>attribute with the grain.  This was added for this very purpose.
>
>He may not like the way we accommodate footnote anchors but we have
>accommodated them.

You are right. I don't like it, but it can be made to work with 
additional processing.

>>      <p>Traditional psalm book titles are rendered as text rather 
>>      than
>> titles, because
>> the title element does not support containing transChange elements, 
>> as
>> would be
>> required to encode the KJV text using OSIS title elements.</p>
>
>We should add <transChange> to <title>.

Amen.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: http://eBible.org/mpj/gpg.htm

iD8DBQFAWhghRI/gxxfXR7sRAp3DAKCvQRJc9TFztX/1a+JvcLFE+yzVuACgqJ6d
OEcWH3jn9Jy+43994KzwJlQ=
=ElLx
-----END PGP SIGNATURE-----