fourth H1 id=3
third H2 id=7
second para id=12
... my annotation ...
third para id = 13
second H2 id=8
first para id = 14
or something like that, and you store both the structure before and after
the annotation. Then you have a chance of recovering as long as future
revisions of the document don't alter the original IDs.
A couple of comments. It seems like documents can have at least a couple of
purposes. First, they can be traditional things where someone writes them,
a few people comment, and the author integrates or rejects their suggestions.
The second is a document as the source for a thread, similar to the way netnews
or Lotus Notes work. In this case, it is likely that there will be one
original document and many annotations. In this case, the author shouldn't
revise the original document, subthreads which pertain to other annotations
rather than the original document should be allowed, and you need a fairly
serious bulletin-board style UI as opposed to the simple document interface.
In a number of cases I can think of, this latter model would be very useful
with WWW.
John
>From daemon@nxoc01.cern.ch Mon Aug 9 15:42:02 1993
>To: www-talk@nxoc01.cern.ch
>Subject: Re: Annotations futures
>
>John Danner writes:
>
>> I haven't been following this discussion at all, but using
>> character-offsets seems like a pretty weak mechanism for marking
>> annotation positions when you have the SGML structure of a document
>> lying around.
>
>Fair enough. Instead of character-position offsets, do you mean
> fourth H1
> third H2
> second para
>
>Is that enough detail for the annotation?
>
>> Our experience on Oracle Book, a commercial hypertext system, is
>> that except for electronic review situations, authors will not take
>> responsibility for repositioning annotations.
>
>This sounds reasonable. I think this means the annotations (as
>stored) should have an md-5 digital signature of the original document
>to enable the client to say ``this is an annotation of an EARLIER
>version''. I don't think full versioning is possible, given the
>limitations of the resolution of HTML's semantics.
>
>Nat
>