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

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

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.

I'll note in advance that your train might have stopped,
but you have missed ours, which has a different destination.

(I will give an example about distributed production of software,
if requested.)


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

> 2. present relevant criteria to evaluate a solution

Situational, given, as mentioned, e.g. integration of data.

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

> 4. evaluate these solutions against the criteria

Ergo.

> 5. make choice based on the ranking obtained

Situational, e.g. as above.


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

I did. Again.

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

OK. Your train stops.

> We
> were talking about the network of car devices.

I was not talking about protocols. Please re-read the posting

Message-ID: <502b832f$0$6579$9b4e6d93@newsspool3.arcor-online.net>

which started this sub-discussion. See in particular how does *not*
mention protocols at all.

> I don't care what else XML
> might be,

Your choice.

> because being not a protocol automatically disqualifies it here
> and now.

Yes, like I said, most engineers would heartily agree. See [+Almost all]
in a previous posting.


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


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

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

> B) methodic of its evaluation

Multivariate analysis of those variables of the programming situation
that lead to a decision about data formats.

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

And that, therefore, one of the reasons for choosing XML does
*not* apply.

> D) comparison to competing solutions

See above, and everything said so far.

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

It works only for those people who would declare the truth of
false statements about XML, mistaking the meanings of nouns
(deliberately?):

1. that readability means more than "can be read, technically, with
plain text tools", (it means little more than that)
2. that XML had been developed to be more efficient than other
data formats. (It has not.)

> 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

I really have to say that from False follows...

There is a huge amount of technical problems with heterogeneous
data, but people solving these problems do not submit to
your exclusive definition of "technical". Integration of
information of different kinds of data documents, such as Teletext
and HTML pages, *is* a technical issue. Granted, it is not just
one of electronics.

The major contenders in the office market leverage the data
format problem for economic purposes, worsening the situation
for future generations. And damaging the reputation of XML.
To some extent they have succeeded in undermining the intents
of using XML. For example, one of the contenders simply
provides an isomorphic mapping of .doc to .docx, basically.
That's devilish, and cynic, but silences those who
had really asked for a way to make documents readable (technically
readable) without running the single program capable of reading
.doc and .docx properly.