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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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.88.41 with SMTP id bd9mr892770pab.47.1345237865690; Fri, 17 Aug 2012 14:11:05 -0700 (PDT) Path: p10ni90884728pbh.1!nntp.google.com!border1.nntp.dca.giganews.com!backlog1.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!feed.xsnews.nl!border-1.ams.xsnews.nl!plix.pl!newsfeed2.plix.pl!wsisiz.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!newsfeed.icp.pl!news.icpnet.pl!newsfeed.pionier.net.pl!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Wed, 15 Aug 2012 10:18:42 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net> <502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50677fa2-7f82-4ccc-8c56-161bf67fefe1@googlegroups.com> <44bb5c96-a158-41c1-8e7d-ae83b2c0aca1@googlegroups.com> <502a6ab7$0$9519$9b4e6d93@newsspool1.arcor-online.net> <6412cd0e-a1b2-4004-a80b-fa445bbbcf00@googlegroups.com> <502b8c45$0$6570$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: 69.20.190.126 Mime-Version: 1.0 X-Trace: posting.google.com 1345053526 16992 127.0.0.1 (15 Aug 2012 17:58:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 15 Aug 2012 17:58:46 +0000 (UTC) In-Reply-To: <502b8c45$0$6570$9b4e6d93@newsspool3.arcor-online.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-Original-Bytes: 9743 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-08-15T10:18:42-07:00 List-Id: On Wednesday, August 15, 2012 5:47:23 AM UTC-6, Georg Bauhaus wrote: > On 14.08.12 22:30, Shark8 wrote: >=20 >=20 >=20 > > the presence/absence of that single [optional, according to the documen= tation, IIRC] attribute caused the whole thing to fail. >=20 >=20 >=20 > You don't remember correctly. > Namespaces used to be controversial, but an Ada-like solution > has been adopted by XML. It was years ago, it might have been due to still being controversial, it m= ay also have have been the Java documentation was wrong, and, yes, I could = have been recalling wrong. >=20 > >> Wow. At least witty commentary compensates for the lack > >> of understanding of the basics of XML. > >=20 >=20 > > What's there to understand when you're evaluating it as a container? > > Take config-files, they're usually much better stored in an INI file. >=20 > Both "usually" and "much better" need facts to back them up. I'm using my own experience as a gauge; it is incorrect to not consider exp= erience as fact. -- True, my perceptions color things, but you simply canno= t say that the experiences didn't happen. > If two heterogeneous systems need to exchange configuration > data, whether or not INI files will work well, or not at all, > or something in between, will depend on the configuration data. Agreed. INI files would be horrible for storing the state of a simulation, = as would most text-based files, also it would not suit data which is hierar= chical like object-serialization (in particular the 'has-a' relation).=20 >=20 > > About the only thing I can really envision XML being appropriate for, a= nd this is likely a stretch, would be serialization of [OOP] objects where= the tag would be either an object or a primitive type, a primitive type be= ing self-closing and having a value attribute where the object-tag would en= close tags corresponding to its own fields (either object-tags or primitive= -tags themselves)... of course that pretty much just described the text-for= mat DFM files Delphi uses (which I like more because of their readability a= nd philosophy of "if it's the default, don't save it" which is sadly missin= g from a lot of config/state/obj serializations). >=20 > While XML is being used for serialization between heterogeneous systems, > I guess that's probably because programmers have tools for turning > internal data objects into serialized form for external use, apparently > freeing them from thinking, and apparently saving some work at some point= . I would agree; though there are problems about not-thinking in [my experien= ce] in the field (granted, I was doing web-site backend stuff). > Nevertheless, this frees the other end from having to deal with foreign > internals. Which is not a bad thing; good tools allow the user to concentrate on the j= ob rather than on particular irrelevancies. I don't like working on *nix sy= stems precisely because of this problem: the irrelevancies get in the way m= uch too often. (File-permissions is a good example; the one and ONLY time I= 've had a file-permission issue get in the way of working on a Windows-syst= em was under a *nix subsystem port [Ming].) >=20 > > Though if you meant the emphasis of readability was not the same I woul= d agree: XML is skewed toward the machine away from the human, at least in = use. >=20 > Yes I meant "technically possible to read without additional > tools, everywhere". >=20 > >> Readable in the case of XML > >> means something more plain, something more technical: > >> that anyone can read XML documents using a pair of > >> eyes and a program like "more". No knowledge of any other > >> language is required, no knowledge of bit patterns is required. > >=20 > > And that's where XML often fails. Sure you "can*, as in might be able t= o, operate an XML file with a plain-text viewer -- but again, once there's = any real-life complexity, then the relevant information [the signal] is qui= ckly lost in a sea of noise. >=20 >=20 > Again, these claims would profit from facts to back them up: > Here is one. The real-life situation is exchange of data. > You need to debug one such exchange. >=20 > If (1) you get to see a stream of bits, what do they mean, > where is the error? >=20 > If (2) you get to see a structured text, what do the words mean, > where is the error? As we're talking of XML in particular, I should think the second is the onl= y class we really need to worry about. (Failure on the first would indicate= a failure on transport or decoding-to-text; i.e. exceptional circumstance.= ) >=20 > > This is why INI files beat XML as config files: there is so little nois= e built into the format of "sections containing key/value pairs." >=20 > In this case, your ini files would be trivial, and your XML files would > be a product of thoughtlessness. Both are related to quality of work and = data, > they do not imply properties inherent to either format, >=20 > as can be seen by actually comparing equals in either format: >=20 > [gnorplx] > foo =3D 42 > thrndx =3D 1m >=20 > foo=3D"42" > thrndx=3D"1m" /> This is trivial, but indicates a problem about the XML format: it assumes e= verything to be a tree. Element gnorplx here is representing an entire sect= ion of the given INI -- the key-value pairs though should be leaves themsel= ves of the section-object. INI files have a different problem: they assume things to be non-hierarchic= al, key-value pairs divided into sections. >=20 > Big deal? -- If the XML file should look even more like an INI > file, if your eyes sting when they see angle brackets in plain > text, then with a suitable SGML declaration for a config document, > the aesthetically offended programmer can write >=20 > [gnorplx] > foo =3D 42 > thrndx =3D 1m >=20 > in SGML. Er, that's a pretty bad example. It's like saying you CAN serialize objects= into INI-format w/o considering the consequences of that decision. Indeed,= that's been my main underlying point here: XML carries with it implicit co= sts, it is *not* the best solution for every problem. {It is my opinion tha= t there are very few problems that it actually does solve nicely: object-se= rialization is one where I think it is adequate. (Though, as CombatXXI show= s, it may be unsuitable for that due to constraints.)} >=20 > >> Nor is XML intended for internal data formats. > >=20 > > That doesn't stop people from doing so; I've seen it in web-programs an= d desktop apps (a lot more now that MS-Office's *.???x format is widespread= ). >=20 > Nor does the attribution of simplicity to INI, CSV, etc. > stop people from storing a ton of brittle implications > in these files, sometimes pointing out efficiency. Ive not seen "efficiency" *ever* cited as a choice's decision-factor for ei= ther CSV or INI -- I have, however, seen "portability" and "simplicity" cit= ed. {Especially in CSV vs Excel's binary decoding for importing data into a= system.} >=20 > My favorite example: CSV without record separators > (hint: use counting). Yeah, I haven't encountered CSV w/o record separation... I have encountered= the other-way that makes record separators irrelevant though: data across = multiple rows for a single record -- Which is why people who use spreadshee= ts when they should be using DBs ought to be beaten. {I say that having had= some little experience on the Army's admin side: what a nightmare of using= the wrong tools for the job.}