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!news.astraweb.com!border5.a.newsrouter.astraweb.com!news.tele.dk!news.tele.dk!small.news.tele.dk!bnewspeer01.bru.ops.eu.uu.net!bnewspeer00.bru.ops.eu.uu.net!emea.uu.net!newsfeed.arcor.de!newsspool1.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> <1pacymn6hofpx.1huwns88qzd5d.dlg@40tude.net> <4a27f752$0$30225$9b4e6d93@newsspool1.arcor-online.net> Date: Fri, 5 Jun 2009 11:57:41 +0200 Message-ID: <90snpyscdtyd$.5eqz9lt2354e.dlg@40tude.net> NNTP-Posting-Date: 05 Jun 2009 11:57:41 CEST NNTP-Posting-Host: 7b79bac4.newsspool1.arcor-online.net X-Trace: DXC=0`JNMK[>g?L74okIm;?DS@ic==]BZ:afN4Fo<]lROoRA^YC2XCjHcbIkSWNOGakgBFV6;TM1Y4;I X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:6296 Date: 2009-06-05T11:57:41+02:00 List-Id: On Thu, 04 Jun 2009 18:33:22 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov schrieb: > >>>> 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? > > No, I mean ASTs, parse lists, parse trees, possibly annotated, > that are handed from stage to stage. I see, that was a joke... (:-)) >> A trivial constraint like above cannot be described in >> XML. What else need to be said? > > XML is for MOM etc, not a programmming language, not a > logic language. Yes, I know what XML is not. (:-)) > The additional logic goes into (a) the > customization (b) the heads of the config makers and > (c) the input checking routines of your middleware. So XML does not solve the problem you proposed it as a solution for. >>>>>> 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! > > I don't understand this comment, it sure does not address > Relax NG documentation, for example, or content models. [...] >> Look, I don't need any grammars in a reasonable designed protocol. > > Your protocols do not even place any order on items? Do you call it grammar? OK, in some sense it is. But there is no need to document it. For example, there certainly is a grammar of the text files used for Ada (C, C++ etc) programs. It describes that a character #2 follows a character #1. It is a very impressive grammar... >>>>> 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 validation is a well tested wheel. Available everywhere. > If you need additional logic when reading input from the > uncontrolled outside world, you can build on top of XML > infrastructure. If everything I need must be built on top of XML, I prefer to build it rather on the [solid] ground. >>> 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? > > Uhm, is sensor data what you consider either message oriented middleware > or else configuration data? To put it clear I don't see how XML can describe this so, that a COTS XML compiler (parser) would produce an executable/interpretable code. If I describe sensor in Ada language, I can take a compiler, translate the description (an Ada program) into an executable/interpretable code. Where to buy such XML compiler? What is the target of XML. I know that XML provides an infrastructure. The point is that I don't need it, since it does not solve any concrete problem. The only problems it solves (like validation) are ones inflicted by this infrastructure itself. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de