Re: Data table text I/O package?

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitry A. Kazakov wrote:
 
> See below. It is a table. It has bracketing: rows and columns.

Back to step one: brackets in computer tables are not named,
a computer doesn't have accountants' abilities in pattern matching
when looking at rows and colums in a table. Again, I said XML is good
for parsing of data if you cannot tell in advance that the data stream
is totally free of errors. XML provides means to build robust data
streams in the absence of tight definitions and reliable procedures.

As for whitespace, read Stroustrup's article on defining operator
whitespace.


> This form
> existed for centuries before XML. Who would print tables of logarithms in
> XML?

You're missing the point: XML is *not* about rendering data.
Logarithms are logarithms, not printed logarithms, this is a second
step.  Data formats for exchange or storage on the one hand and
a print-out of some data on the other hand are two very different beasts,
with different purposes. Consider the MVC paradigm.


>>If you care about robust data interchange in a "sloppy
>>field", you employ standard tools to help you get the correct
>>data.
> 
> 
> That is a different problem for which I would use a well-defined binary
> format instead of fancy 3.15. What is the *accuracy* of this value, huh?

It is totally unimportant what you or I would want, sorry.
For a robust data interchange, absent comprehensive definitions
and guarantees about data production, you need redundancy, period.

The accuracy is well defined and most importantly,
it is up to the application, yours and mine repectively.
We both use the accuracy that is most appropriate, and I won't
tell you not to use an internal type when it suits your application.
I expect the same of you. If all I have to do is to store kilometers
measuring straight lines inside the Netherlands in a relational database,
I known the datatype I can use, no matter what you think is best
in your application.
 This has been discussed for years during the development of
XML Schema. What do you care about my accuracy as long as
I compute values from your data that are within application
bounds? 3.15 is as accurate as can be, and independent of
bits.


 > Distance isn't a record.

Huh? In data exchange it isn't your job to to tell others how they
should represent one particular distance.
Likewise, it's not my job to tell you not to think of print, so
to speak. But we both have to exchange all relevant data, and we
have to agree on element types and their attributes to represent
data we both need. This is about DTDs and the like, not about
using XML or not. Going from XML to ASN.1 or some format based
on Lisp list doesn't add much difference. We still both have to
know what an item means. Tags are good for helping with this because
they add information about items. Qualified notation so to speak.


> But, lack of readability is not in the ugly </> brackets. Tabulated data
> are readable because they are tabulated.

This is the *View* in MVC, XML is about *data*. So there is no point in
talking about final looks, it is important to know how data will have
to be seen. For example, can you debug datastreams using the simplest
tools? Think of a log file of a concurrent application, processing data
from several heterogenous input sources on the net.


> That is: the names, the types and
> units are *factored* out to the table header, which allows the reader to
> concentrate on the *values*. Thus a table looks as:
> 
> Distance [km]   Temperature  [°C]  ...
> 3.15                29.0     ...
> 2.10                14.4     ...
> 
> This is readable.

This is irrelevant in data exchange. This is print.


> To make difference more visible, consider bitmaps stored XML format. Would
> you be able to recognize a person's face in it?

You do know about NOTATION?
I think it is very hard to find someone suggesting that we should recode
bitmap graphics formats as pixel tags.