[osis-core] Wrapping up?

[Troy A. Griffitts]

>>self-identify some of the more contemporary texts that versify by
>>paragraphs. e.g. "This paragraph is Mark 1:1-9"
>>
> 
> 
> In this case the "1-9" becomes a verse name in the current reference
> system in same way that "4" is a verse name in "Gen.1.4".  Other options
> were discussed in recent posts.

This seems useless, unless self referencing in the same document.  If I 
have a Bible such as this installed in some Bible software application, 
and I have a commentary that has a <reference> to Mark.1.7, I would hope 
my Bible would jump to the "This paragraph is Mark 1:1-9" paragraph.  I 
don't think we decided how to do this.

In Dallas, we decided to force these types of Bibles to have multiple 
milestone starts, so we could still, easily do a string-match reference 
resolution system.

e.g.
<verseStart ref="Mark.1.1" />
<verseStart ref="Mark.1.2" />
...


Now that we're using containers, I'm not sure how we've decided to allow 
this.  I still think it's not a trivial jump we're making if we decide 
to allow ranges.  I'm not necessarily against it, but am concerned about 
the complexities introduced.  The multiple milestart start solution was 
brainless and made for easy implementation.  I could write XPath to 
resolve to any versification reference that this Bible claims to 
implement.  In the range solution, this is no longer true.


> The case with Mark and Mark.1 you state is an osisID but there is an
> other case where there are divs smaller that Mark.1.
> (Mark.1.1-Mark.1.12) In this case an osisID can not be used to self
> identify itself.  What I am proposing with the container ID is that when
> a container can not self id with an osisID that a range based self-id be
> provided.  I think that we should retain osisID as a non-range and
> continue to provide it for the cases you state above but allow this
> secondary self-id mechanism.

My thinking on this is that if this new range mechanism is INDEED to be 
treated as an "I am this" self-identification, that could be the target 
of a reference... if indeed we are going to allow this, and force 
support of this in implementations, then there is no difference between 
osisID and this new mechanism.  They are both doing exactly the same 
thing.  There should not be 2 mechanisms to do this exact same thing. 
We should instead just extend osisID.

Unless there is a difference between the 2, other than the granularity 
to which they can point, then the 2 should be consolidated.

This is my thinking.


	Thanks for the discussion,
		-Troy.