[Top] [All Lists]

Re: Text/enriched ambiguity

1993-10-31 11:28:34
  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>


  <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

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>

<Prev in Thread] Current Thread [Next in Thread>