[sword-devel] linking syntax
DM Smith
dmsmith555 at yahoo.com
Sat Nov 29 08:28:42 MST 2008
On Nov 29, 2008, at 1:16 AM, Chris Little wrote:
> If we may take a moment to actually discuss development...
> I think we may have a problem....
>
> Troy A. Griffitts wrote:
>> support for external links:
>>
>> There is currently no programmatic features in the engine which
>> help or
>> hinder external links. Historically there has been a common
>> conceptual
>> agreement that a 'reference' is to that of a 'general Bible'.
>>
>> This needs to change, we all agree.
>>
>> The agreed extension is to:
>> implement support for the key prefix on OSIS tag <reference
>> osisRef="module:key"> syntax.
>>
>> use the prefix to specify a sword module.
>> determine a set of meta modules like:
>> bible:
>> strong:
>> self:
>>
>> default the prefix, if absent to 'bible:' so current modules still
>> work.
>>
>> None of this requires engine changes, but rather that we extend the
>> historical conceptual idea of a reference beyond bible:key.
>
> Meanwhile, the OSIS manual says:
> <QUOTE>
> A reference element was used in the note example above. To refresh
> your
> memory, here is just the reference element part of that example:
>
> <reference osisRef="Ezra.4.6">Ezra 4:6<reference>
>
> Note there is no osisWork prefix, that is no ‘name:’ in from of
> ‘Ezra.4.6’ in the osisRef attribute. That may be for one of two
> reasons:
> First, that is being supplied by the osisWork default, i.e., it is a
> reference in this work. Or, the osisWork prefix may have been set by
> the
> the workPrefix element in the header element of the document.
>
> In either case, if you want to point to another text, you must declare
> that in a work element and use the value of the osisWork attribute
> from
> it to make references to it.
> </QUOTE>
>
> The two positions appear to be in conflict with respect to the default
> workID. The spec says the default workID is either specified by the
> header or the current document. Troy suggests that the default should
> always be Bible:. I think my own encoding practice, when it even
> makes a
> difference, follows the manual's standard.
>
> So, do we follow Troy's suggestion and take default to be Bible:
> when no
> workID is specified? Or do we follow the OSIS spec?
>
> I have a feeling the former is probably the more pragmatic approach,
> precisely because it doesn't break existing content (though I'm not
> sure
> either approach would break anything in the public repository). But we
> need to make a decision on this for our own encoding, importer, and
> documentation purposes.
I've written and re-written my response to this several times....
Having thought better about what I have written, I'll state my
conclusion:
IMHO, the OSIS manual and spec are not consistent on workIDs. The
manual states that the default workID is the work itself. Troy pointed
out that the schema defines it as Bible:. The workID is also defined
not as an abstraction but a reference to an explicit particular work.
This needs to be fixed.
The notion of workID and workPrefix is nice, but in the context of a
SWORD module, quite meaningless. If the conf maintained workID and
workPrefix or if we retained and used the OSIS header then it might be
useful.
Apart from that our mechanism needs to be simple and work without
breaking existing modules.
I think we need to define:
1) How to reference a Bible. This is the only kind of reference that
SWORD supports right now. All are assumed to be biblical, so the
absence of a workID has to imply Bible:. At least in Bibles and
commentaries. Maybe the default in a dictionary is the same work. I
think we also need an explict mechanism for a non-KJV versification
reference. I think we should use the list as given in the OSIS manual
(e.g. Vugl for Vulgate, LXX for septuagint, MT for Masoretic
Text, ....) or some other well defined list.
2) We need internal linking, especially for dictionaries. Troy
suggested "self:" That works for me.
3) We need to link to an arbitrary work. Using the module's [name] has
been suggested.
In Him,
DM
More information about the sword-devel
mailing list