[osis-core] Free-range grain-fed sacred cows

[Todd Tillinghast]

> > So my proposal for this would be to disallow grains on self-ids, and
> > to either suggest or (preferably?) require appending a, b,... to the
> > identifiers if you want to make the parts accessible (those should
be
> > declared in a reference scheme, but I'm not picky about that part,
> > seems like a  nit at this point). This gives us nice predictable
> > names for the parts of a discontiguous verse (say, for use in the
> > next/prev values), and makes a trivial algorithm to  strip them off.
> > Indeed, we could use the default fallback algorithm, which is to
> > strip off trailing tokens of a reference; to do that we just put '.'
> > before the 'a'.
> >
> > S
> 
> If I want to use larger verse-like chunks, e.g.
> 
> <p osisID="CEV:Matt.1.1_9">
> 
> would it be non-intuitive to use CEV:Matt.1.1_9a, CEV:Matt.1.1_9b,
> etc to refer to parts?
> 
> Or, worse, what happens if I add <q> or other tags that spans a verse
> boundary and causes another split in the verse container.  Now the
part
> of the verse that used to be Matt.1.1b becomes Matt.1.1b and
Matt.1.1c,
> and all the subsequent sections of Matt.1.1 are renamed, c->d, d->e,
etc.

I am in agreement with this idea assuming that an osisID is a list of
all applicable identifiers from the "standard" reference system.  If
more than one verse element contains text identified by a single
identifier from the reference system that is fine.  If a verse element
is more than one verse identifier let it be identified by all that
apply.

> 
> How about just using osisID of Matt.1.1 for all segments of the verse?
> This would require that all segments be in order, but you can retrieve
> all pieces by asking for all elements with osisID="Matt.1.1". You'd
have
> to use grains to access other parts of the verse. But, of course,
you'd
> be free to define a reference system that uses Matt.1.1.a, Matt.1.1.b,
> etc.
> in addition to Matt.1.1 .

I am not sure the order assumption/requirement is a good on.  There will
be cases where the pieces of a logical verse (as defined by the
reference system) will be reordered to make the text "flow" better.  In
fact there are several cases that the reason that the logical verse is
split into more than one element is so that the text can flow contrary
to the logical verse order.  If a verse element is segmented the same
prev/next strategy would continue to be used and I would think that any
of the fragments of the split verse element would ALL carry the same
osisID.  

For the case where identifiers belong to more than one verse element
(not the case where the verse element is segmented) then the document
order would be the assumed order of the text.  If however, the reference
system commands its own order then the document user is free to use that
scheme as they see appropriate. 
> 
> (I assume that we are allowing tree-structured hierarchy in the
osisIDs,
> Matt containing Matt.1, Matt.2, Matt.3, ...; Matt.1 containing
Matt.1.1,
> etc.)
> 

This is my view.  The danger would be if an encoder used the "verse"
level osisIDs for a <div> element that contains <verse> elements that
also identify themselves with the same ids.

<div osisID="Matt">
	<div osisID="Matt.1 Matt.2 Matt.3">
		<div osisID="Matt.1">
			<div osisID="Matt.1.1 Matt.1.2 Matt.1.3 Matt.1.4
...... Matt.1.29 Matt.1.30">
				<verse osisID="Matt.1.1">...</verse>
				<verse osisID="Matt.1.2">...</verse>
				<verse osisID="Matt.1.3">...</verse>
				<verse osisID="Matt.1.4
Matt1.5">...</verse>					<verse
osisID="Matt.1.5 Matt.1.6">...</verse>
				<verse osisID="Matt.1.7">...</verse>
</div>
		</div>
		<div osisID="Matt.2">
		</div>	
		<div osisID="Matt.3">
		</div>
	</div>
</div>

> -Harry
>