Re: Howto read line from a stream

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

On Thu, 04 Jun 2009 14:14:33 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Thu, 04 Jun 2009 11:41:38 +0200, Georg Bauhaus wrote:
>> 
>>> Dmitry A. Kazakov schrieb:
>>>
>>>> The point is, either the configuration is trivial and you don't need any,
>>>> or else it is non-trivial and then a representation of it as a tree does
>>>> not work.
>>> What would be the reason that trees don't work?
>> 
>> Because non-trivial configuration cannot be reasonably represented by a
>> tree. BTW, Ada program as a configuration for some processor. Why do we use
>> Ada instead of XML?
> 
> *We* use Ada instead of XML, but *we* are the front end in program
> production, wheras an Ada compiler's middleware does *not* use Ada
> as a data representation format.

You mean object, library and executable files?

> To the best of my knowledge,
> it uses a format that works well with compilers: lists or trees!
> XML uses graphs BTW.

So, down with ELF let it be XML!?

>>> I notice that alternative formats have tree structure, such as
>>>
>>> Name.Space.This = 123
>>> Name.Space.That = foo
>>> Another.Thing = bar
> 
>> What about a constraint that Name.Space.This cannot be 123 when
>> Another.Thing is not bar?
> 
> I was referring to XML editting customized to leading to consistent
> and only to consistent configurations.

I don't know what "customized XML editing" is. But since it is obviously
not XML, then I don't see how XML helps the purpose of "customization" and
"editing" of itself. A trivial constraint like above cannot be described in
XML. What else need to be said?

>>>> XML is rooted in dark ages of computing,
>>> The dark ages of configuration are not over, and they will
>>> not be over as long as we are here;  remember the
>>> protocols being written in quality C?  ;-)
>> 
>> At least they were properly documented
> 
> Every proper XML grammar is documented.  In addition, there
> are standard ways of documenting the grammar.

Sorry, but XML grammar is an equivalent to, say, in a byte-oriented stream
protocol, to the sentence "the stream consists of bytes." What a lavish
piece of documentation!

Look, I don't need any grammars in a reasonable designed protocol.

>> (The
>> configuration of a device that yields 8 values is 993 lines long.)
> 
> I don't know how a ratio of 993:8 is representative of the
> technical properties of XML's grammars.  It might be
> representative of get-the-job-out-the-door management
> strategies.

It shows where it goes.

>>> Just *provide* values.  Valid values.  XML validation
>>> is a start, and can be performed anywhere.
>> 
>> XML validation does not validate the values. It validates *itself*.
> 
> Self-validation is not sensible.  How could it.  XML validation
> performs language defined checks.  Nothing more, nothing less.

Great. This is the reason why I should take this language? Because there
exist a validator? I am impressed!

> XML  can be used in integration.  When some input in whatever
> format is lifted over some wall (middleware), you need programs
> that deal with the delivery.  Proper packaging helps with
> the transport.

I don't see how XML helps me to deal with "whatever format" of an input.
Say I have a temperature sensor connected via a CAN bus (... encoding
description follows...). What exactly can XML do with that?

>>> Here in the chain XML can add value to some technical
>>> production process.
>> 
>> I don't see how XML can add a value to the process without knowing how the
>> process functions and how to influence the process. XML is a "Ding an
>> sich", it has no technical purpose.
> 
> XML has rules.  It does not magically provide the rules of
> a specific technical process.

What is the purpose of XML as a language here. Can you point out what does
XML describe except than its own gadgets?

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