[
Lists Home |
Date Index |
Thread Index
]
At 01:43 AM 21/07/2002, Mike Champion wrote:
>But seriously, I interpreted Robert Leftwich's post as an honest inquiry
>about a hard problem:
That's what was intended. I apologize for any semblance of trolling and I'll
try to be more specific.
By way of explanation I draw a parallel to the early C++ days where there
were a number of competing frameworks, ranging in complexity from simple
collection classes thru to complete application frameworks and the perennial
problems were - which do you choose, how much commitment do you make to the
one vendor and is that the best long term choice. Depending on how early you
came to C++ you might not have had the choice, you had to build your own,
there was nothing else. Later you might have decided that the effort in
maintaining those home-built solutions was too great and replaced them with
something (possibly) more robust, but certainly tried and tested in a larger
arena than your own.
I an viewing the current state of xml as similar to this. There is a
standardized core that provides sufficient power to tackle most relevant
problems. But in order to do so you have to do a lot of 'rolling your own'
solutions. There exists a number of third party 'libraries' that have
tackled the problem of adding higher level functionality in different ways.
The difficult choice for developers is which, if any, of those approaches is
the best one, the one most likely to be worthy of long term investment.
So the questions then are :
1. Is this the correct forum for this sort of discussion?
2. If so, is this a valid parallel?
3. If not, what is the current state of play in xml development?
4. If so, are there any articles/papers/etc that discuss the relative merits
of the competing approaches (as I cannot find much relevant information via
Google, et al)?
Respectfully
Robert
|
