[osis-core] Wrapping up?

[Todd Tillinghast]

I think we have nearly reached consensus on the open issues of the last
two weeks.

Here is a summary.

1) osisID is for self identifying and is never a range.
2) osisID is always an identifier that fully describes the fully body of
text it contains.  
3) higher level "containers" like <div>, <p>, <lineGroup>, <list>, etc..
will have an optional identifying attribute that deferrers from an
osisID in that it MAY be a range.  These containers will also have an
optional osisID attribute for the cases where they purely contain larger
grain reference like a book or a chapter.
4) osisID is mandatory on <verse> elements.
5) all other references will use the <reference> element with an
appropriate type or type/subtype value.
6) references, osisID, and container ids (see #3 above) all take the
same from including the option of a grain with the exception that an
osisID may not have a range.
7) either a reference system or a reference system/work pair must be
specified in references, osisIDs, and container ids.  The absence of any
specification implies the default.
8) a default reference system or reference system/work pair must be
specified in the header.
9) osisIDs may be from more than one reference system.
10) the form of a reference and a container id is as follows
[referenceSystem[(work}]:]simpleReference[@grainType.grain][-
simpleReference[@grainType.grain]]
examples:
Bible.KJV(Bible.TEV):Gen.1.1@char.44-Gen.33.3@char.55
Bible.KJV(Bible.NASB):Gen.1.1@char.44
Bible.KJV(Bible.TEV):Gen.1.1@char.44-Gen.33.3@char.55
Bible.KJV:Gen.1.1-Gen.33.3
Bible.NRSV:Gen.1.1
Bible.TEV(Bible.TEV):Gen.1.1
Bible.Todd(Bible.TEV):Gen.331.a
Bible.KJV:Gen.1.1
Gen.1.1

Bible.KJV:Gen.1.1@char.44 (This should not really be allowed because the
grain is meaningless outside of the context of a specific work.  But I
would propose that we ignore that detail in validating the form for
now.)

11) the form for an osisID would be as follows
[referenceSystem[(work}]:]simpleReference[@grainType.grain]
12) prev and next attributes of <verse> take the same form as the osisID
13) an osisID must ALWAYS be unique and may never be a range.  If there
is a many to many, one to many, or many to one relationship between a
verse element in a document and the verse identifiers defined for the
"preferred" "common" reference system then the document MUST use a
reference system that has a one to one match between identifiers and
verse elements. 

Note: The two options proposed previously:
   13.a) The use of a list element of osisID singular ids for the osisID
attribute.
   13.b) The using the first "common" reference system id as the osisID
when there are many "common" reference system verses in a single verse
element and then put child elements that carry osisIDs for the reference
ids from the "common" reference system that were left out.
do only work when there is a one to many relationship between the verse
in current document and verses identifiers in the "common" reference
system.  The many to many and many to one cases would not have unique
osisIDs.

14) as demonstrated by the osisID form an osisID may have a grain.  This
will allow for unique osisIDs for segmented verse elements.  (The first
verse element of a segmented verse is expected to not have a grain to
facilitate finding the "logical" verse by its non-grain adorned osisID.)


Problems, suggestions, agreement?


Issues:
A) Which elements can be segmented?
B) What form does a reference to an entire work take?  If we keep the
same form we could reserve a the character "*" to mean the entire work.
("Bible.KJV(Bible.TEV):*" for example).  We must continue to have the
":" character present to differentiate between a reference within the
default reference system and an entire work.  I still think that it
makes sense to have reference to an entire reference system BUT only the
work is needed (and not the reference system) when referring to an
entire work.  It seems that the current reference strategy works when
trying to express the entire set of references in a work or reference
system but not to reference a work itself.  I don't really like the idea
of two optional attributes in <reference> and making the single required
attribute to do double duty does not work.  It seems that we may need an
additional element for referring to entire works.  Ideas?
C) Should we allow the defaulting of the reference system for references
that are not for self-identification?

Todd