Object-oriented serialization (Was Re: Some questions)
Robert La Quey
robertl1 at home.com
Thu Dec 2 21:37:46 GMT 1999
At 01:22 PM 12/2/99 +0100, you wrote:
>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
>> 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 ...
uhh guys, the thread on Web Architecture, to which essentially no one replied,
was addressed to exactly these issues. Oh well, it is good to see the issues
A small rewrite to fit this thread.
Layer Purpose Example/Description
3) application e.g. [PICS], [OCS], [RSS]
2a) Resource Description Framework Dublin Core
Describes a particular choice of
data structures (property lists)
to be used by applications
2b) Other Application Oriented Data Structures (or objects)
2) Object Definition Standard way to represent objects
1) ML ML used for data serialization
and transport and IDL
I left out namespaces for the moment.
The basic problem remains a lack of a clearly articulated vision of what
the web of the future could/should be.
Bob La Quey
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev