[osis-core] Reference Syntax Proposal - Suggestion

[Todd Tillinghast]

> Dear friends,
> 
> Now that we are ready to start marking up larger chunks of text, I
would
> like to ask some questions and make a couple of observations re. the
> Matthew 13 sample text. Please forgive my ignorance...
> 
> While verses are elements that can be segmented, chapters are marked
up
> as attributes of <div> elements. In the earlier (pre-Rome) approach
both
> of them were treated in the same way (as milestones). I take it that
the
> new system allows us to have divs that cross chapter boundaries.

My view was that a chapter usually IS a <div> rather than an attribute
of a <div> in the same way that a verse IS a <verse> and that <div>
carries an osisID so that it can self identify things like chapters and
books.  This does not assume that every chapter must be a <div> or that
every <div> must carry an osisID.

Naturally we will see <div> elements that contain several chapters as in
the Ps for the major groupings of chapters.  It is possible (although I
can't point to a specific case) to have a div that starts in one chapter
and ends in another.  If the encoder wants to ALWAYS have a <div>
element that precisely contains EVERY chapter AND there are cases where
other <div> elements start within a chapter and end in another chapter
then one of the <div> elements will have to segmented.  When rendering
the process will have to account for such cases.

> 
> In the parallel references following the section heading "The Purpose
of
> the Parables" the reference to Luke 8.9-10 is split into two. You did
> not do this for the Mark 4.10-12 parallel, why?
> 

I created my version from the XSEM encoding of the TEV.  In that
encoding Luke.8.9-Luke.8.10 was split into two separate references.  I
will have to look at the printed version to see if the original text
presents these as three separate references or just two.  Good Eye!

> How do we handle discourse that goes beyond section and chapter
> boundaries. Shoudn't there be a <div> that encompasses vs 11-23? Right
> now our div structure only partly corresponds with the way TEV
organizes
> the text. However, the TEV translators make it clear that Jesus'
> reported speech continues after the section heading at vs 18 by using
> only opening quotation marks at major breaks (vs 16, 18) and only
> closing the discourse at the end of vs 23. Shouldn't we have a div for
> the entire speech with nested divs and p's?
> 

This is the beauty of segmentation and the problem that drew me to
Matt.13.  The use of the single quote mark is a technique used when
printing.  You will see in the version of Matt.13 that I posted recently
that there are nested quotes and that a SINGLE segmented quote starts in
the middle of a div and continues through two more div elements.  The
matter of placing a single quote at the first of the block of text is a
rendering issue.  When the quote is segmented it is easy to know to only
insert a single quote mark to show that a quote is continuing based on
the fact that the quote element will have a "prev" attribute with a
value assigned.

There is more than one way to encode Matt.13 with respect to
segmentation.  I chose to segment the quotes first and then the verse
letting the <div>, <p>, <lineGroup>, and <line> elements stand.  (I
don't recall having to segment any of them anyway.)  I will likely be
creating Matt.13, Ps.1 and Matt.1 as example text in the next couple of
days.  You will see in the version of Matt.13 that I posted recently
that there are nested quotes and that a single segmented quote does in
fact cover the span 

> Another thing is the embedded quote from vs 14b to 15, marked by TEV
by
> way of single quotation marks following common practice . Right now
this
> is handled as a second blockquote with an embedded linegroup. Is that
> good enough?
> 

Actually the <blockQuote> element has been eliminated and the <q>
element currently serves all quotes.  I have used the type attribute
with a value "blockQuote" to differentiate <q> elements that are block
quotes.  

Again the fact that Matt.13.14b-Matt.13.15 is a quote within a quote
(nested quote) does not present a problem with encoding or rendering.
When rendering, the process adding quotation marks will have to account
for nested quotes.  In this case is more than just the quotation mark
(single vs double) but also the indentation of the text.  In some
versions there are other typographical techniques applied.  The beauty
of encoding only the fact that there is a quote is that the presentation
is left to the imagination and preference of the renderer and all that
is encoded is the raw information of where the quote is, which is the
way it should be.

> Your comments will be appreciated.
> 
> Thanks for all the good work.
> 
> Kees
> 

Does this help clear things up?

Todd