Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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.