< hansen(_at_)pegasus(_dot_)att(_dot_)com writes:
<< I personally don't have a problem with the lookahead. That's what seek()'s
<< are for, and in practice, you'll never have 35 megabytes of whitespace
<< before the potential non-whitespace octet.
< You can't always seek(). If the grammar can't reasonably be parsed in a
< single pass, there's something seriously wrong with it.
<
< When dealing with binary objects, pretty much anything can happen in
< practice. Regardless of whether or not something can happen in practice,
< if something is legal, a parser has to correctly parse it or it's not
< conforming.
I've dealt with a lot of binary objects, and I agree that lots can occur in
them. I mentioned seek() as one possible implementation, but it's not
necessarily the only one which can handle the problem.
< 1341 prohibited boundaries from being substrings of enclosing boundaries.
< Many parsers developed to 1341 will make mincemeat of objects that violate
< that prohibition. The prohibition was inadvertantly removed in
< 1521--whoever did the grammar in 1521 seriously botched the job, it has a
< number of problems with it which I've previously pointed out.
<
< There is no pressing need to allow boundaries to be substrings of
< enclosing boundaries. Composers can simply choose different boundaries.
Most of the time, this is quite true. One time, however, when it's not easy
is when you're dealing with generating messages which contain other
pre-existing messages.
< Making parsers that can deal with both subsring boundaries and trailing
< white space, on the other hand, is a complex task.
We have different definitions of complex. I don't consider this a complex
problem at all.
< LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Boy, I haven't seen ihnp4 mentioned in years! :-)
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com