[osis-core] Thoughts and Questions on compare file

[Patrick Durusau]

Jim,

Some thoughts and questions on the latest compare file.

At first blush I did not see anything that we can't handle in OSIS now 
or with minor modification.

Decided to copy the osis-core list so we can get comments from others as 
well.

Will be checking today on actually producing a more restricted schema, 
that is one that takes out the x- capability and leaves only enumerated 
values. I take it you are aware that your software interface does not 
have to display the possibility of an x- value for attributes? That is 
to say you could only display enumerated values and not leave the user 
any mechanism for departing from the list?

Side note to osis-core on the restricted schema: What I am envisioning 
is a very small schema that imports osis-core and redefines/restricts 
attribute values to the enumerated lists. Since such an instance would 
be a conforming OSIS document (the greater always includes the lesser) I 
don't see any compatibility problems.


Specific comments follow:

Alluded_Text: Posting a note today to add this as enumerated value on seg.

Attribution: Should this be on lg or l? Thinking that it is more likely 
on l as part of a lg. On the other hand, don't you have the same case 
where you would not be using lg or l?

Book_ID: I am not sure what you are asking for here? Isn't this already 
contained in the osisID?

Chapter_Head, Chapter_Label, Chapter_Number: Aren't these variants of 
title? That is to say that a chapter has a title and these are 
'additional' titles of some particular type?

My first reaction is to have:

Chapter_Head = title type="main"

Chapter_Label = title type="sub"

Chapter_Number = title type="sub"

Granted that osisTitles (for type on title) only enumerates

<xs:enumeration value="acrostic"/>
<xs:enumeration value="continued"/>
<xs:enumeration value="main"/>
<xs:enumeration value="parallel"/>
<xs:enumeration value="psalm"/>
<xs:enumeration value="sub"/>

Citation_Line1 (etc): Question, you list lg but I assume l?

BTW, we have otPassage on seg. So, would <l><seg>...</seg></l>, meet the 
need here?

Err, actually just looked at the John the Baptist example and so you 
would want something like otPassage on lg. Hmmm, then you could do the 
line1, line2, etc. with XSLT. Actually would reduce the amount of markup 
you would need since if I am in a lg type=otPassage, then lines 1, 2, 
etc. fall out from the structure. I think that works for me if it works 
for you.

Citation_Paragraph: Looks like a block quote that contains a paragraph, 
which as you know can contain a reference element. I think this is what 
we used to call <cit> in TEI, which had a <q> followed by a <ref> (don't 
hold me to the names) element.

Not sure what would be different about using a block quote that contains 
a reference element.

Citation_Reference: Why isn't this simply a reference with a type? That 
is to say all references are citation_references in some sense of the 
term. Since we have an element for marking all references, why not use 
that and add a type if necessary?

Closing: What is the problem with closer here?

Congregational_Response: I will post this to the list. Suggestion for 
attribute value? response? congregation? on lg.

Copyright_Statement: Covered under rights in the header. This is the 
standard location in Dublin Core. Don't think we gain anything by adding 
another potential location for the information.

Unless you mean to say that the copyright page as an artifact needs to 
be encoded. I suspect we could add a type to div but to be honest, I 
don't see the point. Just make it a div and if you need copyright 
information, get it from the header.

Credits: Same here, I could counsel just paragraphs with the usual 
sub-elements. Don't gain anything if you have properly prepared the 
header which has the very long enumeration of roles for credit, etc. I 
guess in part I don't see any reason to priviledge a poor retelling of 
information already presented in a useful fashion in the header.

Not saying people should not enter it, but it is just an artifact of 
printing and not something you will need to identify later for 
processing. For those purposes, use the header information.

Doxology: Let me check on that one. I know we have discussed, probably 
should be added.

Embedded_text (all entries): We have discussed, posting to list for 
adding type to q.

Emphasis: ??? Sorry, why isn't this covered by hi?

Gloss: Hmmm, would require annotateRef so you could like to the word or 
phrase being glossed. Suggest same places and content model as hi?

Hand: Perhaps it is just confusion with the use of 'hand' to mean in 
transcription circles the scribal hand and not references to hand in the 
text, but I don't see this as a different element. Fair enough that the 
text says: 'in my own hand' but that does not seem to me to be a 
separate element in the structure of the text. We should discuss this 
one. I would suggest hi or seg at first blush.

Inscription_Paragraph: Why doesn't the inscription element work here?

Interlude: Selah is enumerated under osisLine. Suggest same for Interlude?

Intro (all): Suggest introduction type on div?

Line1-*: I assume from your notes you are handling these with XPath 
expressions?

Name_of_God: enumerate types, I assume you don't have any to add to the 
list I posted?

Paragraph_Continuation: As we discussed, this is handled automatically 
in tree representations.

Parallel_Passage_Ref: Yes, handled by reference element

Quoted_Text: Why isn't this handled by q? As opposed to seg type = 
quoted text?

Refrain: add type to lg?

Rights: In terms of accessable information, handled by Dublin Core 
element in header. Is there some reason to duplicate here?

Section_Head_List: Do you mean a list within a list? If so, note that 
list contains list and all lists have head.

See_in_Glossary: ?? The reference element is not empty. Reference is not 
limited to simply being Bible references but can contain a reference to 
another part of the work, such as a glossary, perhaps a map, etc.

So_Called: Actually these are examples of the mentioned element.

BTW, the example in the help file is incorrect. The last occurrence of 
'sinners' is not a mentioned or so_called element. The quoted statement 
of the Pharisee's were *using* the term. The preceeding uses are 
examples of mentioned, that is the apeaker of those occurrences was not 
*using* the term.

Speech_lines (all): I assume you are going to handle these with XPath?

Stanza_Break: add type to lg?

Title_Main and Title_Tertiary: I assume the type on title works for 
main. Since sub titles should be inside of title, is there a need for 
another type here?

Thinking <title type="main"> blah, blah <title type="sub">blah, blah 
<title type="sub">blah, blah</title>(closes tertiary title) </title> 
(closes secondary title) </title> closes main title, and allow you to do 
uniform XPath expressions for all cases.

If you are going to use styles, etc., so no one sees the XML, suggest 
the embedding method for more reliable XPath processing.

Untranslated_Word: ??? Sorry, you have me on that one and I could not 
find an example in the help file. Wouldn't this be foreign?

Variant_Section_Paragraph/Head/Tail: Note sure what is being requested. 
Look at rdg. By definition, rdg is a variant so everything inside is 
about a variant. Perhaps if you could say a bit more about this one.

Verse_Number_Alternate: Hmmm, why not have more than one osisID, with 
the alternative prefixed by a work? Display is of course up to the 
application.

Words_of_Christ: I take it that the who attribute works for you?

Hope you are having a great day!

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau at sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!