[osis-core] SplitID

[Todd Tillinghast]

> 
> Todd,
> 
> Sorry for the delayed response! Trying to catch up on other work that
> lagged for the candidate release. New version with regex fixes to
appear
> by Sunday NOON.
> 
> Todd Tillinghast wrote:
> 
> >
> > We can not use the split id as suggested by the example Patrick
gave.
> > This does not however imply that we need to change the structure.
> >
> > The basic problem with the example
> >
> > <verse osisID="Matt.1.1" splitID="1"></verse>
> > <verse osisID="Matt.1.1" splitID="2"></verse>
> >
> > is that it depends on the osisID which may not always be available.
> >
> >
> >
> > First there seem to be two kinds of splits being covered.
> >
> >
> >
> >
> > ONE: Split verse identifier but not XML element splitting.
> > <verse osisID="[[Matt.1.2] [Matt.1.3] [Matt.1.4] [Matt.1.5]
> > [Matt.1.6]">...</verse>
> > <verse osisID="[Matt.1.6] [Matt.1.7] [Matt.1.8] [Matt.1.9]
[Matt.1.10]
> > [Matt.1.11]">...</verse>
> >
> 

I think we are in agreement on this other than you suggestion that
<verse> should only have a single identifier.

> 

> Not sure what case you are describing here. A verse, as I understand
the
> element, would never have more than one osisID. A <p> element could,
is
> that what you are describing?

Although the number of cases where a <verse> element would have more
than one identifier in an osisID would be less frequent than <p>, there
is a different meaning to <p> than there is to <verse>.  If you in the
middle of a <p> and there are several verse elements and one of the
verse elements represents a block of text identified by more than one
identifier then we should not be forced to insert an artificial <p>
within the real <p>.  As it is <verse> elements don't really serve much
purpose but to contain a verse amount of text.  On the other hand <p>
carries more meaning.  

> 
> Assuming the latter, that is a case where Matt.1.6 is split between
two
> <p> elements (the Matt.1.6a and Matt.1.6b in conventional but not OSIS
> notation, then the osisID (which is not a true XML ID) appears as an
> osisID in both <p> elements. This forces a search for osisID =
Matt.1.6
>    to return both parts, which is the expected behavior.
> 
> Yes, need to document that behavior but that makes sense (I think) to
> have the default return all the relevant portions of a text by osisID
> even if the  particular text has split them differently than you might
> expect. Allows users to have a uniform expectation of how to ask for
> references and returns the material they requested.
> 
Todd