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


I'm with Richard in not liking the idea of tying 'strikethrough' to revision/change tracking.  However we decide to semantically describe change tracking, I don't want to prescribe how someone has to present those semantics, even if the DITA-OT makes choices in its processing.

I looked at Eliot's list of 'formatting' additions and in addition to strikethrough, I also find the following to be compelling additions to the highlighting domain:
-  overline  (heavily used, btw,  in semiconductor documentation)
-  bold italic
-  roman - removal of bold and/or italic

My reasoning is that these are all, like most of the other highlighting elements, glyph-based but not typeface-based presentation (don't get me started on <tt>, but I know it's historical and can't be avoided.).  If we put these items anywhere except hi-d, it will be very counter-intuitive for people looking for such things.  I would favor adding them to hi-d, creating a constraint module to remove them, and including the constraint module by default in all the vocabulary modules calling hi-d, the way we do with the strictTaskbodyConstraint in tasks for 1.2.

I don't consider any of the other items in the formatting group to fall naturally into the same category.  Even though blink does meet the glyph-based/non-typeface-based model, and could probably be construed as 'highlighting' in some sense, it doesn't feel like the same thing.

my $.02


On Tue, Jul 26, 2011 at 1:38 PM, Richard Hamilton <hamilton@xmlpress.net> wrote:
I'm concerned that we're straying into a gray area with some of this discussion about strike through.

Even though I'm a "strict constructionist" when it comes to semantic markup (must be my DocBook roots:), I do understand the usefulness of a highlighting domain. If nothing else, it helps you avoid some of the egregious tag abuse that I'm sure most of us have witnessed (if not perpetrated ourselves). I also like the idea that if you're going to have representation markup, it should be called out as such and kept separate.

However, in the discussion today about strikethrough and revision markup, we blurred the line between representational and semantic markup.

Yes, strikethrough is typically used to show deletions in revision markup, but from a markup point of view, there is no more connection between strikethrough and revision markup than there is between italics and the <var> element.

My hope is that we make sure that in creating revision/correction markup we avoid anything that ties the markup to a particular representation, and that in extending the highlighting domain (and possibly creating a formatting domain) we avoid suggesting that elements in those domains are the preferred way to represent revision/correction markup (or any other kind of semantic markup).

Best Regards,
Richard Hamilton
XML Press
XML for Technical Communicators

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:

Nancy Harrison
Infobridge Solutions 

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