Object-oriented serialization (Was Re: Some questions)

[Matthew Gertner]

David Megginson wrote:
> If you have a function loadXML(), you get a DOM tree or a bunch of SAX
> events or something similar; if you have a function loadRDF(), you get
> a collection of objects with attributes and relationships.  In either
> case, a schema can tell you things like "element type/class B is a
> kind of element type/class A", but that's secondary information; the
> primary information is "element X is an object of class Y with
> identifier Z, while element A represents a relationship between this
> object and object C".

A schema gives you this information too. The problem of how to attach a
schema to an instance is not yet resolved, but it is a purely syntactic
consideration and a satisfactory solution will be found. This then tells
you what class a given instance belongs too. The identity can be
specified using an ID attribute; this is exactly the way it is done in
RDF. That an element represents a relationship is implicit in the
content model of the element.

SAX is great as far as it goes, but we seem to be agreeing that an
additional layer is needed on top. This layer is not the DOM. One of the
lessons that I learned from my time at POET Software is that, although
we had an excellent generic API, the vast majority of our customers
wanted to work with real C++ (and later Java) classes in their problem
domain. But there is nothing to say that a loadXML() function must
return a DOM tree. There are a variety of efforts to create
domain-specific objects automatically from XML objects. I don't have a
list at the tips of my fingers, but if anyone does it would be a great
resource. They are out there because I keep bumping into them.

> If you're interested in a collection of objects in the first place,
> why should you have to see or know about XML elements and attributes
> at all?  Or to put it a different way, why should people constantly
> have to redo the work of extracting objects from XML, when they're all
> trying to do the same thing?

Once again, there are already tools that provide this functionality
across applications (i.e. they can be plugged in and used without
additional development). The interest of XML is essentially as a way to
serialize objects and send them across a network, as you also stated.

> I think that reasonable people can argue that RDF is not the best
> solution to the problem of object exchange in XML, but I am somewhat
> surprised to hear people deny that the problem even exists: there is
> an enormous demand for exchanging objects in XML (businesses exchange
> a lot of structured data), and it's hard work to have to figure out
> over and over how to construct objects from a SAX stream or a DOM tree
> especially when programmers with XML knowledge are scarce and
> expensive.
> 
> I have no doubt that we need an abstract object layer on top of XML.
> Right now, RDF is the best solution currently available (XMI also has
> its advocates), but I'm ready to listen about anything better.

In no way do I doubt the importance of being able to exchange objects in
XML, but I do have serious reservations about RDF as the way to do this,
and they have nothing to do with the hairy syntax or hard-to-understand
spec. What is lacking right now is an overarching approach to using XML
in real-world applications. To be quite blunt it seems ashame that a lot
of really great work is being put into the RDF effort (including a very
valuable vocabulary for collection classes, just to name one) instead of
being integrated more tightly into the overall XML architecture. This is
especially so because there isn't an overall XML architecture yet, and
the effort and thought that are being put into RDF could bring us a long
way towards this. I don't agree with the conclusions of the Cambridge
Communique. I think that if the work being done on RDF were refocused to
making sure that XML Schemas do everything that the RDF advocates are
rightly claiming is necessary, that we will see a clear win in terms of
pushing the whole XML effort from a theoretical effort into a major
paradigm shift with extensive real-world implications. As things stand,
this work is being diluted because both we are asking people to read
about, grasp and implement two things instead of just one.

Cheers,
Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)