[
Lists Home |
Date Index |
Thread Index
]
I'm not sure what point I'm missing. I'm asserting that schemas are
commonly and usefully employed to bootstrap binding from untyped XML
to programming objects, and this use case for schemas is reasonable
even if XSD is not. You mention JAXB 2.0, which increases the
fidelity of the XSD < - > Java mapping, so I'm not sure what we
disagree about in terms of the direction of the tide. I certainly
wouldn't argue that XSD is the *only* way to do databinding, just that
databinding is a use case for schemas that can't be avoided. For
example, Apache Commons Digester provides a rules-based rather than
schema-based way to do data binding, but the FAQ makes VERY clear that
it is meant for simple scenarios where performance is not critical.
Things definitely do get dicey in that the round trip from one
databinding technology -> XSD -> another databinding technology -> XSD
-> the original databinding technology is error prone. Whether that
indicates problems in XSD, immaturity of the databinding technologies,
or just the harsh nature of reality is not clear to me.
I'd take some issue with "strong, static typing is brittle and
inflexible; and to see that systems that solve real problems need to
be a lot more open and flexible". Systems that solve SOME real
problems need to be more flexible, but flexibility creates new
problems of its own, especially in the realms of reliability and
security at a reasonable cost. The fewer the options, the easier the
decisions that developers must make can be and thus the more reliable
the code tends to be and the more rigorous the testing / auditing can
be for a given cost. You probably don't want anyone at the bank being
creative and flexible with how they format the information that goes
into complex financial transactions. But by the same token, you
probably DO want them to support lots of flexibility in how you as a
consumer interact with them. Interesting tradeoffs...
On 10/13/05, Elliotte Harold <elharo@metalab.unc.edu> wrote:
> Michael Champion wrote:
>
> > XSD has few loyal friends in the
> > trenches AFAIK, but the idea of having to deal with the hassles of
> > comparing dates, floats, etc. as strings, or tediously converting them
> > to programming language datatypes one by one, and learning XPath/XSLT
> > in order to handle arbitrary variations in data structure, is even
> > worse. In my heart of hearts I think they would be better off if they
> > *did* learn all this wonderful, open, XML stuff, but the fact seems to
> > be that they would prefer to just map it to objects as quickly as
> > possible. "It's a price in an invoice, don't make me deal with it as
> > a node in a tree!!" is their complaint against untyped XML. By binding
> > to objects, they get the benefits of XML
> > (vendor/platform/application-neutrality, the network effect, etc.)
> > without the costs of diving into all the confusion and complexity that
> > we somewhat happily wallow in.
> >
>
> This completely misses the point. Weakly typed XML can absolutely be
> bound to objects. The difference is that everyone gets to choose which
> objects to bind to depending on what makes sense to them in their
> environment. Strong typing says everyone has to use the same objects,
> and interpret the dates/floats/integers/etc. in exactly the same way.
> But we aren't the same. We aren't using the same platforms and tools. We
> don't need to do the same things. We all need different, unique classes
> and data structures. XML lets us have that.
>
> Most data binding frameworks still believe in the Highlander principle
> of schema design (There can be only one!) but a few are starting to move
> in the direction of allowing a lot more local flexibility because
> they've been around long enough to realize that strong, static typing is
> brittle and inflexible; and to see that systems that solve real problems
> need to be a lot more open and flexible. JAXB 2.0 is a big improvement
> on JAXB 1.0 in this respect. Apache Commons Digester is also a very
> interesting approach. Neither is fully there yet, but it's obvious which
> way the tide is flowing.
>
> --
> Elliotte Rusty Harold elharo@metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
>
|
