[Doc-SIG] Re: [Docutils-develop] master plan for interpreted text?
Ian Bicking
ianb@colorstudy.com
Mon, 3 Feb 2003 16:56:05 -0600
On Monday, February 3, 2003, at 02:07 PM, David Goodger wrote:
> * emphasis
> * foreign words
> * special terminology & technical terms
> * words used as words
> * letters as letters
> * musical dynamics (pianissimo as italic "pp" etc.)
> * letters indicating ryme schemes (as "aabba" for a limerick)
>
> All of these are mapped to italics. Should we have roles for each of
> them? Even if we combine closely-related cases (words as words &
> letters as letters; musical dynamics as a case of foreign words), we
> have 4 or 5 cases here. DocBook has dozens more inline elements. How
> far should we go?
I think there should be some plan in place to add extra types, but only
add them as people request them. The richer the formatting, the less
likely different people's markup will match each other -- in one place
someone might use `pp`:music:, where another just uses *pp*, etc. The
lack of semantic markup in the current version (I certainly think of
*emphasis* and **strong** more in terms of their rendering and physical
look than any semantics) makes this less of a problem, because
semantics are highly ambiguous while rendered look is concrete.
But if `something`:type: is valid for any "type", then I suppose it
doesn't matter, so long as the output format has some way of
identifying the proper styling. As I think about it though, it's
non-trivial to effect any output but HTML.
Anyway, in summary: just because you *can* identify a semantic
classification doesn't mean you should. I seldom see the benefit, and
before introducing more complexity into the system there should be a
concrete reason someone wants to do so. E.g., they want to mark
glossary terms for later compilation -- a very concrete desire. But if
it is more work to restrict the kinds of semantic inline markups then
to allow arbitrary semantics, then perhaps arbitrary semantics make
more sense. In which case perhaps there should be a directive to give
rendering hints (and hopefully definition hints!) in the document
itself, as otherwise the document won't be portable.
Ian