Prev: Session Factory Error
Next: looking for a predicate hierarchy
From: Daniel Parker on 12 Dec 2006 11:20

Dmitry A. Kazakov wrote:
> On 11 Dec 2006 16:55:51 -0800, Daniel Parker wrote:
>
> >>
> > In the context of enterprise integration, it seems to me that the trend
> > is towards standardization on the representation of data, and away from
> > the idea of distributed objects (aka CORBA, DCOM, RMI, etc.) So date
> > is represented as the text value "2006-10-10T12:00:00-05:00" (noon on
> > 10 October 2006, Central Daylight Savings Time) as opposed to a date
> > ADT (with getYear(), getMonth() etc.)
>
> As Steven has pointed out these are not equivalent. We have to decide
> whether data represented by a text value show a behavior of a date or text.
> Consider T1 - T2, what is the result? Does < compare dates or texts? Can I
> add "1" to the text and get the date of 1 second later?

All of these things are defined in a specification. XML Schema is not
one of the world's great specifications, but it does define all of
these things.
>
> > Every industry from life
> > insurance to publishing seems to be participating in consortiums for
> > standardizing on a representation of data that fits their business
> > context.
>
> This is an obvious and easy step ... in a totally wrong direction. One
> could agree on a representation format of something which behavior is
> known. For this you have to define the behavior. How could we do that? What
> is the behavior of date? Has it day savings? Is it monotonic? Is it
> astronomical time. Would it work on the moon? etc. Even for simple things
> like floating point number it is very difficult to define the behavior of.
> What about any more complex stuff? The point is, you need a language (not
> necessarily a programming one) to describe the behavior.

A specification will do.

> You cannot come
> out with some implied behavior. Text is not a language. Should we do
> natural text processing, or what? Even if we managed it perfectly, an A.I.
> from UK could ask, damn it, is 12:00 in the text above PM or AM?
>
All of these things are covered by the specification for the data
representation.

> People are doing things you are describing, just because they don't want to
> think any further, and because any kind of more precise definition is not
> in the economical and political interests of the parties involved. The
> least common denominator is what we get.
>
> > Communication is through the transfer of documents containing
> > data adhering to standards. One big reason is decoupling; from a
> > document centric approach, no matter how many code decoupling
> > strategies Robert Martin comes up with, the result is still tightly
> > coupled, it is in the nature of code. (I'm not exactly sure what
> > "behaviour" means, I haven't seen the term used in formal treatments of
> > ADTs, but I think it has something to do with code.)
>
> I see your point. But the decoupling you are talking about were achieved
> through making everything static. All and everybody should agree on an
> implied, not stated, behaviour of dates. You cannot communicate things you
> didn't agree in advance. This is an utopia. It has no future,

It has a present. Who knows about the future? Good data
specifications do allow for extensibility. There is some flexibility,
known components can be assembled in different ways, and understood.

> You lifted a local coupling and moved it
> to the global scope, probably beyond mere software developing. Yuck.
>
I don't think so. CORBA, RMI etc. introduce global coupling, things
have to match on both sides of a wire. Communication based around
documents with well defined data takes that out.

Regards,
Daniel Parker
http://servingxml.sourceforge.net/

From: Daniel Parker on 12 Dec 2006 11:20

Dmitry A. Kazakov wrote:
> On 11 Dec 2006 16:55:51 -0800, Daniel Parker wrote:
>
> >>
> > In the context of enterprise integration, it seems to me that the trend
> > is towards standardization on the representation of data, and away from
> > the idea of distributed objects (aka CORBA, DCOM, RMI, etc.) So date
> > is represented as the text value "2006-10-10T12:00:00-05:00" (noon on
> > 10 October 2006, Central Daylight Savings Time) as opposed to a date
> > ADT (with getYear(), getMonth() etc.)
>
> As Steven has pointed out these are not equivalent. We have to decide
> whether data represented by a text value show a behavior of a date or text.
> Consider T1 - T2, what is the result? Does < compare dates or texts? Can I
> add "1" to the text and get the date of 1 second later?

All of these things are defined in a specification. XML Schema is not
one of the world's great specifications, but it does define all of
these things.
>
> > Every industry from life
> > insurance to publishing seems to be participating in consortiums for
> > standardizing on a representation of data that fits their business
> > context.
>
> This is an obvious and easy step ... in a totally wrong direction. One
> could agree on a representation format of something which behavior is
> known. For this you have to define the behavior. How could we do that? What
> is the behavior of date? Has it day savings? Is it monotonic? Is it
> astronomical time. Would it work on the moon? etc. Even for simple things
> like floating point number it is very difficult to define the behavior of.
> What about any more complex stuff? The point is, you need a language (not
> necessarily a programming one) to describe the behavior.

A specification will do.

> You cannot come
> out with some implied behavior. Text is not a language. Should we do
> natural text processing, or what? Even if we managed it perfectly, an A.I.
> from UK could ask, damn it, is 12:00 in the text above PM or AM?
>
All of these things are covered by the specification for the data
representation.

> People are doing things you are describing, just because they don't want to
> think any further, and because any kind of more precise definition is not
> in the economical and political interests of the parties involved. The
> least common denominator is what we get.
>
> > Communication is through the transfer of documents containing
> > data adhering to standards. One big reason is decoupling; from a
> > document centric approach, no matter how many code decoupling
> > strategies Robert Martin comes up with, the result is still tightly
> > coupled, it is in the nature of code. (I'm not exactly sure what
> > "behaviour" means, I haven't seen the term used in formal treatments of
> > ADTs, but I think it has something to do with code.)
>
> I see your point. But the decoupling you are talking about were achieved
> through making everything static. All and everybody should agree on an
> implied, not stated, behaviour of dates. You cannot communicate things you
> didn't agree in advance. This is an utopia. It has no future,

It has a present. Who knows about the future? Good data
specifications do allow for extensibility. There is some flexibility,
known components can be assembled in different ways, and understood.

> You lifted a local coupling and moved it
> to the global scope, probably beyond mere software developing. Yuck.
>
I don't think so. CORBA, RMI etc. introduce global coupling, things
have to match on both sides of a wire. Communication based around
documents with well defined data takes that out.

Regards,
Daniel Parker
http://servingxml.sourceforge.net/

From: topmind on 12 Dec 2006 12:21
Dmitry A. Kazakov wrote:
> On 11 Dec 2006 16:55:51 -0800, Daniel Parker wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On 8 Dec 2006 18:37:10 -0800, Daniel T. wrote:
> >>
> >>> To quote Uncle Bob:
> >>>
> >>> Unfortunately, representational modeling is often taken for
> >>> object-oriented modeling... Representational models are an
> >>> abstraction of static entities and relationships, devoid of
> >>> behavior; object-oriented models are abstractions of dynamic
> >>> behavior devoid of representation.
> >>
> >> This is a very good one.
> >>
> >> However. Look what happens once we've got rid of data. Which, by the way,
> >> is a very important step. Also, no data exist. Hooray! But now the behavior
> >> itself inevitably starts to form new abstractions which are first perceived
> >> as data. The text of a program or an UML diagram are just data. At some
> >> stage these abstractions are again considered as a behavior (of behavior).
> >> Patterns is a typical example. This is a never ending process. I think that
> >> OO and OOPLs try to embrace it more or less successfully.
> >>
> >> I don't know if this any close to Robert's view, but this is one of the key
> >> factors which make me disagree with H.S. He believes that he could stay on
> >> the top of this pyramid. I argue that there is no any top. Data and
> >> behavior are relative and mutually complementary. In that sense neither
> >> exist. This is a platform on which we could talk to the relational camp.
> >>
> > In the context of enterprise integration, it seems to me that the trend
> > is towards standardization on the representation of data, and away from
> > the idea of distributed objects (aka CORBA, DCOM, RMI, etc.) So date
> > is represented as the text value "2006-10-10T12:00:00-05:00" (noon on
> > 10 October 2006, Central Daylight Savings Time) as opposed to a date
> > ADT (with getYear(), getMonth() etc.)
>
> As Steven has pointed out these are not equivalent. We have to decide
> whether data represented by a text value show a behavior of a date or text.
> Consider T1 - T2, what is the result? Does < compare dates or texts? Can I
> add "1" to the text and get the date of 1 second later?

In scriptish or dynamically-typed languages one gets used to this kind
of thing and deals with it. The advantage of a standardized text
formats is that just about any programming language can use them, at
least in a rudimentary sense. Creating a date library for each of 2,000
programming languages is not good factoring of human effort.

By the way, a connonical date text format can still be compared
properly as strings if designed right. For example, a date formatted in
YYYY-MM-DD can be compared using ">" and "<".

I know many of you OO'ers want to force everybody into a single OOP
language, such as Java or Smalltalk to acheive behavioral unity, but
that is not going to happen and text is more multi-language-friendly.

>
> > Every industry from life
> > insurance to publishing seems to be participating in consortiums for
> > standardizing on a representation of data that fits their business
> > context.
>
> This is an obvious and easy step ... in a totally wrong direction. One
> could agree on a representation format of something which behavior is
> known. For this you have to define the behavior. How could we do that? What
> is the behavior of date? Has it day savings? Is it monotonic? Is it
> astronomical time. Would it work on the moon? etc. Even for simple things
> like floating point number it is very difficult to define the behavior of.
> What about any more complex stuff? The point is, you need a language (not
> necessarily a programming one) to describe the behavior. You cannot come
> out with some implied behavior. Text is not a language.

Huh?

> Should we do
> natural text processing, or what? Even if we managed it perfectly, an A.I.
> from UK could ask, damn it, is 12:00 in the text above PM or AM?
>
> People are doing things you are describing, just because they don't want to
> think any further, and because any kind of more precise definition is not
> in the economical and political interests of the parties involved. The
> least common denominator is what we get.

Bull. It is because it is more flexible. Data has outlasted programming
languages many times. 20 years from now Java will be looked down on the
way COBOL is. Its screwy meta model is already a laughing stock.

>
> > Communication is through the transfer of documents containing
> > data adhering to standards. One big reason is decoupling; from a
> > document centric approach, no matter how many code decoupling
> > strategies Robert Martin comes up with, the result is still tightly
> > coupled, it is in the nature of code. (I'm not exactly sure what
> > "behaviour" means, I haven't seen the term used in formal treatments of
> > ADTs, but I think it has something to do with code.)
>
> I see your point. But the decoupling you are talking about were achieved
> through making everything static. All and everybody should agree on an
> implied, not stated, behaviour of dates. You cannot communicate things you
> didn't agree in advance. This is an utopia. It has no future, because it
> imposes a much tighter coupling on the whole software developing
> infrastructure, including people. You lifted a local coupling and moved it
> to the global scope, probably beyond mere software developing. Yuck.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

-T-

From: Dmitry A. Kazakov on 12 Dec 2006 12:58
On 12 Dec 2006 08:20:33 -0800, Daniel Parker wrote:

> Dmitry A. Kazakov wrote:
>> On 11 Dec 2006 16:55:51 -0800, Daniel Parker wrote:
>>
>>> In the context of enterprise integration, it seems to me that the trend
>>> is towards standardization on the representation of data, and away from
>>> the idea of distributed objects (aka CORBA, DCOM, RMI, etc.) So date
>>> is represented as the text value "2006-10-10T12:00:00-05:00" (noon on
>>> 10 October 2006, Central Daylight Savings Time) as opposed to a date
>>> ADT (with getYear(), getMonth() etc.)
>>
>> As Steven has pointed out these are not equivalent. We have to decide
>> whether data represented by a text value show a behavior of a date or text.
>> Consider T1 - T2, what is the result? Does < compare dates or texts? Can I
>> add "1" to the text and get the date of 1 second later?
>
> All of these things are defined in a specification. XML Schema is not
> one of the world's great specifications, but it does define all of
> these things.

Really? It is impossible to specify one time format. The fundamental laws
of physics (relativity theory) and mathematics would prevent this.

>>> Every industry from life
>>> insurance to publishing seems to be participating in consortiums for
>>> standardizing on a representation of data that fits their business
>>> context.
>>
>> This is an obvious and easy step ... in a totally wrong direction. One
>> could agree on a representation format of something which behavior is
>> known. For this you have to define the behavior. How could we do that? What
>> is the behavior of date? Has it day savings? Is it monotonic? Is it
>> astronomical time. Would it work on the moon? etc. Even for simple things
>> like floating point number it is very difficult to define the behavior of.
>> What about any more complex stuff? The point is, you need a language (not
>> necessarily a programming one) to describe the behavior.
>
> A specification will do.

I am impressed. Can these specifications be written in XML?

>>> Communication is through the transfer of documents containing
>>> data adhering to standards. One big reason is decoupling; from a
>>> document centric approach, no matter how many code decoupling
>>> strategies Robert Martin comes up with, the result is still tightly
>>> coupled, it is in the nature of code. (I'm not exactly sure what
>>> "behaviour" means, I haven't seen the term used in formal treatments of
>>> ADTs, but I think it has something to do with code.)
>>
>> I see your point. But the decoupling you are talking about were achieved
>> through making everything static. All and everybody should agree on an
>> implied, not stated, behaviour of dates. You cannot communicate things you
>> didn't agree in advance. This is an utopia. It has no future,
>
> It has a present. Who knows about the future?

Well, we could use COBOL. I see no any technological difference. You
propose to sit down and specify everything in the world. Great, why didn't
it worked in 70's?

> Good data
> specifications do allow for extensibility.

Ah, that's interesting. What about a good specification of a circle? Let's
extend to an ellipse! (:-))

> There is some flexibility,
> known components can be assembled in different ways, and understood.

and then crash...

If I were a conspiracy theorist, I would suggest that the only purpose of
XML was to rebut the Moore's law. (:-))

>> You lifted a local coupling and moved it
>> to the global scope, probably beyond mere software developing. Yuck.
>>
> I don't think so. CORBA, RMI etc. introduce global coupling, things
> have to match on both sides of a wire.

This is true, but remember that CORBA was designed long ago. It lacks a
consistent type system. But for all, CORBA's approach is just like yours
with the only difference that the coupling is system-wide. IDL files are
statically valid across the system. In your approach W3C is planet-wide.
Great.

(RMI deserves no attention, being a low-level mechanism. It had been known
as RPC years before.)

> Communication based around
> documents with well defined data takes that out.

The only question is why do we use computers? Document exchange worked
great in XIX century... (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 12 Dec 2006 13:18
On 12 Dec 2006 09:21:37 -0800, topmind wrote:

> In scriptish or dynamically-typed languages one gets used to this kind
> of thing and deals with it. The advantage of a standardized text
> formats is that just about any programming language can use them, at
> least in a rudimentary sense. Creating a date library for each of 2,000
> programming languages is not good factoring of human effort.

Which is exactly what Daniel's approach implies, you need an XML parser +
interpreter for all 2,000 languages.

> By the way, a connonical date text format can still be compared
> properly as strings if designed right. For example, a date formatted in
> YYYY-MM-DD can be compared using ">" and "<".

I am dying to see a GPS system based on this time representation. Maybe
GALILEO will become one?

> I know many of you OO'ers want to force everybody into a single OOP
> language, such as Java or Smalltalk to acheive behavioral unity, but
> that is not going to happen and text is more multi-language-friendly.

LOL. I always knew that you don't trust in DBs! (:-)) Read what you wrote.
Is it about the format for keeping the source code programs written in
those "multi-languages?" (:-)) For that purpose I'd propose a DB, like
ClearCase!

>> Should we do
>> natural text processing, or what? Even if we managed it perfectly, an A.I.
>> from UK could ask, damn it, is 12:00 in the text above PM or AM?
>>
>> People are doing things you are describing, just because they don't want to
>> think any further, and because any kind of more precise definition is not
>> in the economical and political interests of the parties involved. The
>> least common denominator is what we get.
>
> Bull. It is because it is more flexible. Data has outlasted programming
> languages many times. 20 years from now Java will be looked down on the
> way COBOL is. Its screwy meta model is already a laughing stock.

I presume that COBOL is still the most used language.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Session Factory Error
Next: looking for a predicate hierarchy