Must databinding imply tight coupling? (was Re: New tool for handling XML in Java)

On Thu, 13 Feb 2003 12:25:28 +0000, Sean McGrath 
<> wrote:

[I usually quickly regret publicly exposing my stupidity when I
disagree with Sean, but I will throw caution to the wind :-)]

> [Samir Kothari]:
> > For the first time, developers can gain a familiar and convenient Java
> > object-based view of their XML data without losing access to the 
> richness of
> > the original, native XML structure.
>
> This makes perfect sense in an object world view but is a source of 
> dispair for those
> of us who see XML as a markup language not an object serialisation 
> notation.


That's been my [personal] reaction to the various databinding proposals up 
until recently, i.e. those that simply take a schema and create Java code 
to access the elements/attributes as fields in a business object.  Adam 
Bosworth makes a pretty good case in 
http://www.fawcette.com/xmlmag/2002_12/magazine/columns/endtag/ for why 
this is desireable:
Only hardened XML geeks would prefer (stealing Bosworth's example)

Tree t = ParseXML("somewhere");
PERatio = number(t.getmember(
"/stock/price"))  /
(( number(t.getmember(
"/stock/revenues") - number(
t.getmember("/stock/expenses"))

over

XML x  = getxml("somewhere");
PERatio = x.price/( x.revenues - x.expenses);

And that's assuming XPath!  The raw DOM or SAX code would be considerably 
more tedious.

The downside to conventional databinding is basically Permathread #x (hmm, 
we really ought to catalog them) -- rigid schemas imply a tight coupling 
between the data formats of producers and consumers of XML, and if things 
change (or can't be agreed on in the first place, or the consumer needs 
only a small subset of the information, or the community ignores the 
details of the "authoritative" schema ...) then the databinding solution is 
fragile.

I'm not sure what BEA's tool does here, but *in principle* one might have 
the best of both worlds:  Use XPath or XQuery to define the patterns to 
look for in input data rather than simply assuming a shared schema (thus 
loosening the coupling), but *generate* code that uses those patterns to 
map input data onto application objects (thus making life easier for the 
non-geeks).

Maybe I'm trying to reconcile my irreconciliable desires for loose coupling 
/ document-centric XML applications on one hand and ease of use of XML 
technologies by ordinary programmers on the other.  I dunno, but I don't 
see efforts such as BEA's to be either "crap" or a source of despair.  We 
need to be finding a middle ground between "XML is an object serialization 
format, trust the Wizard and don't worry your little head about it"  and 
"XML is a meta language that can describe anything, and if you learn to 
think at two or three levels of abstraction above what you've done all your 
career, it is really useful."    I realize that most people on this list 
are perfectly comfortable thinking at two or three levels of abstraction 
above the level at which the typical VB programmers of the world operate, 
but this stuff has got to be useful to them if it is going to make a real 
long-term difference.