sl>> The whole point of a new format is to allow addition of MORE
 sl>> data, AND in a more structured format so as to allow future
 sl>> expansion without kluges or abiguity.

 JV>     ESLF can do all that, on a need to have basis.

If I've understood the proposals correctly the ESLF will add some
keyword/value lines before or after each nodelist line. That means we'll be
doing both line-based CSV parsing and keyword/value parsing. (Hooray! ;-) A
pure keyword/value format would be cleaner and simpler.

The SLF/ESLF format is difficult to use in other forms than the traditional
text file. With some work, the nodelist can be imported into e.g. a
database table, but handling the diffs is very difficult. The fact that you
don't need such things right now doesn't mean that noone else need it
either.

 JV>     ESLF will contain all data one ever would need; XML may extract
 JV> whatever it needs.

Yes, it's certainly possible to include much more data in the nodelist
using different tweaks, but it will not be as pure and simple as a real
keyword/value format. Since every piece of software that wants to use the
new data needs to be rewritten we could as well take a bigger step and fix
other issues as well.

BTW, I hope ESLF will use UTF-8 or something similar...?

 JV>     The problem seems to be that the XML developers do not see how
 JV> they could extract that data. As if string parsing would be a PITA
 JV> (even BASIC could do that in the early eighties...).

I've written lots of text parsers in many different languages but that
doesn't mean that I always enjoyed it. In some languages text parsing is a
lot easier than in others but the real issue has more to do with what I
wrote above.

  Jesper,
  yeppe{at}enjoy.cc
---