[jsword-devel] References containing canonical text

John Austin gpl.programs.info at gmail.com
Tue Dec 1 00:25:27 MST 2015 

Under the <reference> tag section of the OSIS manual is does not mention 
a default value for canonical, but it does say:

"Reference elements will often occur within notes, but may also occur 
freely in text (the latter is more common when encoding non-Biblical 
works)."

So clearly <reference> is sometimes intended to be canonical and 
therefore it definitely should not hard default to canonical=false! It 
must be inherited. And I'm curious where you read that canonical 
attribute is not inherited, because near the end of the "XML and OSIS 
declaration" section, where it talks about the canonical attribute, it says:

"The canonical attribute is available on all elements. The value of this 
attribute is "inherited," that is once it is set, any subelement of that 
element inherits the same setting."

The OSIS manual in many places talks about this inheritance of 
canonical, so if it says somewhere that it is not inheritable then that 
is certainly a mistake.

I only found a clear statement of canonical default values for 
<osisText> (true) and <note> (false) in their respective sections of the 
manual. It does not state it however in the <reference> section. But I 
did read this intriguing (and disturbing) bit following the previous quote:

"In osisText this attribute (canonical) is set to a default value of 
"true", while in header, note, and reference that setting is overridden 
by setting the value of that attribute to be "false."

If this somehow implies that <reference> will be set to canonical=false 
even if the parent is canonical then that would be a major mistake and a 
contradiction in the spec. Although I admit I'm not entirely sure what 
this does mean...

In any event. Like you said, canonical text should never be dropped 
regardless of how the OSIS manual is interpreted, which in some cases 
seems harder than interpreting the book of Revelation :)

-John

On 11/30/2015 09:39 PM, DM Smith wrote:
> Agreed. Canonical text should not be dropped. What does the OSIS manual
> say the default value for the canonical attribute on the reference
> element when it is not specified? The manual states that attribute is
> not inheritable.
>
> I’ll be looking into it to make it work regardless of what the manual
> says. I’ll report back what I needed to do to make it work.
>
> DM
>
>> On Nov 30, 2015, at 2:15 AM, John Austin <gpl.programs.info at gmail.com
>> <mailto:gpl.programs.info at gmail.com>> wrote:
>>
>> Martin is right that the real problem is canonical text is
>> inadvertently being dropped. This should not be allowed. The various
>> filters should pass all text nodes unless the text node is part of a
>> non-canonical ancestor targeted by the filter (such as a footnote, a
>> secondary reading, etc).
>>
>> It sounds like in JSword the issue is an unhandled exception, and if
>> so, the needed solution is of course an exception handler that passes
>> text nodes rather than dropping if an unknown or unhandled tag or
>> attribute is encountered. Text nodes are canonical unless they reside
>> in an ancestor element which is specifically not canonical.
>>
>> The secondary solution is to handle particular tags (in this case
>> <reference>) but this is optional according to the front end. In the
>> case of these <reference> tags, they are canonical text nodes which
>> are referenced by translators to one or more accompanying localized
>> glossary or dictionary modules. Most of the time, there is only one
>> reference, but sometimes there are more than one (if there are
>> separate OT and NT glossaries, or the Bible was originally published
>> in separate parts such as Gospels and Pentateuch, each having their
>> own glossary/dictionary/concordance etc). So if a front-end can only
>> handle one target reference, then handling the first one is a good
>> solution. But if a front end can handle multiple targets, then each
>> can be presented, as the designer wishes.
>>
>> -John
>>
>> On 11/28/2015 11:08 PM, Martin Denham wrote:
>>> The main issue is not related to the osisRef attribute but to the
>>> content of the reference tag - 'muqaddas' - being excluded by
>>> getCanonicalText() and AB code.  The problem here is quite significant
>>> because it would appear to users as though some words had been removed
>>> from the Bible.  I wanted to check that by including reference tag
>>> content I should not be breaking anything else.  In the normal AB Bible
>>> view the ref tag content is properly displayed but in certain secondary
>>> views where simple text is required e.g. when messaging, references are
>>> currently ignored.
>>>
>>> There may be another issue with the above example, because of the
>>> complexity of the osisRef attribute but that is not John's primary
>>> concern.  Although I believe John has raised an issue regarding multiple
>>> refs in an osisRef before.  iirc AB just uses the first ref, which also
>>> isn't perfect.
>>>
>>> Martin
>>>
>>> On 27 November 2015 at 23:40, DM Smith <dmsmith at crosswire.org
>>> <mailto:dmsmith at crosswire.org>
>>> <mailto:dmsmith at crosswire.org>> wrote:
>>>
>>>    I’d have to look into this carefully to see why it is being dropped.
>>>    I think the xslt expects references to be in a note. From memory, a
>>>    reference that is not within a note is treated as inline text.
>>>
>>>    Also there is no support for non-biblical references at this time.
>>>    It should recognize the work part of the reference, what’s before
>>>    the colon, as the module name. We’ve never supported types of x-
>>>    that were not generated by JSword. If the type of the work needs to
>>>    be communicated, it probably should be something like
>>>    osisRef=“Dictionary.UZDOTL:….” In the absence of that we should look
>>>    to see if there is a book with those Initials and determine the type
>>>    from the MetaData.
>>>
>>>    In this example the osisRef is to 2 different works. Not sure how
>>>    that should work. Two lookups?
>>>
>>>    The other thing is that we have a toggle for references that merely
>>>    toggles whether the reference is a link. Not sure how a reference
>>>    can be to two different things.
>>>
>>>    My guess as to what is happening: It tries to parse the reference as
>>>    a Bible reference, gets an exception and doesn’t show anything.
>>>
>>>    DM
>>>
>>>>    On Nov 27, 2015, at 4:31 PM, Martin Denham <mjdenham at gmail.com
>>>> <mailto:mjdenham at gmail.com>
>>>>    <mailto:mjdenham at gmail.com>> wrote:
>>>>
>>>>    John has raised this issue
>>>>    <https://github.com/mjdenham/and-bible/issues/46> regarding the
>>>>    content of reference tags being removed in And Bible under certain
>>>>    circumstances and this has highlighted a possible flaw both in
>>>>    JSword and And Bible code.
>>>>
>>>>    The full details are in this issue
>>>>    <https://github.com/mjdenham/and-bible/issues/46> but are
>>>>    summarised below.  I am not an OSIS expert so really would just
>>>>    like confirmation of my understanding.
>>>>
>>>>    In the following extract from UZVL the reference content
>>>>    'muqaddas' is being excluded both by JSword's
>>>>    OSISUtil.getCanonicalText and by certain And Bible code and I wish
>>>>    to confirm this is a bug:
>>>>
>>>>        <verse sID="Gen.2.3" osisID="Gen.2.3"/>Xudo yettinchi kuni barcha
>>>>        yaratish ishlaridan dam olgani uchun, bu kunni muborak qilib,
>>>>        <reference
>>>>        type="x-glossary" osisRef="UZDOTL:MUQADDAS
>>>>        UZDNTL:MUQADDAS">muqaddas</reference>, deb boshqa kunlardan
>>>>        ajratdi.</p><verse eID="Gen.2.3"/>
>>>>
>>>>
>>>>    My current understanding is that a reference may or may not
>>>>    contain canonical text.  If a reference is a child of a note
>>>>    element then it will not be canonical, but if it has no specific
>>>>    parent then it will be canonical.  Is that correct?
>>>>
>>>>    Martin
>>>>    _______________________________________________
>>>>    jsword-devel mailing list
>>>> jsword-devel at crosswire.org
>>>> <mailto:jsword-devel at crosswire.org><mailto:jsword-devel at crosswire.org>
>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>>>    _______________________________________________
>>>    jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> <mailto:jsword-devel at crosswire.org><mailto:jsword-devel at crosswire.org>
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org <mailto:jsword-devel at crosswire.org>
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org <mailto:jsword-devel at crosswire.org>
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>

More information about the jsword-devel mailing list