[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: building an object model of a XML schema

• From: Jeff Lowery <jlowery@s...>
• To: "'Thomas B. Passin '" <tpassin@h...>,"'xml-dev@l... '" <xml-dev@l...>
• Date: Sun, 15 Jul 2001 12:31:03 -0700

Tom Passin inflames:
 
> What, you know how to specify an "optimal" physical model??  I always
> thought there wasn't any such thing in the abstract, that it was always
> relative to some context or requirement.  Code size, speed, database
> size,
> etc., etc.

I always seem to get into trouble when I use the word "optimal" in a
sentence. So let's leave it at "storage representation definition". This
would include "types" that have commonly understood properties and
behaviors. Of of the top of my graying pate, I would include arrays, sets,
hash maps, dictionaries, trees (various varieties). Can one identify enough
of these to make useful suggestions for efficient object representations of
hierarchical data models? Does the average OO (or possible other)
programming language have implementations of these 'ready-made'? Java and
C++ do, at least.

If the answer is that a data model, such as one defined by an XML Schema,
can only be efficiently mapped to program code by craftsman who customize
each and every application based on such a data model, then somethings wrong
somewhere. On the other hand, if such efficiencies can be identified up
front (such as through a JAXB binding schema, for example) so that code can
automatically be generated to encapsulate them (or at least 80% of them), I
think we've eliminated some programming jobs at the gain of economic
efficiency.

Now, there's the BIG PICTURE guys who say "We can do all that and a bag of
chips." Use a big modelling methodology that encapulates every model,
method, class, datatype, syncronization protocol, etc., etc., etc., -- and
you will, at the push of the button, have a complete system up and running
in not time. Well, I've worked on teams that foisted those kind of tools on
developers, too, and our reach exceeded our grasp (and I don't see anybody
else doing a whole lot better, at least in my narrow neck of the woods). 

This is not a new problem. Database application developers have had to tease
data out of the relational bottle and stuff it back in again for the benefit
of object-heads who loathe and fear SQL (rightfully so, IMO, but I'm
mercenary enough to cope with it).

Now we have a data representation, called XML, and a nifty (and I do mean
nifty) schema language for enforcing constraints on that representation to a
'T'. And without too much imagination, you see that XML Schema types match
pretty darn well most of the time to class types, and that XML containment
structure matches pretty darn well to hierarchies of objects. And you start
to wonder, as many have, if one can be generated from the other. The natural
path for XML Schema seems to be to generate the class definitions, rather
than the other way around, because the type constraints are very detailed
yet limited in the ways to express them. 

So I look around and see if I'm nuts or something for thinking this, lo and
behold, I have company. There's JAXB, Exolab, Castor, and various other
iconoclasts actually doing the work I'm only idly thinking about (as usual).
But there's a problem. The class definitions generated are not always
efficient. I think it was David Cleary who's been skeptical of this idea
from the get go. I thought he was being a pessimist, but it looks like he
was right. 

So you have to add some more information. If you have to add too much
information, then your costs outweigh the benefits and we're back to
hand-coding glue between XML and JAVA or C++. That reeks. 

Moreover, it seems a shame, since I know, buried within every class
hierarchy, is a data model. How do I know this? Becuase I can persist the
state of any object in a database or in XML. But I have yet to see a
language that allows declarative constraints to be defined (someone will
show me one, I know) for data members such that, for example, I don't have
to do cardinality checking operationally in every mutator method. Of course,
the other advantage is that data model would now be separable (loosely
coupled) from the methods that operate upon it, yet most constraints would
be preserved should another set of methods get bound to it. But that's
preaching to the choir.

There seems to be more ranting than articulating going on in this message,
so I guess I'll stop now that I'm out of breath. Maybe I could be another
Fabian? Another Fabio, at least.

Oh, wait, there's more:

> I'm guessing that you mean "optimal" given some particular context or
style
> of data model.  In my view, a proper conceptual data model is really in
the
> problem domain, and so is orthogonal to consideration of software design
and
> optimization.  Do you see it differently?

I would agree with the orthogonality arguement for the general class of
programming languages, but not OO/XML mappings. I think there's to much
similarity there to be politely ignored.

• Prev by Date: Re: building an object model of a XML schema
• Next by Date: RE: building an object model of a XML schema
• Previous by thread: Re: building an object model of a XML schema
• Next by thread: RE: building an object model of a XML schema
• Index(es):
  • Date
  • Thread