Spitting out XML (was RE: Will XML eat the web?)

[David Megginson]

Matthew Sergeant (EML) writes:

 > 	The point is - XML fits our problem domain perfectly
 > well. It's just not fast when parsing directly. Ultimately we may
 > have to turn the architecture on it's head - store in a database
 > (relational or OO) and transmit XML to the client. If they want to
 > edit the XML by hand, transmit some to them, and parse the results
 > back into the database. This will be a disappointment to me, but
 > not the end of the world.

Why would you be disappointed if you were following best practice?
This is *exactly* the right way to use XML, at least in the data
world.  XML is designed to be an exchange format that allows different
systems to talk to each other; it does not dictate how those systems
should deal with the information internally.

Or, in DB speak, an XML document will usually represent a view of a
database rather than the database itself (unless you're doing a dump
and restore or a long-term archival backup).

Sometimes XML can represent the database itself if the database is
very small (i.e. it would traditionally be stored as a flat ASCII file
and batch-processed with Perl rather being stored in an RDBM): that's
not really what sales wonks would call an enterprise-strength
solution, but I (for example) use it for my own record-keeping.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)