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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!news3.google.com!feeder.news-service.com!newsfeed.freenet.de!news.tu-darmstadt.de!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 04 Jun 2009 18:33:22 +0200 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Howto read line from a stream 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> In-Reply-To: <1pacymn6hofpx.1huwns88qzd5d.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4a27f752$0$30225$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 04 Jun 2009 18:33:22 CEST NNTP-Posting-Host: 772d23f2.newsspool1.arcor-online.net X-Trace: DXC=LL8K9ERm?OR5TOT9_N5iERU;9OJDO8_SKVNSZ1n^B98iZGlm:>?KbaQ^ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:6258 Date: 2009-06-04T18:33:22+02:00 List-Id: 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. >> 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!? ELF refers to output of a compiler, not its middle end... >>>> 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. First, the basic structure of a configuration data item follows from the productions of your XML grammar. XML editing equipment (including: ubuquituous office programs) can be programmed to include additional type checks, constraint checks, etc. They do not stop human checks in addition to the XML syntax checks and validity checks that are for freed. > 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. The additional logic goes into (a) the customization (b) the heads of the config makers and (c) the input checking routines of your middleware. >>>>> 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. NOTE: I should again emphasize that the final configuration data is the result of a programmatical transformation of XML documents. XML was not intended for fully controlled, maximmaly efficient internal data streams. > Look, I don't need any grammars in a reasonable designed protocol. Your protocols do not even place any order on items? There is not even a regular structure in a reasonably designed protocol? >>>> 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. Consider this: CUSTOMER: Here is a Word 2007 document describing the system configuration in nice, if somewhat ambigous prose, we are open to discussion. We cannot predict the order of items, BTW. versus CUSTOMER: Here is an XML document that follows the grammar you have sent us. The root element is ... and we will leave it up to you to fill in element ... with what you see fit. For example, it might be "this end"s job to set up a system such that "the other end" can supply a great-product-archive, to be run. All required software is installed then, because that is what was requested in the XML description of the system, and the description was programmatically connected to the systems software configuration machinery. (parsed, type checked, ...) >> 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? I had thought of this: --> XML description of system setup --> input checking --> transformed description of system setup --> download system settings Another: --> XML description of stock exchange items (excl. RT prices) --> input checking --> transformed description of stock exchange items --> stored in internal data base The idea is that someone from the other side of the middleware border never needs to look at the transformed description. The latter is internal. They also need not expose their internal data structures. Instead, they produce a data stream. The stream is a valid XML instance of some agreed upon XML grammar. > Can you point out what does > XML describe except than its own gadgets? XML documents use the vocabulary that you define in a grammar.