>FIGT as it stands is inappropriate outside a figure, since the attachment
>mechanism is defined as an offset on the figure itself.
True, so we would like to be able to define offsets relative to the
document itself, either in coordinates or via "at" (as in PANELs as
you suggest).
>Perhaps the PANEL element is what you need. This is attached by an id
>reference, and would seem ideal for your needs. For online use it
>could be rendered as an icon of a thumbtack/drawing pin at the
>appropriate place. Clicking on that would show a popup panel with the
>arrow back to that point.
This has some of the features of what we want but is missing the
crucial characteristic of being an overlay. We'ld like to do
annotations where someone can circle a section of text, draw arrows
between sections of text, point to their own comments, etc. We see
each user's comments being on a layer that sits on top of the original
document (as I mentioned in my previous message we are aware of the
issues of the mutability of the document text).
>The restriction forbidding nesting of tables, forms and figures is there
>to help browsers and authors avoid overly complex documents.
Understood, but then you go on to describe several ways to allow
multiple comments on the same document. I understand what the
browser would do with multiple comments; what I don't know is the
HTML+ syntax that could be used to specify them.
>Both of these would could be implemented by getting the server to send the
>annotations separately from the original document.
That would be excellent and we can see putting a mechanism into the
browser to give the user a choice of which annotations to view.
However, that still begs the question of what is the HTML+ format of
those annotations so that the browser knows where to place them after
it retrieves them.
>A neat solution is to use the MIME multipart capability to segregrate
>annotations according to author (itself passed in an RFC 822 header).
>The browser is then responsible to merging them with this document, as
>appropriate to user preferences.
That is exactly the approach that we have taken. We've also added a
MIME part in which we can store geometric information, but we would
really prefer a "standard" way of describing that in HTML+.
Jay Glicksman