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

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

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).

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

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

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?)

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

> 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.