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] Groups - Issue #12038 - Proposal: Acronyms and other AbbreviatedForms (IssueNumbe12038.html) uploaded

gljoseph@yahoo.com wrote on 09/12/2007 07:07:45 PM:

> 26361/IssueNumbe12038.html

The <expanded> form will be a specialization of the <keyword> element, while the <short> element will be a specialization of the <data> element. This means that the expanded term is a normal phrase, while the short form is metadata that is hidden when processes do not know what to do with it.

I question the usefulness of this when the expanded and surface forms both inherit from <keyword>.  A processor which is not aware of the abbreviated form specialization will generalize the keywords and display the WMD example as "Weapons of Mass Destruction Weapons of Mass Destruction (WMD)".  (Also, I don't think that <keyword> inside <keyword> quite survived; do some of those need to specialize from <text> instead?)

The problems raised in the Translation Issues worry me greatly.  First, I doubt that the list is complete, and I suspect that there exists some language where even more sinister problems lurk.  Second, this happens even for topics that are not translated: witness an indefinite article in front of "HTML" when you spell out out ("An HTML document", "A Hypertext Markup Language document").  Obviously the solution is "then don't do that", but since our documentation is translated to 9 languages, I don't want my authors (and outsourced translators) to have to know nine sets of things not to do.

Deborah Pickett
Information Architect, Moldflow Pty Ltd, Melbourne

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