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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: Re: [dita] Proposal 13031: Add Line-Through


And in the category of legal documents, include standards. I first started
thinking about this requirement in the context of the DITA-based GAAP
standards developed by the FASB. It also came up at the Federal Reserve, if
memory serves.

There is a general category of "showing corrections" as well, which is
similar to, but not necessarily the same as showing revisions. The fact that
something was corrected and what it was corrected from may be an essential
part of the content, not simply a revision in the "I changed the file"
sense.

Cheers,

Eliot

On 7/26/11 11:14 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote:

> Here are some use cases that I've run into:
> 
> - Legal documents showing revisions where the revisions are not marked using
> @rev.,
> 
> - More generally, in a data conversion context where the DITA encoding of
> the document is not itself being revised, but the content as captured in
> DITA needs to reflect strikethrough used for an unknowable purpose (at least
> as far as the agent doing the conversion is concerned).
> 
> - Discourse where line-through is used for rhetorical effect.
> 
> - Informal documents, such as business documents, where the overhead of
> using full revision markup just to get strikethrough is prohibitive (in
> particular, the need to configure and use some form of DITAVAL facility).
> 
> Other potential additions to highlight, as distinct from a separate
> "formatting" domain as represented in DITA for Publishers, include:
> 
> - overline (as a complement to underline and line-through)
> - blink (obviously only useful for online presentations).
> 
> My reasoning for not suggesting more additions to highlight and thus having
> a separate, more expansive formatting domain, is to make it as easy as
> possible to not allow formatting requests that most, if not all, technical
> documentation users would absolutely not want.
> 
> A separate formatting domain that essentially includes anything that any
> likely rendition target might support, then provides the option of allowing
> more where more is appropriate, as it is in most publishing contexts, where
> arbitrary, distinctive, and idiosyncratic formatting is the order of the
> day.
> 
> Cheers,
> 
> Eliot
> 
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.reallysi.com
> www.rsuitecms.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com



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