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 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. The decision must be based on
the immanent features of the protocols in question.

> 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
2. present relevant criteria to evaluate a solution
3. present competing solutions > 1 (proving them solving the problem)
4. evaluate these solutions against the criteria
5. make choice based on the ranking obtained

>> How is the choice XML vs., say, CANopen motivated by specifically
>> homogeneity?
> 
> By a homogeneity that I have outlined when talking about measures
> of sameness, in the context of the situation, which is full of motives.

See above and go from 1 though to 5.

>> What is homogenous by XML, which is not by other protocols, and conversely?
> 
> XML is not a protocol, but that's an aside.

If you say that XML is not a protocol, then the train stops right here. We
were talking about the network of car devices. I don't care what else XML
might be, because being not a protocol automatically disqualifies it here
and now.

>> Which weight has the above [quantitative? qualitative?] difference in the
>> context of the requirements, functional and non-functional, imposed on the
>> car software infrastructure?
> 
> Yes, as I said, apply fuzzy logic,

You seem to imply that fuzzy logic (in its scientific meaning) acts
differently from crisp logic by allowing any sorts of non sequitur. It does
not.

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

So I am merely asking for:

A) the definition of, because yours is absolutely non-standard
B) methodic of its evaluation
C) signs of importance for the considered case (car electronics network)
D) comparison to competing solutions

The joke an unknown author made about XML worked because it mocked the
process 1-5:

"XML combines the efficiency of text files with the readability of binary
files"

You find here all components: the competing solutions, the criteria, their
evaluation all leading to the hilarious choice of the worst possible
solution, which also makes a deeper point that there actually exists no
technical problem for which XML might be a proper solution. Very so!

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