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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 17 Aug 2012 20:41:10 +0200, Georg Bauhaus wrote:

> On 16.08.12 21:58, Dmitry A. Kazakov wrote:
> 
>>>> 1. state the problem
>>>
>>> Heterogeneous sources of data. (E.g. Teletext there + XML there)
>> 
>> If sources of data is a problem, then the data format cannot be a solution.
> 
> OK, that's a different if.
> 
>> Problems with sources are solved by choosing other sources or other means
>> applied to the sources.
> 
> "Problems with the distance Earth:Mars or problems with the temperature
> on Mars are solved by choosing others planets or other means applied
> to the planets."

Yes, if you wanted to solve these problems, actually. Otherwise, you remind
me our politicians talking about the debt crisis...

> No. Problems with sources are actually solved by the sources becoming
> different from what they were before.

= by changing the source.

>>>> 2. present relevant criteria to evaluate a solution
>>>
>>> Situational, given, as mentioned, e.g. integration of data.
>> 
>> Sources are selected using criteria describing these sources, e.g.
>> relevance, trustworthiness, independence, accuracy, extent, availability,
>> QoS, etc.
>> 
>> [ Criteria of choice are always immanent to the thing in question ]
> 
> The thing in question is a situation.

First it was heterogeneous sources, now it is a situation. Could you state
the problem?

>>>> 3. present competing solutions > 1 (proving them solving the problem)
>>>
>>> Given. (E.g., what has been done a few times: move from Teletext
>>> to CSV to XML)
>> 
>> No.
> 
> Yes. XML can be quite an enhancement when the problem is heterogeneity
> of sources.

No. I repeat, a problem with X is to be solved by doing something with X,
always.

That reminded me the Max Planck's solution:

"A new scientific truth does not triumph by convincing its opponents and
making them see the light, but rather because its opponents eventually die,
and a new generation grows up that is familiar with it."

> This is how people *have* solved problems of integrating
> data.

Data are not integrated. Data are processed. And, as always, you should
explain what does "integration of data" mean, what is the problem with
that, what are the measurable criteria of "integration" and how XML is
better than other "integrators" of data.

>> Sources of data in a car are sensors.
> 
> Yes. BTW, even though there are many types of sensors I'm sure,
> they all are sensors; depending on distance, then, the observer will place
> them on a scale between homogeneous ("Hey, everything is a sensor here!")
> and heterogeneous ("Dude. This one works with gas and heat, but that one
> uses pressure!")

No idea what the above might mean. Sensors of a car use different physical
principles, measure different characteristics of different physical
processes, deploy different materials, are integrated using different
software protocols etc.

>>>> You seem to imply that fuzzy logic (in its scientific meaning) acts
>>>> differently from crisp logic by allowing any sorts of non sequitur.
>>>
>>> No. There is a point when switching data formats to something
>>> general like XML is considered by some programming projects.
>>> This point is found in [0, 1] ⊂ R. A Yes (1) or No (0) is really
>>> the consequence of a final preference and this preference's value
>>> need not be 0 or 1.
>> 
>> It does not make any sense to me, but since it seems irrelevant anyway, be
>> it so.
> 
> It is the important bit.  The situation (let me call it
> "a programmers' situation", because it is observed from the point of view
> of the programmers) is characterized by inputs and outcomes. An outcome
> is a decision, in this case, viz whether or not time should be spent on XML.
> 
> Some inputs are technical:
> - this device has an 8bit wide output port and it spits
> 13+1 octects and then 2, on request. It does nothing else.
> Others are domain specific:
> - "We must have something to send to the publisher. They want..."
> Others are economical:
> - The high speed RDMS style data collection will cost $$$$$$.
> Others are "people driven":
> - Pointy head boss speaking.
> Etc.
> 
> These and other variable characteristics of a programmers' situation
> all create inputs that find more or less appreciation during the
> decision process.
> Then, finally, the pointy head boss says "We shoud do XYZ."
> Consequently, Choice(XYZ) = 1 as the outcome of the situation,
> for everyone,
> even when pointy head boss is not fully convinced. He may
> privately value Choice(XYZ) at somewhere < 1.

Egh, what is the point?

>> What is "heterogeneity of data" and why should it be tackled?
> 
> Data of different kinds, different along several axes as seen
> by the respective "data processors".

Are you talking about datatypes? Yes, there are many. Typed programming
languages rely on the ADT.

XML is supposed to compete in the field of type systems? Seriously?

>> Are you talking about "tackling" documents? What sort of documents? The
>> time diagram of the ignition impulses at the degree angles of the driving
>> shaft? GPS maps of the navigation system? Traffic rules and regulation?
> 
> More generally, if an algorithm needs to find information in "documents"
> emitted from diverse sources, searching requires assigning meaning
> to messages contained therein.

No. Document search does not require assigning meaning nor does it require
messages. What documents? How organized? Where stored? What has XML to do
with all that?

>>> Its bits and pieces were partially documented. This was enough
>>> to write a crude scanner. With XML, I can at just read
>>> the stuff and see some familiar vocabulary being used. Done.
>> 
>> Nothing is done.
> 
> Compare
> 
> ....<D5><E9><F6>B.....
> 
> to
> 
> ....<indicator-of-meaning>123.4567</indicator-of-meaning>....

By which measure?

The first uses the letter 'a' 0 times. The second does it 4 times. Is the
objective to minimize usage of 'A's or to maximize it?

>> I gather the case for car electronics is closed now?
> 
> From my point of view, we didn't have a case since XML
> would not be needed in any way I could imagine (other
> that this small customer car info server thingy).

Finally! 

>>>> B) methodic of its evaluation
>>>
>>> Multivariate analysis of those variables of the programming situation
>>> that lead to a decision about data formats.
>> 
>> No, the methodic of evaluation a measure of similarity of the "motivating
>> factors."
> 
> Methods?
> Here are two simple methods that do not always work:
> - [all equals] Majority vote.
> - [consultation among equals] For each pair (Pi, Pj) of people
[...]

No. What you wrote was a crude description of the multiple-criteria ranking
problem. Before that you need a methodic to measure single criteria
(features), e.g. a "motivating factor." These are done by physical
measurement instruments, expert polls, statistical procedures etc.

>>>> D) comparison to competing solutions
>>>
>>> See above, and everything said so far.
>> 
>> No, you should show that for XML "motivating factors" are more similar or
>> dissimilar
> 
> I see. A misunderstanding, I think. Dissimilarity has motivated
> preferring, and possibly choosing XML, in order to tackle dissimilarities.

Dissimilarity is a *measure*. In a metric vector space the measure of
dissimilarity is the distance between two points. In non-metric spaces
there are various measures of different properties. You evaluate XML
against the commuter rail schedule by measuring the dissimilarity of the
"motivating factors" for both. That will give you, depending on the measure
but considering it in the most simple case numeric, two figures x and y.
You compare x with y and conclude that XML is better than the schedule.
BTW, the difference between the measures must have some "physical" meaning.
E.g. one point of dissimilarity would mean 100 voters, 0.5 kWh, 3.5
drachmas, +4 experience points etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de