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,
[email protected]
---
* Origin: Singularity/2 - Swedish Internet Backbone (2:204/255)
