Re: Interplatform (interprocess, interlanguage) communication
Arne Vajh=F8j wrote:
it all still basically amounts to:
read a line;
split the string;
do something with the split strings.
But that not how you work with XML.
You load it into a DOM and use XPath to pull
out what you need.
Or you scan it with SAX or StAX and deal with XML-parsing events, or
you run the schema through JAXB and let it generate all the parsing
classes for you, or you use one of the many other standard libraries
in Java (or if not Java, in your favorite platform) that are available
personally, I like recursive hand-written descent parsing, as it is
fairly straightforwards and doesn't depend on external tools.
The number-theorist can never pass a calculus exam because he's only
just reinvented calculus by the end of the hour.
You need to depend on some tools.
If you use Java then you depend on standard Java library.
Standard Java library contains several XML parsers.
No extra dependency for Java.
The thing is, BGB, that your macho programming style is impractical
and not very justifiable. It's wonderful that you have reinvented the
programming world and all, and are so clever and knowledgeable, but
most of us programmers work in a workaday pragmatic environment where
best practices really do save the day. That means use the standards,
and the abundant tools that support them, and give up our egos that
make us feel that superman heroics are the only available path. I
sincerely hope that readers of this thread can understand the manifest
shortcomings of the approaches that you've espoused here. (And that
they can disentangle themselves from your fetching but irrelevant
analogies.) To get the job done, to get it done right, and to minimize both=
error and development time, use the standards.
XML is just fine for just about every purpose to which it's put.
That's why it's popular now. People who cavil about "bandwidth" and
"10 Hz network messages" are tossing us red-herring sashimi. You
aren't going to get 10+ Hz message exchanges over the WAN. For
realistic message rates, XML suits beautifully. I speak from
experience with many, many projects that used every conceivable
message format from binary to CSV to custom to XML to protocol buffers
to JSON, and XML has distinct advantages. Its purported disadvantages
of bulk and bandwidth turn out to be non-issues in practice. Really.
So, dear future readers, stick with what's known to be true by people
who actually do this work, not by some armchair theorist in a darkened
room who thinks that he has to do everything by hand and wants the
rest of us to follow his suboptimal strategy.