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.204.10.88 with SMTP id o24mr79512bko.0.1345708610519; Thu, 23 Aug 2012 00:56:50 -0700 (PDT) Received: by 10.180.96.42 with SMTP id dp10mr835174wib.2.1345708610066; Thu, 23 Aug 2012 00:56:50 -0700 (PDT) Path: m12ni126129bkm.0!nntp.google.com!news1.google.com!7no38329821wig.0!news-out.google.com!q11ni272005109wiw.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 23 Aug 2012 09:56:49 +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> <502040c0$0$9510$9b4e6d93@newsspool1.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> <502c08f9$0$6573$9b4e6d93@newsspool3.arcor-online.net> <5034d558$0$6581$9b4e6d93@newsspool3.arcor-online.net> In-Reply-To: Message-ID: <5035e241$0$6584$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 23 Aug 2012 09:56:49 CEST NNTP-Posting-Host: 4913d61a.newsspool3.arcor-online.net X-Trace: DXC=c_D\>?maRHO=8m7nZkdN^@McF=Q^Z^V3H4Fo<]lROoRA8kFejVH]6BU]5=I;nGRVkeh>VBK9A X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-08-23T09:56:49+02:00 List-Id: On 22.08.12 23:55, Randy Brukardt wrote: >> Zeroth, a setup that sends plain HTML does not meet the usual >> requirements for presenting information to end users (excluding >> engineers who would be happy just seeing some text). > > Baloney. Measured by the amount of money flowing into design of ever new packaging for the umpteenth time, not baloney. As I said, engineers might have some exclusive views... >> First, HTML is inflexible in that you cannot choose a natural >> vocabulary for car information. > > Who gives a f*** about a "vocabulary"? Ada software engineers are asked to use a domain specific vocabulary in their program (which here is about car status). The status web server engineers can be asked the same when producing tagged text they then delegate to the web guys who write the XSLT to be run in the browser. I think Vasiliy already indicated how. And yes, it has to come from somewhere. Defining the vocabulary and defining the grammar is another opportunity for engineers to make their education bear fruit. Can't do this using HTML. Granted, I said browser, not app, although today many customers do not distinguish them. But even then, HTML may be produced from the domain specific XML document by referring to an XSLT in an XML processing instruction. (And the transformation program may be cached in the device, unlike the car's status). One consequence is separation of concerns, since status engineers will not have to change output procedures if rendering is to be changed. Additionally, the CSS may well be delivered by the company web servers, not the car's. Yes, there are limits to what a browser can do, largely because our software industry has invented the fully qualified host name as the principal item of security. The point why I am saying all this in an Ada context is that I can't help but think that many Ada programmers are stopping to think the Ada way (should that exist) once the subject matter changes just a little, for example, to XML syntax. (General purpose language, large systems, subsystems, packages, decoupling, name equivalence of types ...) > Apparently, you have completely forgotten the original purpose of HTML. That > is, the browser, not the sender, decides on the format. I always agreed with the original intent of HTML. The market has not agreed. Not at all. Sometimes even within reason: What kind of web pages need to have section headings? So still, HTML does not allow for the separation of content and format as well as XML. Not surprisingly at that, since HTML was not meant to be as general purpose as SGML. So I'll happily embrace the idea that the product should be an app if this helps clears the path for better software engineering.