[Doc-SIG] Re: [Docutils-develop] master plan for interpreted text?

[Ian Bicking]

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