I base my view on line-through on the primary use case of migration,
both of content and of user expectations coming from a mainly
HTML/word processor world view. For other elements in the
highlighting domain, the names correspond exactly to incoming names
rather than semantic names because it is impossible in most cases to
second-guess the author's intent.
One principle of migration is that it is better to name something in
a way that can be searched and filtered later than to wrongly name
something semantically on import because in this case, the content
usually *behaves* correctly but the misuse is hiding in plain sight,
seemingly already correct. Italicized content is usually among the
hardest to guess at algorithmically given the many allowed meanings
in guides like MLA (for titles, emphasis, foreign words, special
terms, and alternative to underlines, etc.).
And while many instances of strike-throughs may be rhetorical, I
can't say that all of them are. So I'm inclined to leave the
highlighting domain focused on preserving legacy notation whenever
the intent is algorithmically unfathomable, which justifies the use
of "tt" and "strike-through" (which in my experience is more common
than "line-through") as commonly used names for those notations.
In deference to the work of the TechComm SC in defining best
practices specfically for their audiences, I'd suggest that one of
their work products ought to be (if not already booked) the creation
of a semantic phrase domain per MLA and other broad writing
guidelines that parallels the highlighting domain but codifies the
usage in appropriate ways for those who adamantly shun the
vernacular variety. The "Typographic Conventions" topic in most tech
manuals is precisely the semantic to visual mapping described by
various semantic domains including programming and hardware (ie,
overbars for flags, which I conceive as specializations of
<state> rather than as phrase content).
I was just tempted to put a smiley emoticon there but realized that
we might just need a domain for those as well. <smile
type="devilish"/>
--
Don R. Day
DITA and XML Consultant,
512 244-2868
Co-Chair, OASIS
DITA Technical Committee
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
On 7/27/2011 11:39 AM, Schengili-Roberts, Keith wrote:
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
