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

[Patrick Durusau]

Todd,

Todd Tillinghast wrote:

>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.  
>
It would be more helpful to know which content models appear to be 
inconsistent (I am printing out yet another copy and will probably try 
to build the chart again in the morning with the current version 007 as 
a final sanity check.).

>
>
>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.
>
Yes, except that the child tree for role for example, is much smaller 
than than of div, for example. If there are common (or what should be 
common sets, like actor, role and roleDesc which share a common model) 
 that are/should be widespread enough to be a single group, that might 
add some clarity.

I think some of the looseness is inherent in the encoding of texts, 
which tend to be fairly loose. The next time we meet, ask about the 
"any" content model for the OED! ;-)

I will print out a copy and pay particular attention to the similar 
content issue. Perhaps some documentation about ususal structures would 
help?

Patrick


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

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu