Alexander R. Pruss:
>... how annotations should be stored. The consensus is that
> they're being moved out of metadata, and into a separate db.
Will there be only one annotation/bookmark db per text db?
I know that one of the earlier goals was to distribute
commentaries, and there will probably be some texts that
have more than one relevant commentary. Unless there is
a good way to merge them, even after a beam-to-existing-name,
it would make sense to allow multiples.
Also, if you allow multiples (especially if you merge them
into a single db), you might want a way to save attribution
and even date (or timestamp), possibly as one of the header
fields. I could imagine marking comments from one scholar
in Red and another in Blue when trying to compare their
opinions.
>On Sat, 19 Jun 2004, Michael Nordstrom wrote:
>> On Thu, Jun 17, 2004, Alexander R. Pruss wrote:
>> > How's this for each record in the Anno-Filename db?
>> >
>> > typedef struct {
>> > UInt16 uid;
>> > UInt16 headerLength; /* sizeof( AnnotationEntry ) */
>> > UInt16 index;
>> > UInt16 paragraphNum;
>> > UInt16 triggerStart; /* relative to paragraph start */
>> > UInt16 triggerStop; /* relative to paragraph start */
>> > UInt16 dataOffset; /* offset of data from beginning of this record
*/
>> > UInt16 dataLength;
>> > } AnnotationEntry;
Just a check -- is uid the record number of the annotation, and
index the record number of the annotated record?
HeaderVersion? Or is that in the db header, and assumed to be
constant within a single annotation database? (And the same
question regarding which db this annotates. Is it possible to
annotate more than one pdb from the same commentary?)
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.
Is there a way to make annotations that span paragraphs, or even
different db records? 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. (I also see
some value in making both the start and the stop references look
like regular anchors.)
> headerLength is used so we can extend this later to include
> other data, such as RGB value of highlight, and anything else
> one might fancy.
Attribution, time, category (categories?)
> dataLength is also nice for the same reason. For all we know,
> there might be reason to store other stuff in the same record
> eventually, and it might go after the data.
True -- though my inclination for a variable header might be to
put it before the data. I do think there should be a variable
header (or trailer). I can imagine wanting different
meta-information for different databases (previous cost?
alternate part numbers?) and not wanting to burn a version number
for each database.
>> > We might lose one thing. Currently bookmarks specify not just
>> > the byte offset, but also a yoffset.
What does the yoffset provide? Is it a hint about drawing if you
follow that bookmark? Is it the absolute y-offset, making assumptions
about the font and screen-width?
> Do we still keep the add annotation form and the add bookmark forms
> separate?
> The visual difference is that the add bookmark form is a small popup,
Unless this changed since 1.7.2, the bookmark form already covers
plenty of screen; so long as you continue to prefill it with reasonable
defaults so that a single "OK" works, then covering a bit more shouldn't
matter. (Unless there were a way to cut-n-paste from the backing screen.)
-jJ
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
