[mmox] Three serializations

[Catherine Pfeffer <[e-mail]>]

> so. again. let me reiterate the issues we have with "the XML way."
>
> first off, XML is for us, not a first order representational system.

Finally! I'm really glad to hear that.

If XML serialization is not a first class citizen in the protocol, then why
is it presented at the same level as the other serializations in the LLSD
draft? Why bother with it at all?

Implementing three serializations (plus perhaps a serialization negotiation)
mechanism will mean tons of more work for everyone.

Excuse me, but the considerations you expressed behind the choice of having
a XML serialization ("because we need JSON too", and "not co-mingle
application semantics with presentation logic") do not explain why an XML
serialization would be necessary. To me this sounds like, "We'd like to
separate our data view from the on the on-the-wire protocol. Oh cool, that
means we could change serialization of the fly. As a proof of concept, here
is an XML serialization that could please the XML nerds out there!". That is
not a valid argumentation in favour of an XML serialization.

Virtual Worlds exchange lots of data: spatial, graphical, multimedia. That
makes binary formats an obvious choice, be it LLSD (or whatever its future
name), Google buffers, or anything else.

You have come with something great, Infinity. Your binary format is an
extraordinary middle way between compactness and flexibility. It achieves
what Corba and UNO and others have always tried to do, but in a much
simpler, bullet-proof, way.

On the other hand, transposing it one-to-one to XML does not really work.
When it takes you 1 byte to encode "integer" in the binary serialization, it
take you 19 bytes in the XML serialization (<integer> ... </integer>).

Again, your XML might look like XML, but it is not real XML:


1) You don't take profit of XML validation mechanisms

Having very low-level data types like <integer> or <float> makes validation
look like more a wellformed-ness test than real validation.

There is not even a way to control that a color is in the RGB range, or even
that a vector has three coordinates.

This XML really works at a semantics level that is too low. It's like
writing an assembler program with binary codes in an array of char in a C++
program ;-). The external grammar is C++, but the inside content is still
assembler.


2) Your XML format does not fit well into DOM parsing or XSLT/XPath
transformations

The XPath expression
      map/key[. = 'Taper_X']/following-sibling::float[position() = 1]
speaks for itself, at a place where people normally do
      @Taper_X
(I have not checked that this expression works, but the real one must not be
very far away in terms of complexity)

Jon was right when saying about maps that this is "a terrible
serialization".


3) One of the major advantages of XML is that it's human-readable. But the
data types like <integer> or <array> clutter the file. Embedded XML tags are
replaced with nested <map>s. So even that does not work well.


So, if the native XML tools are of little use, why bother with XML at all?

-- 
Cathy