OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: DOCBOOK: Issues with processing expectations of the proposedannotation element

Yann Dirson <ydirson@fr.alcove.com> writes:

> How do people feel <annotation> would relate to <footnote> and <remark> ?
> It seems to me that <remark> would be just a special case of
> <annotation> (class="(Editorial|ProofReader)", and maybe a couple
> more),

I don't think I would go that far. I can imagine that users might have
sub-classes of remarks that they want to distinguish for one another--
for example, a <remark role="for.reviewers"> that they want only their
technical reviewers to see, and a <remark role="editorial"> that they
want only their editors to see.

Yeah, I know if Remark were made a class of Annotation, sub-classes of
remarks could also be handled by just including the sub-class values
as values of a second attribute on Annotation (the Role attribute or
whatever). But it seems to me that, as a rule, if a strong need to
sub-class a certain attribute of an element is foreseen, it's time to
make that attribute an element instead (or, in the case of Remark, to
just continue to retain it as a separate element).

> and that <footnote> could be merged into <annotation> as well, but
> I'd rather not use "footnote" as a class value, as it has IMHO too
> much layout-oriented connotation. Maybe footnotes could be made the
> default processing for <annotation>,

On this, I think I agree with you. "footnote" is purely a description
of how the content should be presented -- it doesn't say anything
about the nature of the content. What I mean is, it's not at all
parallel to something like "expansion" (a class value for Annotation
that I included in the proposal -- to be used for marking up
expansions or "spelled out" versions of acroynms and abbreviations).

So I agree that it wouldn't be appropriate to have "footnote" as a
class value for annotations. It should instead be a value for some
parameter in the processing application, e.g., the DocBook stylesheets
might include a general anno.rendering parameter with the supported
values for print rendering maybe being "footnotes" and "endnotes".

> and some annotation classes (eg. editorial comments) would be
> possible to render as marginalia.

Right, rendering as marginalia should also just be left up to the
processing application -- it's purely a description of how the content
should be presented, says nothing about the nature of the content.

But I don't think there's actually any easy way to render marginila in
HTML or in XSL-FO or DSSSL, so I doubt you'll ever see the DocBook
stylesheets providing an option for rendering annotations as marginalia.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC