From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,865c3d125a8dbc3b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!xlned.com!feeder3.xlned.com!news2.euro.net!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!195.14.215.230.MISMATCH!news.netcologne.de!newsfeed-hp2.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Howto read line from a stream Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <83317a97-dae5-4c84-a1ac-88a87833cf3f@q14g2000vbn.googlegroups.com> <1a90e055-44a3-4d00-b4cd-64798c731a55@e24g2000vbe.googlegroups.com> <709e8a12-f967-43db-b76b-4852cf1db08b@v4g2000vba.googlegroups.com> <196d124vj6gin.16zf5y40t9tr$.dlg@40tude.net> <4a26d249$0$31865$9b4e6d93@newsspool3.arcor-online.net> <4a26f4a3$0$32674$9b4e6d93@newsspool2.arcor-online.net> <1x2tgzxiay4t3$.rvhjms1ggu3h.dlg@40tude.net> <4a2796d2$0$30234$9b4e6d93@newsspool1.arcor-online.net> <1unigz9o798hk$.y1vxsdvq2uwg.dlg@40tude.net> <4a27baa9$0$32663$9b4e6d93@newsspool2.arcor-online.net> Date: Thu, 4 Jun 2009 16:54:07 +0200 Message-ID: <1pacymn6hofpx.1huwns88qzd5d.dlg@40tude.net> NNTP-Posting-Date: 04 Jun 2009 16:54:08 CEST NNTP-Posting-Host: c3797240.newsspool1.arcor-online.net X-Trace: DXC=GJdL]ffYR@7]E=H1Q9`787ic==]BZ:af>4Fo<]lROoR1^YC2XCjHcb9<`c65>C[B[kg2kPG64G?A:`5 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:6248 Date: 2009-06-04T16:54:08+02:00 List-Id: 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