There's almost certainly no absolutely "right" point on
that continuum to be.
well, perhaps, but if we pretend to have an upwardly extensible
design then a certain minimum complexity seems necessary, too bad
exactly what that should comprise has eluded us.
rhys> I'd expect that the <colorentry> example would be
rhys> "wrapped up" in a <param> block...
<param> xxx </param>
becomes
<param> {a..z} </param>
Given that context, any of the following
1 <param>{<8bitRGB> <c>red 255 0 0</c>... </8bitRGB>}</param>
2 <param>{<8bitRGB> <c>red 255 0 0</c>...}</param>
3 <param>{<8bitRGB> red 255 0 0... </8bitRGB>}</param>
4 <param>{<8bitRGB> red 255 0 0...}</param>
meets my concerns regarding engines which are ignorant of the particular
parameter.
My (weak) personal preference between them would be
2, but I wouldnt be unhappy making a parser for 1, 3, or 4.
In other words, I think that, inevitably, text/enriched
is neither powerful enough to do everything nor simple
enough to satisfy everyone, but that if we were to
change it from its current spec, we'd be better off
simplifying even further at the expense of power.
I dont think the baby is dead yet, but the bath water
is getting cold, lets see if we cant get it changed?
--
dana s emery <de19(_at_)umail(_dot_)umd(_dot_)edu>