[osis-core] Reference Syntax Proposal

[Harry Plantinga]

Todd's excellent questions brought to my mind a question of my
own. Or maybe it's just a restatement of a question of Todd's, I'm
not sure.

Suppose that Matt.1, Matt.1.1, and Matt.1.2 are defined in a ref 
system.  Suppose I put all of Matt.1 in a big div, so I can access
the whole chapter at once, but the div has to be split. Perhaps
I'd call the pieces Matt.1.a and Matt.1.b.  Matt.1.a contains 
Matt.1.1 and Matt.1.2.

If I try to get Matt.1 by searching for all elements with osisID 
of Matt.1.*, I'm going to come up with Matt.1.1, Matt.1.2 as well as
Matt.1.a, Matt.1.b.  Matt.1.1 and Matt.1.2 will be in the result
list twice -- in fact, all of Matt.1 may be duplicated in the result
list.

Long and short of it is, you need some way of differentiating
split container ID extensions and osisID levels.

Two possibilities:

a) use different syntax, e.g. Matt.1;a and Matt.1;b

b) use some other attribute, as in Todd's proposal

-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
>