Lists Home |
Date Index |
- From: "Paul Butkiewicz" <email@example.com>
- To: <firstname.lastname@example.org>, <email@example.com>
- Date: Sun, 3 Jan 1999 13:33:36 -0500
>The tutorial by example does raise the question often asked
>and seldom answered by the XML community: precisely
>why should developers choose this approach (XML
>and Java objects) over a commercial relational
>database given the ease by which this example can be done
>using standard SQL, script, and an
>HTML browser? As this same question occupied
>many of the venerable CALS developers for some period,
>have any new answers emerged for XML?
>The only one I can think of is that we didn't have
One important point is the scale of the implementation and the intended use.
If you were developing a system for a company that was entirely
Windows/Microsoft based, you probably wouldn't bother with XML, HTML, java
or any of that --- the simplest solution might just involve Visual Basic and
ODBC calls to a database or DCOM calls to an application server. (Unless
you're trying to retain programmers by using "cool technology" or have a CEO
that insists you build it around a corporate intranet because that's what he
reads about in the newspaper :) And you would have all of your
documentation in hand and people who needed it could get it.
If you were trying to do this on a (big) enterprise-wide level or toward a
global audience, the sort of arena where this web thing comes in handy,
trying that approach might involve trying to make ERwin models available
globally, publishing application server interfaces, somehow publishing what
stored procedures are available, and possibly letting folks know what
database or variant of SQL is being used.
Or you could just publish a DTD and a bunch of XML and those clever folks in
the Phoenix office or in another organization that wants to access your data
would probably be able to figure it out.
>The primary answer I give this question is flexibility, though there is a
>significant cost in efficiency. XML documents can easily hold structures
>that make relational databases choke. . . .
I would love to see an example of this.
As for the phone book example, perhaps XML works much better (even well) in
making this data avilable if all of the data doesn't exist in one document.
I know that if I'm personally searching through a book for something, I'll
usually follow a URI (my almanac calls it a "General Index". There's also a
"Quick Thumb Index") to an approximate location and start iterating from
there, rather that just starting from the beginning and approaching the
whole mass of the data as a single document (although in the almanac case
this often makes for interesting reading, I'll usually get hungry or sleepy
at some point and never find the data I was looking for :).
Happy New Year,
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)