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.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24, 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,UTF8 Received: by 10.66.72.165 with SMTP id e5mr794276pav.4.1345227733868; Fri, 17 Aug 2012 11:22:13 -0700 (PDT) Path: p10ni89894547pbh.1!nntp.google.com!border1.nntp.dca.giganews.com!border1.nntp.ams.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!eweka.nl!hq-usenetpeers.eweka.nl!proxad.net!feeder2-2.proxad.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 16 Aug 2012 20:31:20 +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> <50677fa2-7f82-4ccc-8c56-161bf67fefe1@googlegroups.com> <44bb5c96-a158-41c1-8e7d-ae83b2c0aca1@googlegroups.com> <1mchat48i3fos.1ksbz02nuzf5f$.dlg@40tude.net> <502b832f$0$6579$9b4e6d93@newsspool3.arcor-online.net> <502bc4df$0$6574$9b4e6d93@newsspool3.arcor-online.net> <502bd3e6$0$6574$9b4e6d93@newsspool3.arcor-online.net> <17qgsq5y7or0v.16z18fmcew1lt$.dlg@40tude.net> <502c149e$0$6579$9b4e6d93@newsspool3.arcor-online.net> <502cd701$0$6568$9b4e6d93@newsspool3.arcor-online.net> In-Reply-To: Message-ID: <502d3c68$0$6572$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 16 Aug 2012 20:31:04 CEST NNTP-Posting-Host: f0d64282.newsspool3.arcor-online.net X-Trace: DXC=lF5DYV@C2h>LNKYb?b>076McF=Q^Z^V384Fo<]lROoR18kF:Lh>_cHTX3j=HFYEY On 16.08.12 14:56, Dmitry A. Kazakov wrote: > On Thu, 16 Aug 2012 13:18:28 +0200, Georg Bauhaus wrote: > >> On 16.08.12 09:30, Dmitry A. Kazakov wrote: >>> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote: >>> >>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote: >>> >>>>> And >>>>> how these false premises could justify any application of XML even if per >>>>> some miracle they happened true? >>>> >>>> The point of the exercise is to make apparent the variables >>>> that help decide when, and when not, to use XML, >>> >>> List of the variables, please. >> >> They were given in the text, and even indicated syntactically. > > What you listed was unrelated to the issue. It was related to the issue from which you keep dragging the discussion away: data formats. I'll note in advance that your train might have stopped, but you have missed ours, which has a different destination. (I will give an example about distributed production of software, if requested.) >> I had hoped that someone with a PhD in mathematics would find >> this a fair read, even when the subject matter might look strange >> at first sight. > > If has nothing to do with strangeness. There is a standard procedure of > evaluating such things in engineering. You should: > > 1. state the problem Heterogeneous sources of data. (E.g. Teletext there + XML there) > 2. present relevant criteria to evaluate a solution Situational, given, as mentioned, e.g. integration of data. > 3. present competing solutions > 1 (proving them solving the problem) Given. (E.g., what has been done a few times: move from Teletext to CSV to XML) > 4. evaluate these solutions against the criteria Ergo. > 5. make choice based on the ranking obtained Situational, e.g. as above. >>> How is the choice XML vs., say, CANopen motivated by specifically >>> homogeneity? >> >> By a homogeneity that I have outlined when talking about measures >> of sameness, in the context of the situation, which is full of motives. > > See above and go from 1 though to 5. I did. Again. >>> What is homogenous by XML, which is not by other protocols, and conversely? >> >> XML is not a protocol, but that's an aside. > > If you say that XML is not a protocol, then the train stops right here. OK. Your train stops. > We > were talking about the network of car devices. I was not talking about protocols. Please re-read the posting Message-ID: <502b832f$0$6579$9b4e6d93@newsspool3.arcor-online.net> which started this sub-discussion. See in particular how does *not* mention protocols at all. > I don't care what else XML > might be, Your choice. > because being not a protocol automatically disqualifies it here > and now. Yes, like I said, most engineers would heartily agree. See [+Almost all] in a previous posting. > You seem to imply that fuzzy logic (in its scientific meaning) acts > differently from crisp logic by allowing any sorts of non sequitur. No. There is a point when switching data formats to something general like XML is considered by some programming projects. This point is found in [0, 1] ⊂ R. A Yes (1) or No (0) is really the consequence of a final preference and this preference's value need not be 0 or 1. >> and doing so stipulates >> that the persons involved can produce weights that work. >> Actually, I am sure they have done so many times. > > In that case you should summarize/cite their results. You brought the issue > of "homogeneity" up as a criterion of choice in favor of XML. Did you? On the contrary, I said that XML, if chosen, is a way of tackling heterogeneity of data. (E.g., moving away from Teletext to XML sent over HTTP.) With Teletext, I have had to find means of inspecting a mostly unknown stream of video text data. Its bits and pieces were partially documented. This was enough to write a crude scanner. With XML, I can at just read the stuff and see some familiar vocabulary being used. Done. > So I am merely asking for: > > A) the definition of, because yours is absolutely non-standard Homogeneity is a pre-network term and means, as mentioned many times, of the same kind. (όμοιοϛ and γένοϛ are the parts of the word, TTBOMK.) Where "kind" is from a multidimensional space of motivating factors. > B) methodic of its evaluation Multivariate analysis of those variables of the programming situation that lead to a decision about data formats. > C) signs of importance for the considered case (car electronics network) I said, after establishing background, which see, that "a network connecting the electrical devices of a car does not counts as heterogeneous." A statement valid against the background only. And that, therefore, one of the reasons for choosing XML does *not* apply. > D) comparison to competing solutions See above, and everything said so far. > The joke an unknown author made about XML worked because it mocked the > process 1-5: > > "XML combines the efficiency of text files with the readability of binary > files" It works only for those people who would declare the truth of false statements about XML, mistaking the meanings of nouns (deliberately?): 1. that readability means more than "can be read, technically, with plain text tools", (it means little more than that) 2. that XML had been developed to be more efficient than other data formats. (It has not.) > You find here all components: the competing solutions, the criteria, their > evaluation all leading to the hilarious choice of the worst possible > solution, which also makes a deeper point that there actually exists no I really have to say that from False follows... There is a huge amount of technical problems with heterogeneous data, but people solving these problems do not submit to your exclusive definition of "technical". Integration of information of different kinds of data documents, such as Teletext and HTML pages, *is* a technical issue. Granted, it is not just one of electronics. The major contenders in the office market leverage the data format problem for economic purposes, worsening the situation for future generations. And damaging the reputation of XML. To some extent they have succeeded in undermining the intents of using XML. For example, one of the contenders simply provides an isomorphic mapping of .doc to .docx, basically. That's devilish, and cynic, but silences those who had really asked for a way to make documents readable (technically readable) without running the single program capable of reading .doc and .docx properly.