[Top] [All Lists]

Re: Text/enriched ambiguity

1993-10-30 10:48:00
    I've always seen these as "commands" and coded accordingly. 
If you get a <bold> and then a </bold>,  fine.   If you get a <bold> 
and never encounter the </bold>,  still fine. 

Maybe, maybe not.  In a stack-based parser, this could be a real 
pain in the neck.  It also defeats auto-correction schemes to some 
extent.   ... 
Unless there is a matching </> command or a different way to indicate 
commands that don't need a </>, auto-correction and stack-based parsers 
will be defeated. 
        These are valid points.   Please consider,  and let me know 
what you come up with,  the idea of enhancing a stack based-parser. 
I agree about the usefulness of auto-correction,  and my suggestion 
would complicate that ... slightly.   All you need is a bit somewhere 
saying  "this must be matched within context"  or not. 
For the colorentry example, I can't see anything wrong with (to define
two colours):

      <colorentry>red 255 0 0 blue 0 0 255</colorentry>
        I'd say try, 
                <colorentry>red 255 0 0</colorentry> 
                <colorentry>blue 0 0 255</colorentry>
The extra bracketing cited by someone else seems unnecessary to me.
        Above,  I used the <command> / </command> method 
to delimit the colorentries.   I'm not completely happy with that 
because to me it is less generic than allowing commands without 
matching /commands. 
        See for yourself:  it's easier to take the string 
delimited by angle brackets and act on the "verb" (which may 
or may not have parameters) than to switch into and out of 
"colorentry modification mode". 

Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems 

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