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

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

On 22.08.12 09:32, Dmitry A. Kazakov wrote:
> On Tue, 21 Aug 2012 23:35:35 +0200, Pascal Obry wrote:
> 
>> Dmitry,
>>
>>> The problem of transformation XML documents does not exist. I don't see why
>>> data exchange needs that. I don't see why any transformations would be
>>> necessary between systems.
>>
>> You don't see why because you seem to try hard to deny XML any benefit.
> 
> It is not a hard try. Yes, I have an opinion on XML because in my job
> (automation systems and embedded) XML became a real plague. I asked others
> to put up a practical case where XML might be useful, technically useful,
> rather than per popularity vote or legacy. Nobody proposed any.
> 
>> Exchanging structured data is an important point.
> 
> It is an important problem, yes, but XML is poor for that. XML
> 
> 1. is extremely inefficient

As always, the question is inefficient for what and for whom.

As has been repeated a few times now, there are systems where many
would agree that there is no point in using XML or even CSV or something.

For yet another example of a practical case in favor of XML,
consider a program that needs to retrieve information. A set
of sources is external. The program needs to input

(a) Microsoft Excel files produced by different people
    using different versions of the software.
(b) PDF files
(c) plain text files
(d) HTML files
(e) etc.

The program may not be able to change its sources, as the market may
or may not exert influence on the producers of the sources, since they
may or may not see economic advantage in switching from sending
Excel files to XML documents that use the tagging vocabulary of
some industry standard.

In a multicompany project the situation might be better because
parties may agree to use some common "carrier format" such as XML,
or something completely different. This agreement still lets all
companies live behind the walls they prefer.


> 2. fails to capture the structure (e.g. recursive, interlinked structures)

?

> 3. lacks even basic data types (everything is string, not even weakly
> typed)

?

> 4. lacks any means to describe the semantics (e.g. no ADT),

Yes, as this capability was not intended for XML proper. However,
if you use something like (like!) WSDL, there is an unambiguous way
to transform an ADT into the preferred programming language.

> 5. incapable to validate data (because of 4)

OK, "XML validation" /= "type checking of a compiler".


> 6. requires complex, resource consuming, vulnerable infrastructure like
> parsers

Yes, there are cases where such parsers are needed, and even more
of such things. For example, if you run Google.

> 7. is not redundant and at the same time absolutely permissive (requires
> complex validation of itself)

Another set of unqualified word ({"redundant", ... })

>> Before XML we were
>> using many format and we had to write parsers for all those formats in
>> every languages. Now with XML (and the corresponding xsd, or wsdl) it is
>> possible to parse (and *validate*) any data set coming from any
>> applications.
> 
> And it is still so with XML, because XML considered for data exchange is
> not of the application level.

You don't have to write parser infrastructure when you
can use XML.

> It is just a very ugly

What does "ugly" mean, technically?

> and unsafe

Another claim. XML may have been called robust (in that the
brackets are named, e.g., not overloaded). Has it ever been
called safe?


> The application level is still to
> develop and XML is no relief, it just complicates things.

A problem that XML-based setups solve is when they greatly
simplify the combinatorial explosion of some ad-hoc variety
of mutually semi-compatible ways of exchanging data.
Turning data into application level objects is easier,
standards-driven, and more regular, in the same sense that
any other standard way of exchanging data would achieve
this.