[osis-core] Latest Draft of Schema

[Patrick Durusau]

Suggestion: with all the changes and modifications, lets limit each post 
  on the latest version to one element or attribute whenever possible. 
That will help me keep track of the discussion and any changes that we 
need to make. I should have most of Thursday afternoon and Friday 
evening (my presentation and following meetings consume most of 
tomorrow, Wednesday for me already).

Guys,

Well, after much delay and not a little hard work, I finally have a 
candidate release for OSIS 1.1!

I have added a lot of notes to the schema to try to make it a little
clearer on the first read.

A couple of major points to note:

Reference Syntax:

The regexes for the reference system are in place but basically 
constrain the syntax of grain and reference but not their content. I 
have spent the better part of a day trying to devise a system that 
allows all the possible alternative reference systems with this syntax 
and came up dry. The problem is that if we require say 
book.chapter.verse for osisref, what do I do with references to Plutarch 
that have only a book and section number? In part it is a problem of 
trying to be a reference syntax and content validation rolled into one.

One possible approach is to allow the schema to handle the syntax of the 
reference validation and have the content validation (data type in 
schema land) handled by a separate process, perhaps even a perl script. 
To some degree schemas can do both syntax and content (read data type) 
validation but only because they are in a universe of a very controlled 
set of data types.

Note that the syntax for the osisRef data type:

(([^\s]*\.)?([^\s]*\.)?([^\s]*\.)?([^\s]*\.)?([^\s]*\.)?([^\s]*)?)

Allows you to have up to six (6) non-whitespace character strings 
separated by the period for a reference.

I used the same syntax for work (osisRef being a data type) so that we 
could validate the syntax of references to a work.

Syntax for osisGrain:

(char:([Nd]*)+([Nd]*)\((^\s)*\) | ((^\s)*)

Follows Steve's suggestion but with the addition of a string as an 
alternative to allow for alternative (XPath?) addressing of grains.

Corpus vs. Text

I have added a higher level container element, osis, which has a choice 
of either being followed by osisCorpus, which contains an unlimited 
number of osisText(s), or simply being followed by osisText.

Let's try to get some texts into this so we can determine if there are
any hidden bugs about to bite us! I would really like to put this to bed
so we can move onto producing texts and getting some work done on the
rest of the materials.

Hope this finds one and all in good health and spirits!

Patrick

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