[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. --Mike
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC