[osis-core] Reference Syntax Proposal

[Todd Tillinghast]

> > But I am not sure what purpose the extension is trying to serve.
Can
> > someone enlighten me regarding what benefit there is by allowing the
> > extension behavior.  All I see are multiple step searches and no
clear
> > benefit.
> >
> > Do we only allow extension to standard references that have the
MAXIMUM
> > number of number of identifiers defined by the reference system? Can
I
> > say Matt.1.myOwnSubdivision and Matt.1.44 to both mean subdivisions
of
> > Matt.1 of my own design?  Also potentially problematic is the
"Hebrew"
> > reference system Patrick has reference to in the past, which seems
to
> > have an "a" and "b" part for the verses in the Psalms, but not in
the
> > rest of the Bible.  In this case we would have to intuitively know
that
> > "Ps.1.1.a" is a standard identifier and not an extension.  We could
> > however extend it with "Ps.1.1.a.a" and "Ps.1.1.a.b" AND could
> > ambiguously extend "Ps.1.1" with "Ps.1.1.a"!
> 
> Todd,
> 
> The proposal is a means of identifying segments of a split container.
> If Matt.1.1 has to be split, using Matt.1.1.myId1 and Matt.1.1.myId2
> allows us to find the pieces using a relatively straightforward
algorithm.
> 
> You are right that we wouldn't know just from looking whether
> Matt.1.1.myId1 is in the reference system or is an extension. Can you
> think of situations where that would be a problem?
> 
> -Harry

Harry,

I think we may be trying to have osisIDs server two purposes.  
1) To help identify the segments of a split container.  Within this case
I think there are two sub-cases.
	1.a) An element is split because XML forces there to be a single
tree and the split element overlapped with another element that is given
precedence.  In this case the segmentation strategy with the prev/next
attributes will continue to serve us well.  The issue is that we used
osisIDs in the case where a <verse> element was split.  If we get away
from using the osisID as the key for the prev/next and use another
attribute like "splitID" coupled with the "prev" and "next" attributes
we will have removed a part of the burden on the osisID as well as
creating a consistent pattern for segmentation that can be used for all
segmented elements (including those that don't have osisIDs).

	1.b) The text that belongs to a single identifier within the
reference system is encoded in more than one XML element (more than one
<verse> element).  In this case I don't think that there is a split
container.  If we want to view the reference system as a hierarchical
set of "logical" and virtual containers then there is a split container.
Is this the case that is driving the addition of the reference
extensions?

2) To self-identify an element using identifier(s) from a standard
reference system.  The identifier(s) allow for finding an element.  

Does this accurately describe what we are trying to do with osisIDs?

Todd