RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)

[Michael Brennan <Michael_Brennan@allegis.com>]

> From: Nicolas LEHUEN [mailto:nicolas.lehuen@ubicco.com]

<snip/>

> I have been developing for my company a kind of compiler that 
> enables us to
> embed XPath expression in Java code. We can now access any 
> random piece of
> data within a document as easily as we would have done with 
> an object model,
> e.g. we can write things like invoice/line[5]/quantity in our 
> Java code
> instead of invoice.getLine(5).getQuantity().
> 
> We then developed a model in which business processes where 
> expressed in XML
> documents, possibly containing Java code fragments, that are 
> compiled into
> Java code, then into bytecode by a standard Java compiler. 
> The compilation
> is dynamic, and is done for performance purpose. If a 
> scripting language
> seamlessly integrating XPath expressions existed, we could 
> have used it.


Sounds interesting. I've been thinking along similar lines, lately,
including the desire for a scripting language that cleanly integrates XPath
(similar to the way XSLT expressions do).

<snip/>

> 3) We don't have to worry about object model mappings to/from 
> databases or
> XML ; all data is represented as XML documents. This is good, 
> because it
> saves a lot of code writing, and increases our flexibility. 
> The bad side is
> that non-textual data (e.g. numeric values) are not handled 
> easily. But
> that's something we plan to solve by implementing our own DOM.

Our system uses hierarchical data structures that kind of resemble a DOM
with data types. We didn't try to shoehorn our solution into a DOM, but do
use record structures that easily support an XML serialization format. These
structures are also mapped onto relational database structures; we don't try
to build business systems using 1 GB XML documents. And we have a
hierarchical query language (a sort of XML Query Lite, if you will) for
querying the persistence layer for hierarchical record sets.

Although we've taken different approaches, it sounds like there is some
similar thinking going on.

> 
> 4) This separation between data and processes is totally against most
> object-oriented practices. This is somewhat considered as 
> "bad", especially
> in France where people are very strict about it :). But in 
> fact if you take
> a close look at most EJB architecture, you'll discover that 
> processes (in
> Session EJBs) are usually separated from data (in Entity 
> EJBs), and that
> implementing business methods in data object is not an easy 
> task (not even
> speaking about evolution of the model).

You'll also notice in Sun's J2EE Blueprints white papers, they encourage the
notion of "value objects" that can encapsulate the state of an entity bean
in a lightweight object that permits interaction with EJBs at a more
coarse-grained level. These objects are just data.

The traditional OO notion of encapsulating data with the processes that act
upon them doesn't scale across the network. I used to do development with
Forte 4GL a few years ago. Forte (before being acquired by Sun) pioneered a
model for distributed systems development that Java vendors are only now
slowly waking up to. This model of lightweight objects that simply represent
some aggregated state that can be passed about among services was a dominant
pattern for development among Forte developers. The larger development
community seems slow to wake up to this notion and wean itself of blind OO
orthodoxy (except for those who have embraced XML).

> 5) Our greatest current problem is about schemas. As I've 
> wrote previously
> on this list, our approach raises a dire need of a simple 
> schema language,
> simple enough so that developers can write and use schemas 
> without having to
> read thousands of pages of specifications. We are currently 
> investigating
> languages such as RELAX NG, Schematron, Examplotron or a 
> custom language we
> named RESCALE to solve this problem.

We are in agreement there.