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

[David Goodger]

Ian Bicking wrote:
> I think there should be some plan in place to add extra types, but only
> add them as people request them.
...
> 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.

That's reasonable.  But what I'm trying to establish is where to draw the
line?  How much demand is enough to allow a new role in?  It's been up to my
judgement so far.  Unless I hear some compelling arguments otherwise, I
suppose it will remain that way.

> But if `something`:type: is valid for any "type",

It's not.  "type" has to be one of a pre-defined set of roles for which
there is parser and doctree support.  Each role will have an associated
method or function that understands the role's semantics.

> 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.

("Effect" or "affect"?  Completely changes the meaning of the last
sentence.)

> 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.

There won't be arbitrary semantics, and there's no need or room for
rendering hints in the markup.  That's really basic: keep the style separate
from the structure.

-- David Goodger    http://starship.python.net/~goodger

Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv