[osis-core] one more past unrsolved issue - deriving the presentation value from a complex osisID

[Todd Tillinghast]

Patrick,

Sounds like a good solution.  Can you remind me of the general
meaning/purpose of the "n" attribute?  Is it "name"?

I strongly agree that markup is supposed to encode the structure of a
text and not its presentation.  The problem is there is a fine line in
some cases between "data" that IS the text and "data" that is
presentation related. 

Todd

> -----Original Message-----
> From: owner-osis-core@bibletechnologieswg.org [mailto:owner-osis-
> core@bibletechnologieswg.org] On Behalf Of Patrick Durusau
> Sent: Thursday, October 31, 2002 3:33 AM
> To: osis-core@bibletechnologieswg.org
> Subject: Re: [osis-core] one more past unrsolved issue - deriving the
> presentation value from a complex osisID
> 
> Todd,
> 
> I will hopefully reach all the outstanding issues that are pending on
> the list and have some suggested "bug" fixes by early next week.
> 
> Note that we keep coming back to presentation issues that are being
> confused with markup. Markup is supposed to encode the structure of a
> text, not its presentation. If we wanted presentation, we could have
> used TeX and while the text would not be easily searchable or useful
> with widely available software, there would be minute control over
> presentation.
> 
> Consider the TEV problem:
> 
> There is nothing in the current schema that prevents:
> 
> <p n="Matt.1.2-6a" osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5
Matt.1.6
> Matt.1.6a">
> 
> Such that your stylesheet checks for "n=" before using osisID as a
> display value. This allows the generic use of osisID in cases where
> there is only one identifier and we only have to write the stylesheet
> routine once.
> 
> If you want to have anchors in the text (not displayed to users or
> displayed if you like), use generic milestones to mark the beginning
of
> "verses" in the paragraph to allow users to jump to what would be a
> verse in a regular translation. That would mean that they could either
> go to the paragraph or the "verse" so you would need to give them a
> choice if you are building search software.
> 
> I realize there are typos and some actual problems in the current
schema
> but it was not meant to conform to either how texts are currently held
> or how they may need to be displayed. I really do think we can solve
the
> display problems I have seen thus far, although some will be more
> difficult than others.
> 
> Patrick
> 
> Todd Tillinghast wrote:
> 
> >PROBLEM: It is difficult and in some cases impossible to derive the
> >verse identifiers that match those in current printed editions from
an
> >OSIS encoded document.
> >
> >Examples:
> >The TEV renders the following paragraph with "2-6a" as the verse
> >identifier.
> >Here are some options for how it could be encoded:
> ><p osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5 Matt.1.6 Matt.1.6a">
> ><p osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5 Matt.1.6 Matt.1.6.a">
> ><p osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5 Matt.1.6a">
> ><p osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5 Matt.1.6a">
> ><p osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5 Matt.1.6a kjv:Matt.1.2
> >kjv:Matt.1.3 kjv:Matt.1.4 kjv:Matt.1.5 kjv:1.6">
> ><p osisID="kjv:Matt.1.2 kjv:Matt.1.3 kjv:Matt.1.4 Matt.1.2 Matt.1.3
> >Matt.1.4 Matt.1.5 Matt.1.6a kjv:Matt.1.5 kjv:1.6">
> ><p osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5 Matt.1.6">
> ><p osisID="Matt.1.6 Matt.1.5 Matt.1.4 Matt.1.3 Matt.1.2 Matt.1.6a">
> ><p osisID="Matt.1.2 Matt.1.4 Matt.1.3 Matt.1.5 Matt.1.6a">
> ><p osisID="Matt.1.2 Matt.1.4 Matt.1.3 Matt.1.5 Matt.1.6a">
> >
> >In some cases it is possible to create an algorithm that would derive
> >the desired text, but in others the translators may have been
> >inconsistent.  In any case such an algorithm is complicated in XSL.
> >
> >SOLUTION OPTION 1: Put the display value in as one of the osisID
values.
> >4a <p osisID="Display.2-6a Matt.1.2 Matt.1.4 Matt.1.3 Matt.1.5
> >Matt.1.6a">  OR
> >4b <p osisID="Matt.1.2-6a.display Matt.1.2 Matt.1.4 Matt.1.3 Matt.1.5
> >Matt.1.6a">
> >OR
> >4c <p osisID="Matt.1.2-6a Matt.1.2 Matt.1.4 Matt.1.3 Matt.1.5
> >Matt.1.6a"> where the convention is that the FIRST value when there
is a
> >list of osisIDs is used for display.
> >  This creates a strange value in the "namespace" but makes it easy
to
> >render and would be HARMLESS otherwise.  The rendering system can
either
> >employ a fancy algorithm to derive "2-6a" and/or use the value
following
> >the "Display." OR with a trailing ".display" when such a value is
> >present (Options 4a and 4b).  This does not add a questionable
> >attribute, does not "misuse" <seg>, does not bend the meaning of
> >milestone, and still provides a mechanism to solve the problem.
> >
> >SOLUTION OPTION 2: Without changing the schema is the following:
> ><p osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5 Matt.1.6
Matt.1.6a"><seg
> >type="verseIdentifier">2-6a</seg>text of the verses</p>
> >
> >This is a non-standard and would likely result in many users ignoring
> >the type attribute and incorrectly applying the text.
> >
> >SOLUTION OPTION 3:
> ><p><milestoneStart osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5
Matt.1.6
> >Matt.1.6a" textIdentifier="2-6a"/>text of the verses</p>
> >For this special case use a milestone and ADD a "textIdentifier"
value
> >to <milestone>
> >
> >SOLUTION OPTION 4: Allow milestone to be non-empty in the same way
that
> ><reference> is non-empty.  This is a handy solution but is contrary
to
> >the nature of milestones.
> ><p><milestoneStart osisID="Matt.1.2 Matt.1.3 Matt.1.4 Matt.1.5
Matt.1.6
> >Matt.1.6a">2-6a</milestoneStart>text of the verses</p>
> >For this special case use a milestone and ADD a "textIdentifier"
value
> >to <milestone>
> >
> >SOLUTION OPTION 5:
> >Tough this is a rendering issue.  Suck it up and write algorithms to
> >solve this problem.
> >
> >I prefer the 4c, is there a need to change the schema as in options 3
> >and 4?
> >
> >Is there a "best practice" that we can recommend for general use?
> >
> >Todd
> >
> 
> --
> Patrick Durusau
> Director of Research and Development
> Society of Biblical Literature
> pdurusau@emory.edu
> 
>