Jewett, Jim J wrote:
>> Will there be only one annotation/bookmark db per text db?
Alexander R. Pruss:
> Yes. I don't think the renderer should be scanning several.
I agree with this, in principle; the question is what sort
of tradeoffs that will require.
For example, if I were reading something by Plato, I might want
to see translation notes, commentaries from Augustus, class
notes from a professor, notes from a modern scholar relevant
to my own paper, and my own comments.
I also might want to beam the class notes but not the modern
scholars's notes. (And if version one is beam all-or-nothing,
then the receiver might want to avoid duplicating all the
Professor's notes, but also avoid losing his own notes.)
> One solution is to make some "merge" code.
So if there is only one commentary, then a good utility for
merges and partial exports becomes more important.
> Well, maybe some work would need to be done about overlapping
> annotations--that's something that isn't permissible yet.
I understand if that is a pain for version 1, but I think it
should change eventually, and the header format should not
make it harder.
Perhaps order annotations by start-point, and the reader can
just keep looking for additional annotations until the next
start-point is "too far" ahead?
> There will be room in the header for future data.
How?
The structure I see lets you add *bytes*, but I don't see
any reliable way to add *fields*. If I find a longer
header length, I know that more space has been reserved,
but I don't know what it is for; at best I can treat
header length as a version field and hope that no one
else extends the header differently.
What I would like is a variable-header section, perhaps
as pairs of strings for field-name/value. (This does
make the header variable length.) That way, if someone
else adds a different extension field, I can just ignore it.
> The uid is the record number of the annotated record.
> The index is the index of annotation within the annotations
> for this record. Thus, the first annotation for this record
> is 0, etc.
So you are assuming that an annotation-db record will contain
several different annotations? Is that just for space/synch
efficiency? I wouldn't recommend doing that, because it makes
it harder to merge/filter annotations.
Or are you saying that there can be several annotations of a
single text-record, and you order them by index instead of
by start-position? If so, why?
> I am hoping we don't need a version yet.
I think a self-defining variable header would be better, but
I think we need at least one of the two. If we add a version
number later, then future code will always have to say
if header.length == x
version=0
else
version=header.version
>> RecordType (Bookmark vs edit vs commentary)? Or is that assumed
>> to be handled by the palm categories? I suspect we will want
>> both record type and user-defined categories within (at least
>> some) annotation types.
> I don't know about "edit". As for bookmark vs. annotation, the
> difference is not significant really. I consider annotations where
> triggerStart == triggerStop to be bookmarks.
I was thinking of record type as indicating the layout, in case some
annotations needed different data.
edit vs commentary vs bookmark are different reasons for the
annotation; it is possible that users will want to turn off some
but not all annotation categories sometimes.
>> Is there a way to make annotations that span paragraphs,
> Not with the current highlighting code. However, eventually,
> it could be done by just allowing triggerStop to point beyond
> the current paragraph.
OK; in that case I would personally prefer that triggerstop
include paragraph data, but I would certainly understand if
that were part of the variable header. (A bit ugly in the
code, but treats the normal case as the default.)
>> For paragraphs, you could just add a stop
>> paragraph number, but for different indices, you might want a
>> "refer to annotation X; it still applies" record.
> This can be done if we need it later.
Which is why I wondered whether their should be a record-type
field, or whether palm categories would be used for that (in
which case we should do something like the plucker extended
categories for selecting groups of annotations).
>> What does the yoffset provide? ... Is it the absolute y-offset,
>> making assumptions about the font and screen-width?
> It lets one position things precisely, so a bookmark can be
> set on a half-line, or more usefully, half-way through a table.
> Currently when the assumptions become invalid, the y-offset is
> invalidated, and the bookmark just goes to the top of the text
> that is bookmarked (e.g., top of table, start of line).
Then doesn't trigger-start provide (a superset of) this same
information, except that it won't be invalidated (and *might*
be slower to render)?
Instead of saying
"30 pixels down, which I hope will be row three
of the table",
you can say
"419 characters in, which I know is in the second
column of the third row of the table".
So I guess in summary, I would get rid of headerLength
(use palm-category, until we approach a dozen record
types/versions) and index, but I would definately keep
the dataOffset to leave room for a variable header.
I might even special-case a keywords header (like
extended palm categories) to always be the first
variable header, if it exists.
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
