Lists Home |
Date Index |
- From: David Megginson <firstname.lastname@example.org>
- To: "'email@example.com'" <firstname.lastname@example.org>
- Date: Fri, 29 Jan 1999 10:22:05 -0500 (EST)
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 Megginson email@example.com
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)