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

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

On Thu, 16 Aug 2012 20:31:20 +0200, Georg Bauhaus wrote:

> On 16.08.12 14:56, Dmitry A. Kazakov wrote:
>> On Thu, 16 Aug 2012 13:18:28 +0200, Georg Bauhaus wrote:
>> 
>>> On 16.08.12 09:30, Dmitry A. Kazakov wrote:
>>>> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:
>>>>
>>>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>>>>
>>>>>> And
>>>>>> how these false premises could justify any application of XML even if per
>>>>>> some miracle they happened true?
>>>>>
>>>>> The point of the exercise is to make apparent the variables
>>>>> that help decide when, and when not, to use XML,
>>>>
>>>> List of the variables, please.
>>>
>>> They were given in the text, and even indicated syntactically.
>> 
>> What you listed was unrelated to the issue.
> 
> It was related to the issue from which you keep dragging
> the discussion away: data formats.

So XML is a data format? Let's note that.

>>> I had hoped that someone with a PhD in mathematics would find
>>> this a fair read, even when the subject matter might look strange
>>> at first sight.
>> 
>> If has nothing to do with strangeness. There is a standard procedure of
>> evaluating such things in engineering. You should:
>> 
>> 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.
Problems with sources are solved by choosing other sources or other means
applied to the 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 ]

>> 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. Sources of data in a car are sensors. E.g. the lambda sensor:

http://en.wikipedia.org/wiki/Lambda_sensor

>> 4. evaluate these solutions against the criteria
>> 5. make choice based on the ranking obtained

>> We were talking about the network of car devices.
> 
> I was not talking about protocols.

Network peers are communicating using protocols. You have no choice in
selecting the participants of the car's networks. They are defined per
general car design.

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

>>> and doing so stipulates
>>> that the persons involved can produce weights that work.
>>> Actually, I am sure they have done so many times.
>> 
>> In that case you should summarize/cite their results. You brought the issue
>> of "homogeneity" up as a criterion of choice in favor of XML. Did you?
> 
> On the contrary, I said that XML, if chosen, is a way of
> tackling heterogeneity of data.

What is "heterogeneity of data" and why should it be tackled?

> (E.g., moving away from Teletext
> to XML sent over HTTP.) With Teletext, I have had to find means
> of inspecting a mostly unknown stream of video text data.

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?

> 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. Again: What is the problem? What are the solutions?
Positions 1, 2, 3, 4, 5.

I gather the case for car electronics is closed now?

>> So I am merely asking for:
>> 
>> A) the definition of, because yours is absolutely non-standard
> 
> Homogeneity is a pre-network term and means, as mentioned many times,
> of the same kind. (όμοιοϛ and γένοϛ are the parts of the word, TTBOMK.)
> Where "kind" is from a multidimensional space of motivating factors.

What are "motivating factors" of car electronic components, how are they
same?
 
>> 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."

>> C) signs of importance for the considered case (car electronics network)
> 
> I said, after establishing background, which see, that "a network
> connecting the electrical devices of a car does not counts
> as heterogeneous." A statement valid against the background only.

No, the importance of similarity/dissimilarity between the "motivating
factors" of/for car electronics.

>> 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 have no idea why they should be of any kind and what is the
goal) than the "motivating factors" for, say, the commuter rail schedule.

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