[sword-devel] Tagging verses and verse lists

[Jonathan Morgan]

On Dec 20, 2007 1:55 AM, Eeli Kaikkonen <eekaikko at mail.student.oulu.fi> wrote:
> On Thu, 20 Dec 2007, Jonathan Morgan wrote:
> > A good point that hadn't occurred to me (I'm still very much an ASCII
> > man).  For Sword, UTF-8 might end up best, but technically it is one
> > of the worst formats possible.  Its only redeeming feature is that it
> > allows existing 7-bit ASCII to work unchanged.  For the rest, I need
> > to employ special parsing techniques to ensure that it is parsed
> > correctly.  I prefer 16-bit character unicode, since it is a very
> > simple and direct representation at the level of intent, which still
> > allows my array accesses to work correctly and so on.
>
> I don't quite follow you. Most platforms (modern programming languages &
> libraries etc.)  use unicode internally but can use utf8 as a data
> exchange encoding. I don't see why this is a special situation.
> Conversion should be possible with any platform and the Sword library
> users have to handle conversions anyways, even all modules use either
> utf8 or some other encoding, not unicode. It's just much easier if we
> have only one standard encoding.
>
> I can understand what you say if you have worked only with standard
> c/c++ libraries but all important toolkits should have their own string
> implementations and there is no need to handle low-level unicode/utf8
> features because the libraries take care of them.

Sorry, that was a general statement that I don't like UTF-8 in
principle - it was not saying that I think this problem is somehow
special and so has different needs.  You are quite right that it
should not affect the application writer too much if they use the
right libraries (as they should).  My concern with UTF-8 is just the
simple one that it has the potential to convert constant time
operations into linear time operations, which strikes me as inelegant
when there could be a simple 16-bit character solution that does not
have this property (or 32 bit if you wish to handle the full range of
characters, as in UTF-16).  I think Sword tends to support UTF-8 best,
which as you say probably makes it the best choice.

> > I view the description and comments as simple plain-text comments, and
> > so do not see the need for markup.
>
> Me too. This is the exact failure with the Personal Commentary, we have
> to avoid it here and keep things simple because markup is not needed.
>
> > As said just before, I think the verse range is the most compelling
> > one (though this gets more interesting if we want to deal with more
> > than just Bible references).
>
> There is no limit to how long a range can be (a whole book perhaps or
> even more) and it cannot be broken to single verses, that seems quite
> clear to me. But how about a list of verses? Should it be possible to
> represent e.g. a search result as one bookmark or is it enough to break
> it to several bookmarks under one header? WWUW (What Would Users Want)?
> If an app lets a user to save a search result as a bookmark how it
> should be represented in a UI? Maybe a list of bookmarks is enough, I
> don't know.

Speaking as a user, I think verse range but not verse list is best,
because it means that it can be displayed in a reasonable fashion so I
can use it (if the search results were displayed as one entry, then it
seems to me less likely that the application would display them in the
same way as the original search results were displayed, which is
somewhat less than intuitive).

> > I don't see this as a problem.  So long as Sword defines the
> > attributes that the thing can have, no information will be physically
> > lost.
>
> True.
>
> > If applications choose to display a subset of the data
> > available then that is probably a little unfortunate for the user, but
> > it will not actually lose them data.  Applications should be
> > recommended to make the data available in some form, but I don't think
> > it is required.
>
> Yes, and now we just have to guess how unfortunate it can be for the
> user.
>
> But this is just one example of the ordinary "must/should/may" options
> in many (internet) standards. Bookmarks must have folders and bookmark
> items, folders must have editable names, folders and bookmarks may have
> comments, if comments are supported there must be no markup and the
> application should support both short oneliners and longer text. Etc.

Even if we define a "must", we can do nothing to force the front end
to follow it.  We can probably come to a consensus over what seems
reasonable to require (and add it to the Wiki or documentation if so
desired), but it is then up to applications to do it.

If anyone has any ideas on how to get more users involved in this
process or general Sword critique and personal desires for the
software, I would love to hear them.  In the absence of that, your
best bet is often to try and do things that you want, in the hope that
others will want them to.

Jon