[
Lists Home |
Date Index |
Thread Index
]
On Thu, 13 Feb 2003 12:25:28 +0000, Sean McGrath
<sean.mcgrath@propylon.com> 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.
|
