[osis-core] osisCore_Candidate.1.1_006 - 9 - consitency and readibility or "text" related elements grouped into an elementGroup

Todd Tillinghast osis-core@bibletechnologieswg.org
Fri, 30 Aug 2002 13:05:26 -0600


In studying the elements that can be children of other elements two
things have emereged.

1) We are inconsistent in which elements we allow for encoding text.
Some of this may be intentional and some is likely a function of the
evolution of the schema.  

2) If all of the elements that are always present when there is "text"
were put into an elementGroup then it would be clear that those elements
are present children simply because the element contains text.  The
result would be that the other child elements would stand and that the
set of "text" related elements would be consistent.  Further you would
only get the eternally expanding child tree through this elementGroup
and the "intended" use of the schema would be more clear.


(To the person uninitiated to how this schema is intended to be used it
looks pretty loose. For example:
osisText->div->note->p->verse->q->list->verse is possible and would
remain so, only the elementGroup would give guidance regarding the
intended purpose of the elements in it.)

It seems the following elements can go in an element group:

Elements:
a
abbr
date
divineName
hi
index
foreign
inscription
milestone
milestone_start
milestone_end
name
reference
q
salute
seg
signed
speaker
table
transchange
w

Are there any of these elements that should NOT be whereever "text" is?
Are there any elements that should be wherever "text" is that is not in
this list?


The elements that currently contain "text" are:
actor
role
roleDesc
a
abbr
caption
catchWord
cell
closer
div
divineName
foreign
head
hi
inscription
item
label
l
mentioned
name
note
p
q
rdg
reference
salute
seg
signed
speech
title
transChange
verse

Not all of these elements currently contain all of the elements in the
first list.  Notable exceptions are milestones.

Patrick, if a single group does not seem to work for you then we could
easily create three groups that would exactly map to the current schema
setting aside what seems to be unintended inconsistencies.


Todd