[sword-devel] Tagging verses and verse lists
jonmmorgan at gmail.com
Tue Mar 10 03:37:46 MST 2009
On Tue, Mar 10, 2009 at 2:02 AM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> Quoting Jonathan Morgan <jonmmorgan at gmail.com>:
>> I'll add to this:
>> f) Should support passages, not just individual verses (the definition
>> of a passage is interesting - after looking at my notes that I take,
>> I'm inclined to extend it to any collection of verses, not just a
>> continuous passage, and will probably change it to that in BPBible
>> Feel free to dispute, but it makes sense to me.
> It's quite difficult to follow others' thoughts in this subject. One
> important thing is to make difference between the techical implementation
> and an end user/UI need. For example, how
> 1: Matt 1:2-5, John 1:3
> 2: Luke 3:2-4, Rev 1:1
> 1:Matt 1:2-5
> 2: John 1:3
> 3: Luke 3:2-4
> 4: Rev 1:1
> and List1
> 1: Matt 1:2-5
> 2: John 1:3
> 1: Luke 3:2-4
> 2: Rev 1:1
> differ from each other in implementation and in a use case? I see List1 and
> List3 semantically identical, though they look different in UI. Even the
> List1 could be implemented with non-non-contiguous ( :) ) passages - items 1
> and 2 are just sublists.
I am talking entirely from a UI point of view. All of these are
different in the UI, so to my mind they need to be supported by the
implementation and different in the implementation. Your examples
become more different if comments are supported (which I do support).
List1. Description of my list.
1: Matt 1:2-5, John 1:3. Comment about these verses.
2: Luke 3:2-4, Rev 1:1. Another comment.
List2. A new list.
1:Matt 1:2-5. Comment about these verses.
2: John 1:3. Some random comment.
3: Luke 3:2-4. My comment.
4: Rev 1:1. Another comment.
List3. This super list.
Sublist1. An important sublist.
1: Matt 1:2-5. Some comment.
2: John 1:3. Some other comment.
Sublist2. Another sublist.
1: Luke 3:2-4. New comment.
2: Rev 1:1. XXXXXXX.
They are separate items in the UI and should be treated as such in the
implementation. Depending on how you present them, the concept of
"separate items" might be more or less tangible. But I think
fundamentally they are separate.
My comment was that often in my notes (especially of talks) I find things like:
Heb 1: 4 - 7, 9. Comment about this collection of verses.
I can't see any really compelling reason to have an entry like:
Rev 3:2, Gen 4: 1 - 3, Ex 2:3. My comment on these disparate verses.
but I no longer see any reason to stop the user entering it.
>>> So, is it time to resume the debate and bring it to a conclusion?
>> I don't believe it is possible to conclude in practice (or even in
>> theory), since that would be assuming that there is one solution that
>> will suit all needs. I can 95% guarantee that some of the things I
>> want to do will not be interesting to others or just plain will not be
>> implemented. That being the case, I prefer to implement what I
>> believe to be the right thing or just an idea I have in mind without
>> being fettered by any compatibility or anything. If it turns out to
>> be a dead end then I have only wasted my time.
> Whatever the implementation is, if we want the SWORD applications to
> interact with each other and be compatible - which they really should do -
> we have to create explicit conventions for bookmarks/tags/whatever exchange.
> A common technical implementation doesn't help at all if the frontends
> implement the ideas differently. For example, the frontends must not use
> other than plain text. They are not allowed to change the order of the
> bookmarks unless user wants it.
And it is that that I am saying I don't want to limit myself to. It
is perfectly possible to have a common backend implementation both in
theory and in practice so long as you don't depart too far from the
mould (though I fear I will ;) ). I don't think it is possible to
have multiple UIs that have different . While compatibility is nice
in theory, in practice if I am offered the choice between exploring an
incompatible idea that I want to see how it will work and implementing
just the same as every other Sword application has agreed to support,
I will take the former.
> It may be impossible to conclude in practice, either in technical or in UI
> level. At minimum we need some technical implemantion for bookmarks (I'm
> leaving "tags" out because I don't understand the concept well enough) AND
> explicit usage convention for bookmarks. The technical implementation can be
> used for whatever purpose, for example for storing app settings, but a SWORD
> Bookmark Compliant application must follow the written conventions to offer
> the users a user interface which allows using the bookmarks in other
> compliant apps.
It may be possible to have a version that is viewable by all
applications and degrades gracefully, but I suspect very strongly that
even if you had software that was technically compliant they could
have a difference in interface model that meant that the user would
not perceive them as the same, which sort of removes the purpose.
Again, if the explicit usage convention conflicts with the model I
wish to adopt I will pick my version over the conventions. It is the
way of exploration rather than of standards, and, while not
necessarily better in all cases is much more interesting IMHO.
>> I take very strongly the "version independent
>> unless asked otherwise" viewpoint.
> I agree. In that case we need to take care of v11n. People want a specific
> passage, not whatever is in Book2:3 in some translation.
Agreed (in general).
More information about the sword-devel