Re: Data table text I/O package?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 23 Jun 2005 00:24:30 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> But for data exchange there are better techniques than XML.
> 
> Such as ...?

Take any middleware available.

>> Then you cannot talk about numbers transferred. You said "3.15" is a text.
>> So let it be a text. "3.1 5" is also a text, as valid as "3.15" [at this
>> level of abstraction.]
> 
> How is a number transfered from one human to another?

As a description of some [usually trivial] problem. The solution of that 
problem conveys the number. Most people are very bad in memorizing raw 
numbers or even in recognizing them from an acoustic stream.

> How do you explain the number three to a person who
> cannot see?

The number second to two. (:-))

>> [sending two literals instead of one]
>> The true value is always within the bounds. There is still a
>> problem, but a much lesser one.
> 
> I don't agree because you are actually introducing two intervals.

No, it is still one interval that contains the true number. This is the way 
floating-point arithmetic functions. The result of a+b is c, such that 
[c'Pred, c'Succ] contains the exact result. [*] The problem is that 'Pred 
and 'Succ are of course machine dependent. So when you send c you should 
also convey the range. Depending on that the receiver should chose an 
appropriate internal representation for c, which might require a "true" 
interval.

> And mine might be different from yours anyway. So why not use "3.15"
> as per the needs of the application?

It is no problem. But then in your XML format it should rather be:

<model="float", dimension="km", digits="4", value="3.15">

This might look close to Ada's ideology, but I would rather say it does 
not. It smells much of structural types equivalence, I don't like it. What 
if the application expects a fixed point number? Would you convert? It is 
too slippery...

BTW, I'm not arguing against the idea of using type descriptions in 
protocols. It is a great idea. I think Ada will definitely confront this 
issue some day, because presently Ada is completely unable to handle it. 
But XML isn't a right answer here.

>> Relevant errors are only ones made by humans.
> 
> Ahh, no. Think of the last time you have been watching satellite
> TV with a strong cloud in the way. Where is your nice data stream...
> (No I'm not suggesting XML here, of course, but satellites aren't
> just used for MPEG streams. They can transmit XML data too.)

Never use UDP, and you'll have no problems with that! (:-)) But seriously, 
do you really want to collapse all OSI levels into one big mess and make an 
application responsible for error correction?

>> [I don't talk about writing, because to write
>> in XML is beyond anybody's capability anyway.]
> 
> I suggest you have a look at oXygen or nXML mode for Emacs,
> or PSGML mode for Emacs. (Serna is also nice,
> though it is, uhm, stabilizing.)
> They all provide functions similar to a good programmer's IDE,
> analysing source text to help you with typing, inserting
> completions automatically, running the validator in the
> background etc.

That's the point, to write something as a table, you need nothing more 
elaborated than a notepad editor...

Actually I enjoy XML in postings. It is an excellent spam flag. Any post 
which isn't plain text immediately goes into the recycle bin. (:-))

>> Humans are unbeatable in pattern recognition. This is whole idea behind
>> tables. Tab stops and lines are very easy patterns to detect and any error
>> becomes immediately visible long before inspecting the table contents.
> 
> Right. So next time someone sends you an HTML table full of data,
> use this for a start, to get a nice plain text table. (It's verbose,
> I know :)
[...]

And why this nightmare cannot be written in Ada?

----------
* Depending on how the machine rounds a narrower interval can be used.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de