xml-dev - Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)

[uche.ogbuji@fourthought.com]

> > 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?


-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org



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