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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.74.40 with SMTP id q8mr2914889pav.19.1345641154879; Wed, 22 Aug 2012 06:12:34 -0700 (PDT) Received: by 10.180.24.202 with SMTP id w10mr433757wif.0.1345641154488; Wed, 22 Aug 2012 06:12:34 -0700 (PDT) Path: a5ni2355pbv.0!nntp.google.com!news2.google.com!yt1no38881566wib.1!news-out.google.com!q11ni259045932wiw.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 22 Aug 2012 15:12:41 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502cd701$0$6568$9b4e6d93@newsspool3.arcor-online.net> <502d3c68$0$6572$9b4e6d93@newsspool3.arcor-online.net> <502e9039$0$6557$9b4e6d93@newsspool4.arcor-online.net> <40tmogy4d1b5.1kc2gm8qfrkdu.dlg@40tude.net> <503240ed$0$6569$9b4e6d93@newsspool3.arcor-online.net> <50326457$0$6576$9b4e6d93@newsspool3.arcor-online.net> <1qril0ny3eczr$.1vlhpbrjyyb8k.dlg@40tude.net> <503375ac$0$6565$9b4e6d93@newsspool3.arcor-online.net> <1vglgit7vnu4l$.2ytljabrhk2.dlg@40tude.net> <5033986c$0$6573$9b4e6d93@newsspool3.arcor-online.net> <62h5nifarvom.1myeqdyevhefq.dlg@40tude.net> <5033b4d8$0$6571$9b4e6d93@newsspool3.arcor-online.net> <5033ff28$0$6185$ba4acef3@reader.news.orange.fr> In-Reply-To: Message-ID: <5034dac1$0$6579$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 22 Aug 2012 15:12:33 CEST NNTP-Posting-Host: 7d653f5d.newsspool3.arcor-online.net X-Trace: DXC=dn8[]iNV@REWDmlTRbh@=IMcF=Q^Z^V3H4Fo<]lROoRA8kFjeYMIEOnc\616M64>JLh>_cHTX3jMCHLK`OEf=bN X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-08-22T15:12:33+02:00 List-Id: On 22.08.12 09:32, Dmitry A. Kazakov wrote: > On Tue, 21 Aug 2012 23:35:35 +0200, Pascal Obry wrote: > >> Dmitry, >> >>> The problem of transformation XML documents does not exist. I don't see why >>> data exchange needs that. I don't see why any transformations would be >>> necessary between systems. >> >> You don't see why because you seem to try hard to deny XML any benefit. > > It is not a hard try. Yes, I have an opinion on XML because in my job > (automation systems and embedded) XML became a real plague. I asked others > to put up a practical case where XML might be useful, technically useful, > rather than per popularity vote or legacy. Nobody proposed any. > >> Exchanging structured data is an important point. > > It is an important problem, yes, but XML is poor for that. XML > > 1. is extremely inefficient As always, the question is inefficient for what and for whom. As has been repeated a few times now, there are systems where many would agree that there is no point in using XML or even CSV or something. For yet another example of a practical case in favor of XML, consider a program that needs to retrieve information. A set of sources is external. The program needs to input (a) Microsoft Excel files produced by different people using different versions of the software. (b) PDF files (c) plain text files (d) HTML files (e) etc. The program may not be able to change its sources, as the market may or may not exert influence on the producers of the sources, since they may or may not see economic advantage in switching from sending Excel files to XML documents that use the tagging vocabulary of some industry standard. In a multicompany project the situation might be better because parties may agree to use some common "carrier format" such as XML, or something completely different. This agreement still lets all companies live behind the walls they prefer. > 2. fails to capture the structure (e.g. recursive, interlinked structures) ? > 3. lacks even basic data types (everything is string, not even weakly > typed) ? > 4. lacks any means to describe the semantics (e.g. no ADT), Yes, as this capability was not intended for XML proper. However, if you use something like (like!) WSDL, there is an unambiguous way to transform an ADT into the preferred programming language. > 5. incapable to validate data (because of 4) OK, "XML validation" /= "type checking of a compiler". > 6. requires complex, resource consuming, vulnerable infrastructure like > parsers Yes, there are cases where such parsers are needed, and even more of such things. For example, if you run Google. > 7. is not redundant and at the same time absolutely permissive (requires > complex validation of itself) Another set of unqualified word ({"redundant", ... }) >> Before XML we were >> using many format and we had to write parsers for all those formats in >> every languages. Now with XML (and the corresponding xsd, or wsdl) it is >> possible to parse (and *validate*) any data set coming from any >> applications. > > And it is still so with XML, because XML considered for data exchange is > not of the application level. You don't have to write parser infrastructure when you can use XML. > It is just a very ugly What does "ugly" mean, technically? > and unsafe Another claim. XML may have been called robust (in that the brackets are named, e.g., not overloaded). Has it ever been called safe? > The application level is still to > develop and XML is no relief, it just complicates things. A problem that XML-based setups solve is when they greatly simplify the combinatorial explosion of some ad-hoc variety of mutually semi-compatible ways of exchanging data. Turning data into application level objects is easier, standards-driven, and more regular, in the same sense that any other standard way of exchanging data would achieve this.