dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] <text> element (#12020)
- From: Deborah_Pickett@moldflow.com
- To: dita@lists.oasis-open.org
- Date: Tue, 28 Aug 2007 15:51:17 +1100
"Ogden, Jeff" <jogden@ptc.com> wrote
on 08/16/2007 01:18:45 AM:
> Sounds as if <ph> should be a specialization of <text>.
We are
> probably trapped by the past, however.
>
> I wonder of <text> should be a specialization
of anything or just a
> new addition to the base element set for topics and maps.
Actually I'm not really responding to
Jeff's remarks, but to this remark from Michael from the 21 August minutes:
MP: In the past we used <keyword>
to work around this issue. Would <keyword> fulfill this need?
The trouble with <keyword> is
that it has semantic baggage: it imparts some magic onto its contents.
The language spec suggests that <keyword> be used for things
like enumerations with key-like meanings. (At my day job we also
use <keyword> for hotspots on web pages, for URLs, and for names
of XML elements. We even boldface <keyword> by default. Yes,
we should make specializations.) When we translate content, we are
sure to tell translators that <keyword> contents mean more than just
their text value, that they may need to be treated specially.
The idea of <text> is that, by
definition, it contains no semantic baggage at all. In fact, its
contents could always be unwrapped from the element and (where it still
obeys the content model) there would be no change in meaning. It
exists only to define reference points for ID-related things like conref
and to overcome the messiness of mixed content models.
Hence why <ph> would be a closer
match, but the problems with <ph> were already talked about.
--
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]