Lists Home |
Date Index |
- From: firstname.lastname@example.org
- To: Paul Prescod <email@example.com>
- Date: Mon, 08 Feb 1999 19:58:54 -0700
> > I don't think it makes sense to build a business-object model on top of DOM,
> > but I do think it makes sense to define an exchange protocol that selializes
> > objects to XML representations using DOM as a programmatic interface.
> I agree. I'll point out, however, that it is REALLY EASY to generate XML
> directly. In your opinion does the DOM actually make it easier?
> If you use a "reverse SAX" interface (instead of a DOM-building interface)
> then you could pipe together data consumers and if any of them ever needed
> a DOM, it could build it.
I think it depends on several things:
1) The language in which you're implementing the serialization. In Python,
with its rich string handling and dynamic programming features, I might prefer
to generate XML directly, but in Java or C++, I might prefer to go through DOM.
2) Your environment. I have often ended up using DOM because I'm working in a
distributed environment, using CORBA, and it makes it very easy and natural to
just call DOM interfaces across the ORB as a sort of serialization. 4DOM
actually came about because we already had a CORBA-ready API for manipulating
HTML-based views of an object across an ORB, and we wanted to expand this so
we could take advantage of XML. The W3C's work provided a natural
spring-board. Of course, on the same machine, it's probably easier and faster
to use an events-based approach (SAX and your "reverse SAX", something like
which I remember having cobbled together, in fact).
3) Your object structure. Some of the advocates of DOM as the universal
object-model note that they are working in domains that fall into natural tree
structures. In this case, there is clearly less impedance mis-match in using
the DOM interface, and one can even smartly use the Builder pattern to connect
abstraction to serialization interface if he's _very_ confident in the quality
of the design. Alas the reality is that such natural tree-representations are
not as common in real-life as some would have us believe. Business object
models, as you rightly pointed out, more often take on the pattern of a graph
(bi-directional, cyclic, and all those other tree-killers).
> > I think it also makes sense to use the DOM to develop a user-interface layer
> > for such objects, possibly using the same WDDX or XML-RPC mappings in
> > association with a set of style-sheets (although this is just one of many
> > possible mechanisms).
> Yes, it makes sense to use XML as an "interchange language" between your
> business objects and your user interface. On the other hand, if that
> interface is meant to be editable the information loss associated with
> "dumbing down" to XML may not be acceptable.
I agree with this, but in my opinion, user-interface hasn't caught up with
object-modeling practice in any case. XML does cause "dumbing-down", but not
much more than other user-interface options. How does one go from a typical
object model, with as many degrees of freedom as most object models entail, to
presenting a linear form as an effective editing interface? I don't claim to
have any visionary ideas here, but I get the sense that the next big
breakthrough (or hype-engine) in the object community will have to be at the
fundamental UI level. Or did it already pass us by in the (over-wrought)
forms of OpenDOC or Pink?
FourThought LLC, IT Consultants
Software engineering, project management, Intranets and Extranets
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)