Re: XML too hard (YAML opportunity?)

On Wed, Mar 19, 2003 at 04:01:53PM +0900, Richard Kilmer wrote:
> Think of it this way:
> 
> class Person
>   attr_accessor :firstname, :lastname
> end

<< snip example >>

What this example highlights is that XML and YAML sit at two different
levels (shame there isn't an ISO 7-layer model for discussing object
serialisation :-)

XML is a way of presenting structured data or marked-up text, and because it
doesn't specify how to handle that data, you have to define the semantics
for yourself. YAML's application domain is serialisation of arbitary
objects, and it has strongly defined semantics for that.

You can get the same or similar semantics with XML, by putting another layer
on top of it. One way is SOAP, which gives application code almost identical
to the YAML example:

| === Output ===
| 
| SOAP:
| require 'soap/marshal'
| soap = SOAP::Marshal.dump(p)
| puts soap

<?xml version="1.0" encoding="us-ascii" ?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Body>
<Person xmlns:n1="http://schemas.xmlsoap.org/soap/encoding/" xmlns:n2="http://www.ruby-lang.org/xmlns/ruby/type/custom" xsi:type="n2:Person" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<firstname xsi:type="xsd:string">Richard</firstname>
<lastname xsi:type="xsd:string">Kilmer</lastname>
</Person>
</env:Body>
</env:Envelope>

| === Input ===
|
| SOAP:
| p = SOAP::Marshal.load(soap)

The output of this program _is_ XML, but it's more than that: it's
SOAP-over-XML. It's also ugly, but trivial examples like these always look
bad in SOAP, because of the overhead of setting up XML namespaces. The
advantage of this is that your SOAP/XML document is unambiguous, even when
sat alongside other random XML documents and SOAP objects from different
sources.

In fact, according to the YAML home page, the YAML people have defined a
standard for putting YAML serialisation semantics over XML: YAXML. I've not
seen any implementation of that though.

So, with XML, you have to define your own emitters and receivers for each
class. With SOAP/YAML/YAXML, they provide a higher-level abstraction which
is an emitter and receiver for *all* object classes. I think the latter sits
very nicely with Ruby's dynamic typing.  They work at the same level as
Ruby's Marshal, which marshals arbitary objects directly to its own binary
string representation. If you want to store an object or collection of
objects persistently then these solutions all work well.

Incidentally, once you've got object serialisation, then another nice layer
to stick on top of that is RPC. SOAP has this defined as part of the spec;
YAML has OKAY; Marshal has DRuby.

I think hand-editing is something of a side issue. If your requirement is
for config files then you _can_ hand-edit the internal representation of a
serialised object, but in many cases there is a Better Way for a particular
application. Since many config files are just key=value pairs then YAML's
representation of a hash shows them quite neatly, but I'm not sure I'd want
to write a YAML object from scratch for anything more complicated - get the
number of spaces wrong at the start of a line and you end up with an
unparseable object. Having some sort of start/end markers for a block of
related parameters seems more friendly to me. Whether that's curly brackets
(like dhcpd.conf) or <tag>...</tag> I don't really care. In complex
configuration files none of these are appropriate. Would you want to
hand-edit sendmail.cf or an exim configure file as XML? I don't think so.
(OK, so sendmail.cf is not a good example of how configuration files ought
to be :-)

Hand-editing gives you the possibility of recovering from certain forms of
data corruption, perhaps. But there are other issues which may be of greater
importance, such as interoperability. If you want to do RPC over the
Internet you'll find a whole load of sites using SOAP, but few using
YAML/OKAY (which hasn't even got a stable standard yet, from what I hear).
And potentially your SOAP object could be processed with a whole load of
other XML-based tools, none of which I'm familiar with. But in principle I
think you could use XST to pre-validate an object received from an untrusted
source over the Internet, for example, before deserialising it into your
application. The security benefits of that could be important: like a
firewall for objects.

Regards,

Brian.