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

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

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

No. Problems with sources are actually solved by the sources becoming
different from what they were before. It's a market effect. Customers
make suppliers make different sources.


>>> 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. It is characterized by several
variables. One variable measures the qualities of the data sources.


>>> 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. This is how people *have* solved problems of integrating
data. If you cannot present a good reason to sell your data in some
standard form, as a result creating work for others, you're out.

> 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!")


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



> 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". An algorithm computes results from
several inputs. If "processors" need to process many differences,
if higher order "processors" need many "processor hands" to get
compatible inputs, then this complicates the coordinated processing.
It also costs more time and money.


> 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. The processes of isolating messages
may differ greatly, at several stages of processing.


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


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


>>> 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
who contribute to the decision, two things are of the same kind
if Pi and Pj find them to be of the same kind. If i,j ∈ {1, ..., N},
then let similarity of things be the proportion of agreements
in (N choose 2). The P could be experts from different fields.
(Note: for triples (Pi, Pj, Pk), science has found that
if Pi and Pj agree, but Pk does not, then in most cases Pk
will not uphold disagreement if pressured by Pi and Pj.)
Whether or not Pi and Pj agree might be influenced by unalterable
properties of the things in question if found.

Note in particular that---a priori---there is no way to say
that two things are equal, or similar, or of the same kind before
they have been shown to be, and in which way.
Are the balls of a bearing equal?
Are they homogeneous/heterogeneous? The answer to the latter
question may depend on the identities of the bearings involved,
if you ask a technician, I think, and possibly on who you ask.

For more, and for more realistic function procedures resulting in
decisions, see the description of the programmers' situation above.


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

Like heterogeneity has motivated establishing the HOWLG at least
in one way, I think.