I'm not sure what "this idea" (to which you are naying)
is, but since you say "as well", and I'm not sure that Nancy was
naying the actual proposal (Proposal 13031: Add Line-Through)--in fact, I hear
her saying that she doesn't like tying strikethrough to change tracking, and Dick
says there is no more connection between strikethrough and revision markup than
there is between italics and the <var> element--and I know I wasn't, I
thought we'd better clarify.
While I am generally on the side of semantics and separating style
from content, is it not the case that strikethrough is equivalent to
deleted-content. In fact, I would be opposed to defining something
semantic like deleted-content to imply any particular formatting (such a
strike-through), so I don't see how a semantically descriptive element would
satisfy Eliot's requirements at all.
The highlight domain isn't supposed to be semantic--it's for
highlighting. True, any non-semantic markup can be misused when there is
a more semantic markup that should be used, but tag abuse is even more likely
(and more confusing when it occurs) when you don't give users a non-semantic
way to get what they want and they have to use positively misleading markup
instead of just non-semantic markup.
paul
From: Schengili-Roberts,
Keith [mailto:]
Sent: Wednesday, 2011 July 27 11:40
To: Nancy Harrison; Richard Hamilton
Cc: dita
Subject: RE: [dita] Proposal 13031: Add Line-Through
I’ll add my “nay” to this idea as well. The
“strikethrough” proposal is more a request for a formatting style
than a prescription for semantic change. I’d be much happier if the idea
called for a semantically-descriptive element (such as
“deleted-content”) rather than a prescriptive approach to how that
content should be formatted.
As an example of this, we use DeltaXML to help us track changes
between documents, and instead of using strikethrough, we use CSS-type
changebars in the margin of the text to single out where change has occurred.
“Strikethrough” would be a very poor description of the change in
content.
The only instance that Elliot lists that doesn’t quite fit
with the rest is the instance of “rhetorical strikethrough”. Thing
is, I have never seen that used in any technical documentation, only in
non-technical articles. If that is truly needed, then something suitably
descriptive, like “rhetorical-deletion” would be more semantically
descriptive.
I also agree with Nancy on her points, and I can confirm that
overline has a special meaning in semiconductor/electrical engineering content,
where it typically means a negative value of the same term without the
overline.
8-{)}
Keith Schengili-Roberts
Manager | Graphics Platform Documentation & Localization
(Markham) | AMD
o. 905-882-2600 x3218
Please
consider the environment before printing this e-mail
From: Nancy Harrison
[mailto:]
Sent: Tuesday, July 26, 2011 4:22 PM
To: Richard Hamilton
Cc: dita
Subject: Re: [dita] Proposal 13031: Add Line-Through
Hi,
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
Nancy
On Tue, Jul 26, 2011 at 1:38 PM, Richard Hamilton <> 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
http://xmlpress.net
---------------------------------------------------------------------
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
--
_____________
Nancy Harrison
Infobridge Solutions
