[osis-core] Reference Syntax Proposal

[Patrick Durusau]

Greetings!

As promised, the long awaited proposal on reference syntax! Thanks for 
all the posts and discussions while I was wandering Europe without good 
Internet access. Never again! Mainline hotels and/or written 
representations of high-speed Internet access for my next trip!

1. osisIDs: Serve as identifiers for the element on which they occur.

Consequence, no range or range like behavior.

Can be entered as a list of osisIDs in the osisID attribute value to 
accomodate elements that have verses collected into some container other 
than then standard book, chapter, cf. Todd's Matthew 1:2-6a would be 
encoded:

<p osisID="Matt.1.1, Matt.1.2, Matt.1.3, Matt.1.4, Matt.1.5, Matt.1.6a">

Note that the Matt.1.6a is allowed because a search for Matt.1.6 should 
return that element as well as the one following, in order to get all of 
what is considered to be Matthew 1:6 (may have reordering in some 
languages, etc.)

This is based on the defined behavior for processing being:

A. Match on exact string match: Ex. Matt.1.6 matches Matt.1.6. If that 
fails,

B. Match on Matt.1.6.*. If that fails,

C. Match on Matt.1.6.*.*. If that fails,

This allows the match to descend as it were the possible divisions of 
the reference without prior knowledge of the divisions. (Quite elegant 
and obviously Steve's idea.)

(Harry, I think the Matt.1.1_9 is interesting but dangerous from the 
standpoint of data entry error (shift-hyphen), since we will probably 
have to allow hyphens in osisIDs for some reference systems. So you have 
a syntactically valid ID that is invalid for a particular type of work 
(Bible) but valid for osisRefs.)

2. osisRefs: Have range and grain as previously outlined. Noted in prose 
that osisRefs cannot point to the element on which they appear, i.e.,

 <p osisID="Matt.1.1, Matt.1.2, Matt.1.3, Matt.1.4, Matt.1.5, Matt.1.6a" 
osisRef="Matt.1.1-Matt.1.6"> is VERBOTEN!

Noting that the enumeration of osisIDs will only occur where there are 
divisions that do not include verse divisions. In other words, any 
container could simply omit the osisID, if desired, where lower level 
containers have osisIDs. It is only the partial case that requires 
enumeration or where lower level containers don't carry osisIDs. I could 
have startMilestone/endMilestone pairs, segs, verses, etc., that have 
proper osisIDs that resolve as detailed above.

3. Steve has suggested that we add startMilestone and endMilestone 
elements in addition to the generic milestone (which should then be used 
for point (or shadow) references. Having separate elements will allow 
enforcement of a endMilestone attribute only on startMilestone elements 
(in the sense of an IDREF) and a startMilestone attribute (also in the 
sense of IDREF) only on the endMilestone element.

4. Note that the startMileston/endMilestone with a type attribute should 
solve the quotation problem that Troy has raised.

5. In the listing of osisIDs, can prepend work if you want to have a 
mapping for some purpose between reference systems. This should be 
discouraged in favor of actual mapping tables but allowed as a practical 
matter.

6. Note that the defined processing behavior for osisIDs I think gets 
the point of Harry's most recent posts. Would need to document that 
splitting an osisID means that you have to split all occurrences of it, 
sorta makes sense if it is a self-identification within a system that 
either all are split or none?

I am going to hammer out some more formal syntax and probably just post 
it outside the schema tomorrow. Should have the schema posted to the 
group, with docs by late Friday (after I arrive in Montreal, need to 
finish getting some stuff installed on the Linux side of my laptop).

Hopefully we are close enough that we can see some tests of this be 
early next week? (I am opting for the high-speed access option on the 
room in Montreal so when I am not actually in ISO, OASIS TC meetings or 
at the conference I will be online. Well, am taking one evening to go 
hear an organ recital with Jim Mason but that should be the only break 
in the week.)

7.  I have not looked back at the refsDecl discussion yet, Harry, any 
significant problems on declaring a local name for a resource that 
become the work part of the attribute?

I think this is an accurate summary of my conversation with Steve and a 
culling from all your posts but if not, it is error on my part and 
should be corrected.

Other outstanding things I can clean up in the next release?

Guys you are the finest!

Patrick



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