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

Todd Tillinghast sword-devel@crosswire.org
Thu, 18 Mar 2004 19:57:15 -0700


Michael,

I think you should view the character within the "n" attribute as a part
of the text AND a way to override the default behavior.  I think that
overriding the default with nothing and then putting the quote mark in
the text itself is an unfortunate direction and makes the quote mark no
more or less a part of the text.

How is encoding <q n='"' sID="uniqueID"/>text<q n='"' eID="uniqueID"/>
making the quote marks any less a part of the text as compaired with <q
n='' sID="uniqueID"/>"text"<q n='' eID="uniqueID"/>.

Facts:
1) The majority of encoders WILL NEITHER encode n='"' NOR include the
quote mark in the text itself
2) The encoding of quotes using <q> is strongly encouraged
3) The default case for rendering a <q> element for MOST ENCODINGS AND
RENDERING PROCESSES will almost certainly be to add a starting and
ending quote mark and the better process will process the "n" attribute
(if it is adopted as a standard process)
4) You are more likely to get the results you want by NOT putting the
quote mark in the text itself.

Todd

> -----Original Message-----
> From: Michael Paul Johnson [mailto:mpj@eBible.org]
> Sent: Thursday, March 18, 2004 5:17 PM
> To: Todd Tillinghast; 'Patrick Durusau'
> Cc: sword-devel@crosswire.org; osis-editors@bibletechnologieswg.org
> Subject: RE: [Fwd: [sword-devel] Re: [osis-editors] OSIS 2.0.1 modules
> updated]
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> At 09:06 19-03-04, Todd Tillinghast wrote:
> >Michael,
> >
> >I think you will find that in the majority of cases that you will be
> >using <q> milestone containers rather than <q> containers because
> >quotes
> >often cross other hierarchies, so the use of milestone exclusively is
> >not much of a loss anyway.
> 
> Agreed.
> 
> >However, I would still recommend AGAINST <q n="" sID="UniqueID"
> >who="Jesus"> to cause there to be no quotation marks for red letter
> >Bibles.  The reasoning being that this IS truly a rendering issue.
> >If
> >you render the same OSIS document without red letters you will render
> >with no quote marks or at least have to check to see if the were left
> >off because the who is Jesus.  It makes more sense to include the
> >quote
> >marks as the default and then IF the rendering process uses red
> >lettering when it sees who="Jesus" THEN drop the quote marks.  The
> >point
> >being that the same OSIS document should be able to render a red
> >letter
> >edition as well as a all black letter edition, by using the n="" for
> >who="Jesus" cases you are LOOSING information.
> 
> WHY do you think I would be losing information? If I mark the
> quotations of Jesus as I said, using something like <q who="Jesus"
> n="" sID="uniqueid">"actual quotation here inside of real quotation
> marks of the kind appropriate to this language and translation"<q n=""
> eID="uniqueid">, then you always have the correct punctuation, with no
> loss of information, regardless of if you are creating a "red letter
> edition" or a "black letter edition." There seems to be no good reason
> for your recommendation. Am I missing something?
> 
> I NEVER want ANY use of <q n=""> elements to result in generation of
> punctuation of any sort, including quotation marks. I intend to ALWAYS
> include the proper punctuation in the text itself, and always use the
> n="" parameter, except in one case (described below). IF you generate
> quotation marks from the XML markup that says not to, then YOU
> INTRODUCE ERRORS TO THE TEXT. If you honor the n="" attribute as you
> described it, then there are NO ERRORS INTRODUCED AND NO LOSS OF
> INFORMATION.
> 
> Let me put it another way. You seem to think that it is a good feature
> to have XML markup generate quotation marks. I believe such behavior
> is very bad most of the time. It is not a feature. It is a bug. I
> understand that you have been taught to think this way from your
> ethnocentric view of the English-speaking universe, but I see things
> much differently from my cross-cultural and multi-lingual experience.
> 
> Am I that unclear in what I am saying?
> 
> I want to totally separate two issues: (1) placement of quotation
> marks and what exact characters are in use, and (2) marking of Jesus'
> words only for the purpose of giving people a choice of rendering them
> differently (maybe with red letters) if they so choose.
> 
> For issue (1), I don't want to be forced to use XML markup to generate
> punctuation, especially underspecified XML markup like you propose.
> Punctuation is part of a language, just like the letters, syllabary,
> or pictograms. Why not just represent it in Unicode? Keep it simple,
> sir. The advantages of doing so far outweigh the advantages of
> converting to and from XML markup.
> 
> For issue (2), all I want to do is make it easy to give an option to
> people to render Jesus' direct quotes in some other way or not,
> WITHOUT CONFUSING THIS ISSUE WITH PUNCTUATION GENERATION AS PART OF
> THE RENDITION PROCESS.
> 
> >For other cases where the quote marks were left off for other reasons
> >then I would use n="".
> 
> I intend to use n="" for every use of <q ...> or <speech ...>, except
> one, because I intend to treat all punctuation as part of the text,
> not the markup. The only case where I would use <q> or <speech> as you
> envision using it would be the case where someone is drafting a new
> translation, and they want to use an automated process to generate the
> punctuation. HOWEVER, once that punctuation is generated and the
> translation is finalized, then all of the markup should be converted
> to proper punctuation within the text itself and replacing the n
> parameter in q or speech with "". That way, the text and style
> rendering information can be kept separate.
> 
> 
> Rev. Michael Paul Johnson
> Servant of Jesus Christ
> http://eBible.org/mpj/
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: http://eBible.org/mpj/gpg.htm
> 
> iD8DBQFAWjv0RI/gxxfXR7sRAmRcAKCDlWmIoXRYZYXyplHXMhaa6Xpn1QCgjThC
> 9xk8n/WiENEIeoG0PJMmHAI=
> =pLDO
> -----END PGP SIGNATURE-----