Re: [css3-gcpm] More magic areas than footnote and sidenote?

Hi Paul,

My self-description is an Adaptive Hypermedia researcher
technomethodologically embedded in the CS Ed community :-) We have
identified (and had a lot of success training new researchers by
teaching them to explicitly use) at least three distinct types of
private annotations: quotes, distillations, and musings. Annotations,
however, are not stored in the document itself, but in bibliographic
entries - we usually use bibtex. Being able to store the annotations
associated with a copy would be very useful.

I'd be happy to be your guinea pig (offline from the list) in looking
at the Generated Content Module and seeing what is there, as well as
making sure that the specs are symbiotic with what would be needed to
build this realistically with Javascript. To date, we've not had
annotation systems that came even close to what we wanted, despite my
lab's pretty stellar track record in building other systems and
aspects of systems to meet collaborative work needs in unobtrusive

On Fri, Aug 8, 2008 at 12:14 AM, marbux <> wrote:
> "Should there be a mechanism to create new areas like
> footnote/sidenote, or are two "magic" area enough?"
> <>
> For editing application interoperability purposes, I'm somewhat
> inclined against a flexible mechanism. However, I see a strong need
> for at least three more note elements to be defined: [i] endnotes,
> [ii] comments; and [iii] annotations.
> Endnotes are commonly collected at the end of a chapter or near the
> end of a book rather than on the same page as the note's call in the
> body text. Their use in dead tree books is common and time-honored. A
> target reference for their placement seems necessary, given that other
> end matter may trail the endnotes, e.g., a subject matter index,
> appendices, and the colophon.
> Comments are needed for collaborative document development. A lead
> author will wish to have others comment on drafts, decide whether to
> apply suggested changes, and to retain an audit trail of comments and
> related editing decisions. If no common mechanism is adopted for
> associating comments with content, authors will become trapped in the
> editing application that they receive the first comment in,
> notwithstanding that a desired editing feature is only supported in
> another application.
> An annotation ability is needed for the ultimate reader of a document.
> While this is a feature that will be wasted in dead tree documents, it
> is a feature expected by eBook readers. See e.g., ePub 2.0 (uses CSS 2
> with Daisy DTBook annotation features).
> <>;
> (which are in turn derivative of SMIL).
> <>.
> If a more generic approach to notes is considered, one might imagine a
> generic <note> element with an optional <notecall> pseudo-element and
> with cascading properties for further definition of the note type and
> desired processing. (Note that an emerging trend in both desktop and
> web collaborative editors is to attach comments and annotations to
> highlighted text spans rather than to a note call. This can present
> programming challenges when the span crosses paragraph or page
> boundaries, particularly with intervening footnotes)
> Example <note> types:
> annotation
> approve
> approve-with-changes
> disapprove
> *bibliography-entry
> *calendar-entry
> comment
> *contact
> ** endnote
> footnote
> *memorable-quote
> *research-note
> sidenote
> *todo-task
> =======
> * denotes plausible note types where the "magic" area may be located
> in another document or application or be co-located in both the local
> document and elsewhere.
> ** denotes note type where the "magic" area is at the end of the
> chapter or document rather than on the same page.
> The primary concern I address in this post is that the recommendation
> go beyond presentation to address foreseeable authoring workflow needs
> as well as electronic document reader needs such as annotation and
> maintaining a collection of memorable quotes.
> Best regards,
> Paul E. Merrell, J.D. (Marbux)
> ---
> Universal Interoperability Council
> <>

Received on Sunday, 10 August 2008 08:05:29 UTC