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

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

On 20.08.12 21:28, Dmitry A. Kazakov wrote:

>> Related Example that has been part of this discussion,
>> and concern compiler configuration files:
> 
> We have an excellent example how unmanageable Visual Studio became when MS
> switched to XML.

1) For a reason, I have carefully avoided to say "XML".  I have not
given syntax, but I have described a meaningful process involving
different consumers of text documents (configuration files), and have
described a need to transform/adapt a set of specific configuration
instructions for each of the different compilers.

2) But I did explain that "obfuscating companies" like Microsoft are
very good at leveraging misuse of XML (or anything, at that)
for commercial gain, predictably.
The hint given was the 1:1 mapping of .doc to .docx.

Orienting one's arguments along misuses of XML (or anything, for
that matter) like the above has a second order effect on discussions,
a logic that helps turn smart people into irrational anti-XML
instruments:

COMMANDMENT: Microsoft products must *never* have any feature that allows
third parties to do anything not payed to, and controlled by,
Microsoft.

OPPOSING TREND: Customers and administrations ask for more transparency
and control of their own data/documents, produced and stored using
Microsoft products. They try to make XML stand for this.

CONSEQUENCE: Microsoft must produce XML in such a way that (a)
payments to Microsoft are unaffected and (b) so that no third party
gains control.

This consequence is not one attributable to the definition of XML
(or any other way to express the same, for that matter).


> As a hint observe
> that configuration is no way hierarchical,

Hierarchy of configuration or not is totally irrelevant, it may
well be a list of pairs, or simply mentions of configuration items.
Even though the example I have given involves project management and
subordinate teams show hierarchy, it does not matter.
To the hierarchy, the *same* non-hierarchical *intent* is to be
conveyed in some meaningful form or other, calling for
transformation/adaptation of the higher level intent.
So again, non-hierarchy of configuration data is beside the point.

> That it is non-trivial implies that the
> configuration has a *semantics* far beyond dumb string to string mapping
> which is all so-called XML "language" can offer.

Any language that can express "switch to Integration/Testing
this afternoon!" for each of the different compilers will do.
The result will be a suitably transformed/adapted expression
that uses the respective compiler's dumb configuration syntax.

> But you forgot that you once called XML documentation.

(Please, show me where I said documentation. I remember to have
said "data document".)

> It became a language
> by now?

I did not say language either.  I'd rather not use an unqualified
word such as "language". I might say "markup language", implying that
documents become meaningful via ubiquitously implementable
Transformation programs, for example.

Situation now:
Each compiler uses an idiolect for expressing "optimize some".
One cannot use Janus/Ada directives for controlling ObjectAda,
or GNAT, or Visual C++.

Situation then:
Each compiler continues to use an idiolect for expressing
"optimize some", but there exist programs per compiler that allow
management to express "optimize some" so that it is understood
by each of the compilers.

It so happens that these transformation programs need not use, but
can use the combination of ubiquitously available XML and XSLT.