data transport

[Lew]

Put some IBM'ers and MS'ers in a committee to agree on that
standard and it will end up just as complex.

The problem with CSV is that the position of a datum has semantics. This
causes trouble.

People *think* CSV would be easier than XML. Then they try to tie together
systems that have different ideas about what goes in column two.

 

[Ian Wilson]

Perhaps the world needs a better method than that. Perhaps the methods
used originally by the IETF have a better chance of avoiding excessive
baroqueness in the end result? All I know is that the result seems a bit
of a mess.

The problem with CSV is that the position of a datum has semantics.

s/CSV/Java Method calls/; s/datum/argument/; Still a problem?

This causes trouble.

Like a java programmer writing `new Dimension(height, width)`?

People *think* CSV would be easier than XML. Then they try to tie
together systems that have different ideas about what goes in column two.

Yes, I think I mentioned that in an earlier message. But CSVDL would
take care of that in the same way that WSDL (and XSD) are needed to take
care of semantic ambiguity for XML.

Note: I'm not pushing CSV, I was just using it in an attempt to
illustrate what seems to be needless complexity in WS and in Java's WS
toolkits. I'm sure that some of that complexity is necessary (at least
sometimes) but I have doubts about a lot of it.

 

[Lew]

s/CSV/Java Method calls/; s/datum/argument/; Still a problem?

Not comparable. The method is called in a single program. The CSV is a
bridge between independent disparate systems. Therefore not a problem, or
even a related issue.

Like a java programmer writing `new Dimension(height, width)`?
No.


Yes, I think I mentioned that in an earlier message. But CSVDL would
take care of that in the same way that WSDL (and XSD) are needed to take
care of semantic ambiguity for XML.

Note: I'm not pushing CSV, I was just using it in an attempt to
illustrate what seems to be needless complexity in WS and in Java's WS
toolkits. I'm sure that some of that complexity is necessary (at least
sometimes) but I have doubts about a lot of it.

I'm saying the complexity isn't "needless".

Well, not all of it. XML /per se/ isn't the problem. Perhaps WSDL could be
improved, but given the range of matters that it covers I'm not so sure.

CSV isn't designed to support, for example, digital signatures. Web-services
protocols with SOAP are. Just to pick one of the details that account for the
differences.

CSV is not self describing. XML is.

CSV doesn't have neutral structure. XML does.

CSV is not semantically void. XML is.

But go ahead, try to solve all the problems with CSV that SOAP does. Don't
take my word for it.

Then get it to work across everyone's systems.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I was discussing the ridiculous complexity of the WS death star
with a woman who was involved in several of the "standards". I
suggested that the WS-* teams would have produced a better quality
product if they'd followed the IETF process of requiring at least two
independent and interoperable implementations for any standard to be
approved.

I think IBM and MS actually did provide independent implementation
of many of the WS-*.

Implementation has a way of reducing unnecessary complexity
that is completely lacking when the only output required is a
document. Her response was "Don't worry about the complexity, there
will be tools to hide that."

This is broken on multiple levels. First, it amounts to a near
complete abdication of responsibility. Waving the magic wand of tool
support merely pushes the real work off to someone else. Second, it
is an admission of failure. If significant tool support is required
simply to use the technology then either the correct abstractions have
not been found or (inclusive) the underlying language(s) are
insufficiently expressive for the problem domain. In the case of Web
Services, I suspect both are true.

We need to be able to manage complexity, not just "hide" it
behind black box tools. Failure to do so results in exactly the
issues identified by Mr. Brick, of which difficulty in debugging is
just the tip of the iceberg.

The WS-* suite is a teetering edifice of components that range
from the gratuitously heavyweight through the poorly thought out to
the utterly unproven. If you can keep your balance long enough to
stand at the top, you'll hear the chaotic winds at the edge of
manageable complexity. Stay there too long and you'll realize you've
gone past that edge.

What do you think the 1950's assembler programmers would say
about todays Java programs ?

That they are way to complex and that the compiler & language
hiding the complexity is a bad thing ?

Whenever we invent a better tool, then someone else will invent
a more complex problem to apply it to.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Not in a scientific discussion.

Yes it is.

I misunderstood the message until I
realised it was ambiguous. So might others. The proper thing to do is
point out the ambiguity and ask the speaker to resolve it
definitively.

If you think it it can be ambiguous, then you write
"I assume that you mean ..." instead of "Huh".

Arne

 

[Patrick May]

I think IBM and MS actually did provide independent implementation
of many of the WS-*.

Not for all and not before adoption of the standard.

What do you think the 1950's assembler programmers would say about
todays Java programs ?

I have a friend who may be the last GCOS still actively
consulting. I know exactly what he thinks of Java.

That they are way to complex and that the compiler & language hiding
the complexity is a bad thing ?

Actually, he just thinks they're sloppy. Being a Yorkshireman,
he makes the case somewhat more scatologically.

The difference between a language like Java and the WS-*
abomination is that Java provides tools for increasing the level of
abstraction, and therefore the complexity, that can be managed by a
programmer. Even in a verbose, not particularly expressive language
such as Java, the costs of using it relative to assembler are exceeded
by the benefits in most cases. The costs of WS-*, relative to other
options, on the other hand, are high and the additional benefits
frequently not significant.

Whenever we invent a better tool, then someone else will invent a
more complex problem to apply it to.

WS-* is the complex problem, not the better tool.

Regards,

Patrick