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