Re: The Three Myths of XML

[Alaric Snell <alaric@alaric-snell.com>]

Quoting XML Everywhere <host@xmleverywhere.com>:

> I read another email where you said Java serialization
> works great for you.  Dealing with typed data
> and XML is a pain, especially for
> floating point values.  Will XSD solve
> this?  Will parsers ever support XSD?
> The answer to both questions is "eventually".  For now
> there's the conversion functions
> in programming languages such as "atoi" etc.
> It  works but it's tedious.  Serialization
> libraries elminate all of this extra work
> and therefore is very attractive.

The thing is, if there's existing serialisation stuff like Java has, is there
anything to be gained by providing automatic XML serialisation in the same
framework, eg behind an API? If nothing but the library really touches the XML
(and nobody else would want to because it's not going to be *the* most readable
XML), why not stick with what you have?

> Both MFC and Java have their own
> binary serialization built in.  Java's
> implementation is arguably better
> -- after all, it was written years later and
> it works on most platforms.  But I
> don't code in MFC or Java so what choice
> do I have?  XML is the best choice.

Java's serialisation is very tied to Java, but then again, it's tied to the
implementation of a given class so that kind of makes sense. It doesn't just
transport data. It (logically) transport behaviour too, even though no code
flows over the network (by default).

> I
> have used various binary serialization libraries
> and I don't enjoy writing code
> to create a sample serialized document,
> and I especially don't enjoy having to
> write all of the persistence code myself
> (save file/read file).  It's trivial to
> write a XML file to disk and XML APIs let
> you open a URL quite easily.

Yep. Putting data representation behind a library is very sensible, bits and
bytes are too low level for day to day handling. XML doesn't have a monopoly
here, though.

> XML allows me to separate clients
> from servers a lot more seamlessly,
> and I don't have to wait for the clients
> (even if they are stupid test apps)
> to be finished before I can test my
> server, because I can just create
> sample input messages by hand.

As is the case with any serialisation format with decent tools :-) I don't know
if there are detailed "serialised Java editors", but once you've set up a test
harness RMI client of a few tens of lines you can change the lines that craft
the arguments to the invoked method with blissful ease. And a received object
that's been deserialised can be toString()ed for examination.

> You also mentioned that you tried
> using HTTP in your RPC layer and
> experienced horrible performance.  Unless
> you convert your app to using coarse-
> grained transactions, this is inevitable.
> The overhead of HTTP,
> even with "keep connections alive",
> is enormous.  Again, you must have the luxury of
> being able to start from scratch, designing
> everything around a high-latency, low-
> reliability network.  For existing apps
> that is simply not possible.  Even then,
> RPC is quite viable inside the firewall.  I
> use it all the time in the form of COM+.
> But almost all developers have come to
> the conclusion that COM+ and other
> RPC methods don't work very well
> over the Internet.  Direct
> socket connections don't so work good (sic)
> over the Internet.

Is this a problem with the concept of RPC in general (so it affects SOAP and
friends too) or just ONC-RPC/COM+ and friends that you're talking about?

> I couldn't disagree with you more
> about sticking with marking text up.
> My production apps encode data with XML every
> minute of every day and XML works
> great.  Is it better than other tried and true
> methods?  I'd say yes, because
> I can send XML messages to a log file, for
> example, when an error occurs, so I
> can investigate the problem later.  I actually do that
> quite often.  This is simply pointless when
> you're using binary serialization libraries.
> When you use binary serialization you just have
> to ignore those odd intermittent
> problems and keep your fingers crossed.

!!! No way is that professional software development practice :-)

No matter how you transport your data over the wire or on disk, you will still
have code that converts that into an object in your programming environment
(Java class, C struct / pointer network, etc). *THAT* is the stage where you do
debug dumps, since *that* is the stage where the semantics of the object in
transit are condensed into the most usable, well-defined, form. At that stage
you can log stuff by casting that object to a string (some languages do this for
you nicely, others expect an operator<<(ostream &o) to be defined...). Taking
the effort to put "dump to string" methods on all your classes helps debugging
inside the program logic, too, since you can log stuff from there, not just at
address space boundaries where things are XMLized.

> XML is neither a panacea nor a
> pariah.  Those who advocate XML should
> only do so when they have real coding
> experience under their belt.  Unfortunately,
> most of the hot air bags do not.  They
> did the same thing with RPC, and you can
> bet they'll hype the next technology that
> comes along.

Java was once a victim of this, too... IIRC it took a couple of years to pass.
How long does XML have to go before it starts to settle down? :-)

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software