[osis-users] OSIS cross-reference questions

[Markku Pihlaja]

I'm feeling a bit alone here now - quite a few questions still remain
unanswered after several days, and they are rather crucial for me to
continue my work.

To make answering easier, I'll sum up some more: there are now three
fundamental questions that need answers - all other questions are actually
derived from trying to solve them. So if you can't find answers to these
three (marked with Roman numbers I...III), feel free to help with the
previous ones (Arabic numbers 1...7 - or actually 2...6; 1 and 7 are the
same as I and III).

---------------------------

*I.* How do I markup a single but compound cross-reference that refers to
non-adjacent verses or ranges, so that it (structurally) differs from a
(more typical) note containing separate references to the same
verses/ranges?

*II.* How do I markup a reference to a note whose source is more complex
than just one verse or a contiguous range?

*III.* Is it possible to have a reference's osisRef with a sub-identifier
without a corresponding osisID having that (or any) sub-identifier?
*
*
Example:
<verse osisID="*Deut.32.15*" sID="Deut.32.15" />Jeshurun grew fat and
kicked; filled with food, he became heavy and sleek. He abandoned the God
who made him and rejected the Rock his Savior.<verse eID="Deut.32.15" />
...
<reference osisRef="*Deut.32.15!part2*">

---------------------------

And then to the wider variety of derived questions. No need to read further
if you managed to answer all three previous ones :).


I tried running different kinds of osisIDs through a validator integrated
to oXygen. As expected, a hyphen in an osisID wouldn't validate. But the
list of multiple space-separated single IDs does pass the validation.

Well, if we trust in what passes through the validator, I get answers to
many of my own questions (IF we trust the validator, that is):

*2)* Is listing multiple individual osisIDs separated by a space really
allowed in *a)*osisIDs *b)* osisRefs?
a) YES and b) YES, even though after carefully examining the type
declarations for osisRefRegex and osisIDRegex in the osisCore.2.1.1.xsd
file I still haven't found out how the spaces could be valid.

*3)* If the answer to 2a) is yes, what is allowed with a compound ID like
that?
It seems that any valid osisID will do as a component of such a compound
osisID.

Specifically, can I use sub-identifiers?
Thus: YES. But the exclamation mark and sub-identifier will need to be
attached to one of the component IDs, it can't follow a space.

*4)* If the answer to 2b) is yes, what is allowed in that compound ref?
Specifically, are ranges allowed in such compound refs?
Trying with a validator, it seems: YES. For example, this is judged valid:
osisRef="Gen.1.3 Gen.1.5-Gen.1.7 Gen.2.2-Gen.2.5"
even though Durusay's manual says that "a single osisRef cannot identify a
discontiguous range of a work".


This would seem to provide a step closer to being able to refer to notes
with the more complex sources I've been talking about (question II.),
although not quite. [Note that this wouldn't apply to normal compound
references to verses].

This would be valid:
<note type="crossReference" osisID="*Deut.32.15 Deut.32.17!crossReference*">
...
<reference osisRef="*Deut.32.15 Deut.32.17!crossReference*">Deut.
32.15,17</reference>

although !crossReference being attached only to verse 17 gives a slightly
false impression. Moreover, this would not be valid:
<note type="crossReference" osisID="*Deut.32.15
Deut.32.17-Deut.32.22!crossReference*">
because of the hyphen in an osisID.


My next idea would be rather unorthodox, and I hope you consider twice
before answering "no, of course that can't be done". I would love to solve
this problem in a beautiful, "standard OSIS" way. But since nobody has
given me a sufficient answer to how to do it, it seems I need to get
creative, with the cost of some "standard" conventions.

The osisRefRegex and osisIDRegex type declarations (and thus also
validators) allow some slightly peculiar formats, including "1.Gen.2",
"1.2.Gen", "1_.2", "1._.2" and even "_". Of course there is usually no
reason to use these forms.

*7)* Would something like this be acceptable?
<note type="crossReference" osisID="*Deut.32.15.Deut.32.17!crossReference*">
...
<reference osisRef="*Deut.32.15.Deut.32.17!crossReference*">Deut.
32.15,17</reference>
or
<note type="crossReference" osisID="*
Deut.32.15.Deut.32.17.Deut.32.22_Deut.32.26!crossReference*">

Funny as they look, they really are valid OSIS. So: what reasons are there
NOT to use them? I would of course document this convention carefully. I
emphasize the fact that I do need a way to refer to *notes* in addition to
verses and ranges.

Well, hopefully some of this is answerable.

Thanks again in advance, and sorry for bothering you with such long
messages.

Markku










21. Nov 2012 Markku Pihlaja:

Thanks for the reply,
>
> 2012/11/21 <davidtroidl at aol.com>
>
>
>> Deut. 32:15,17,22–26 could be marked up
>> <reference osisRef="Deut.32.15">Deut. 32:15</reference>, <reference
>> osisRef="Deut.32.17">17</reference>, <reference
>> osisRef="Deut.32.22-Deut.32.26">22-26</reference>
>>
>
> I've tried explaining this earlier: that just isn't enough for us here.
>
> There would be no structural difference between a note containing that one
> compound reference that consists of three verses (or ranges), and a note
> containing a list of three separate references. The only difference might
> be in the separator tokens, but those are outside the markup and shouldn't
> count.
>
> I'll make the problem even clearer: how do you markup this list of four
> different references (I'll mark each with a different color)?
>
> Deut. 32:15; Deut. 32.17; Deut. 22-26; Deut. 32:15,17,22–26
>
> This one is of course a rather imaginary and unreal example - there would
> probably never be a list where the three verses/ranges are first individual
> references and then form a compound one - but using the same verses here
> shows the problem more clearly.
>
> The note marker appearing in the text for this whole list of four
> references should be one single note, not four, so (as stated previously in
> this discussion by DM) all these should be packaged within just one pair of
> <note> tags.
>
> What you're suggesting would be a list of six separate references, the
> three last ones just being separated with commas instead of semicolons, and
> the "Deut." being omitted from the content part of the last two - but those
> separators and the missing book names are content instead of structure
> markup. Structurally that would be the identical three references listed
> twice.
>
>
> osisID's are meant to be unique identifiers for book, chapter and verse
>> elements in a bible.  They should not be used in notes, and they should
>> not contain multiple references
>
>
> I don't quite agree, at least on not being for use in notes, and nor does
> Durusau's manual. For instance lines 2, 5, 8 and 11 in the example on page
> 45 show notes with osisID's. Also, osisID is listed as one of the
> attributes of the note element (as well as basically any other element,
> too).
>
> Isn't the main purpose of an ID to be used for referring to the element it
> represents, regardless of the element's type? And I do need to be able to
> refer to notes here, so the obvious (and maybe even only?) way would be
> using the osisID. I just need to find a good way of naming notes with a
> source more complex than just one verse, and referring to them.
>
> --------------
>
> About osisIDs not being able to contain multiple references: about this,
> too, the Durusau manual disagrees. On page 89 there's the example
> <p osisID="Matt.1.1 Matt.1.2 Matt.1.3">...</p>,
> although I did wonder about the correctness of this in my previous
> message, since I couldn't find such syntax in the OSIS schema.
>
> But if osisIDs really are only able to refer to one verse, then I hope
> someone can suggest an alternative method for what I need to do.
>
>  Markku
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/osis-users/attachments/20121122/1023b376/attachment-0001.html>