Re: Data table text I/O package?

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitry A. Kazakov wrote:

> No, you just have to use different delimiters between and within the
> fields.

"You just have to... ". No, gosh, the space was _mistyped_,
it wasn't intended. This goes for any typo irrespective of what
delimiter you choose. Now any reasonable CSV has far less offerings for
error correction facilities for typos like these than any reasonable
XML. By definition. (And, yes, I know you can construct syntax errors
in XML, too, if you think this is an argument ...)

Is it the typical Ada programmer's attitude to promote self-documenting
bracketing constructs only for program text, but never for data text?


> This is why in Ada parameters of a procedure call are separated by
> commas rather than spaces.
> 
> Though is it about what syntax would be the best? Or is it about how to
> parse something in a defined syntax?

HAving a "best syntax" requires a measure for syntax quality.
If you measure what a syntax can do in a heterogenous project
by applying your personal aesthetic preferences,
or your reading habits, or your programming skills, I have nothing to say.

If you care about robust data interchange in a "sloppy
field", you employ standard tools to help you get the correct
data.


> Now consider a space between / and >:
> 
> <Distance km='3.15'/ >
> 
> XML adds here nothing, but a huge readability loss.

Oh well... You mean

  Distance'(km => 3.15)

can be read well, whereas

  Distance'( km => 3.15 )

is a huger readability loss? Come on.