[osis-core] work/works/headers and refSystems

[Patrick Durusau]

Chris,

As promised, early morning musing on work/works/headers and refSystems!

work/works vs. refSystem/refSystems:

I think our reasoning here was that you might want to distinguish 
between a work and a refSystem that was in use in an OSIS document. 
Since the refSystem does not provide for a specification (something 
Harry asked about some time ago) for documenting the reference system, 
it probably does not (upon reflection) deserve a separate element. In 
TEI land, the refsDecl provided a prose, read not machine processable, 
description of the reference system in use.

My thinking at the time was that by dividing work from the reference 
system would give us a place to put such declarations in the future. 
(Can't speak for Steve, comments from Maryland?) Since it does not gain 
us any information and generating the syntax for a machine processable 
refSystem element is something we probably need to add for 2.0, I would 
be willing to collapse work/refSystem, works/refSystems into work/works. 
(Attribute momentary appearance to confusion on the part of one of the 
editors.)

work/works:

Assuming the collapse of work/refSystem, I turn to the question of 
work/works and meta-data in the header.

The problem we were trying to solve was the case where you have a simple 
Bible but want to use osisRef to refer to other materials, which for 
Harry's case, should have the sort of bibliographic information that we 
record in the header. We also need a place to hold the metadata for the 
document itself (the "ding an zich" for you phenomenology folks).

 From the standpoint of a container relationship I think Chris is 
correct that the structure would make more sense if it was:

<header>

contains <works>

<works>

contains <work>

<work>

contains all the other header stuff

That gets you all the identification stuff in a single location (the 
goal of <works>) and allow fairly full bibliographic information 
(requirement of <work>).

By way of explanation, the <works> was optional so that in the simplest 
case, you would not have to declare the collection of <works>. The 
proposed solution would have a content model that requires <works> 
minOccurs="1" maxOccurs="1", and within <works>, <work> would be: 
minOccurs="1" maxOccurs="unbounded". Adds only one element, the 
container <works> and on the whole I think would be less confusing to users.

I can make the foregoing mods later today, assuming no one sees any 
serious problems with them. The remote schema validation service said my 
schema was valid last time with the bad regex so I will try to get to 
installing a validation service on the Linux box. If I don't get to it, 
I may have to send the schema to Todd to validate before posting. (When 
I get the laptop back and have both OSs running, the Linux side is clean 
and I will be setting it up entirely for XML work so that will be easier 
than my general production box that has has various JDK's, etc. and 
cleaning it up would be a major undertaking.)

Hope you are enjoying your studies at SIL!

Patrick
 

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