Subj : XML
To   : Jan Vermeulen
From : Jesper Sörensen
Date : Sat Jan 04 2003 11:55 pm

 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@enjoy.cc
---
 * Origin: Singularity/2 - Swedish Internet Backbone (2:204/255)

.