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

["Randy Brukardt" <randy@rrsoftware.com>]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:5034d558$0$6581$9b4e6d93@newsspool3.arcor-online.net...
> On 22.08.12 00:46, Randy Brukardt wrote:
>> "Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message
>> news:502c08f9$0$6573$9b4e6d93@newsspool3.arcor-online.net...
>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>>>> And
>>>> how these [unsubstantiated claim] justify any application of XML even 
>>>> if
>>>> per
>>>> some miracle they happened true?
>>>
>>> I'll answer in another post, but here is a business idea
>>> involving cars, XML, and smart phones.
>> ...
>>> Technically, then, have the car have a small web server
>>> (perhaps smaller than AWS), and have the server send an XML
>>> document to the owner's mobile phone. Have that triggered
>>> by web  requests. Add information in caches as necessary.
>>
>> Sure sounds wildly complicated, when all that is needed is to send
>> appropriate HTML pages to the phone's browser.
>
> In real life situations (meaning that layout matters) XML turns
> out to be easier, and much more practical:
>
> 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.

> First, HTML is inflexible in that you cannot choose a natural
> vocabulary for car information.

Who gives a f*** about a "vocabulary"? We're talking about presenting 
information to a browser in a human-readable form. That's the problem *you* 
set up.

> Second, separation of teams: providing car status information
> is very different from presenting car information. There are
> providers, and there are presenters.

Surely the software will be structured that way, but unless you plan to send 
your browser unformatted information and hope that it can do something 
useful with it, you also have to send a presenter along with it. (As I said 
previously, this all changes if you are sending the information to an app 
rather than a browser. But that's NOT the problem you set up.)

> Third, you need to vary output of the server for different kinds
> of recipient devices. For shared cars in particular, and for
> quickly changing devices, too. The necessary flexibility is not
> easily handled if a server is built into a car and emits HTML,
> CSS and Javascript.  Note that the car does not change, so the
> information provided by its web server does not change, but
> the devices do. (Would you want the car's web server to be
> updated every time one of the car's users connects a new,
> different device?)

Apparently, you have completely forgotten the original purpose of HTML. That 
is, the browser, not the sender, decides on the format. Clearly, one has to 
go lightly on the CSS in order for that to work, but it does work and it 
works pretty well. When that's done, the presentation changes to fit the 
browser's properties.

One could try to drop some of the data on very space limited devices, but 
that's usually the wrong way around: there ought to be a way to get more 
details on *all* devices. If you want an at-a-glance display, it can't be so 
small that I have to find reading glasses to see it (which means it has to 
be pretty large, even on my desktop).

Besides, just sending raw XML to a browser will get you very lame output. 
Something has to be presented to the browser in order make that presentation 
look better -- and that has to come from somewhere. And if not the car's 
server, where *is* it going to come from? From the "cloud", that master of 
all buzzwords, the home of instability, completely lose of privacy and 
freedom? Thanks, but no thanks. I don't want the user interface to my car to 
change every time I turn it on! Yet that's what happens in these idiot 
systems (my phone has done that several times in the time I've owned it) --  
I have better things to do than to relearn how to use my own car (or phone) 
every few weeks.

> Choosing XML addresses these issues, since the car's web server
> can be left alone when clients should change.

Again, how can the clients change? Where is that presentation coming from? I 
am not interested in putting my car on the public internet!

>> It might make
>> sense to use XML to send data to an app, but that's clearly the hard way 
>> to
>> do things.
>
> It seems the easiest, even in comparison to HTML, in that---for the
> service in question---everything needed to handle XML is in place,
> including transformation machinery.

If you're building an app, I agree that everything changes. But that's not 
the case I've been talking about, because it was not the case you set up --  
you specifically said *to show in a browser*.

                          Randy.