OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML aggregation question?

Thanks for the discussion so far.  Mostly just listening and trying to
absorb the collective experiences.  One specific point below, however...

On Sun, 2006-08-27 at 14:23, Robert Koberg wrote:
> >> So I have been sticking with the filesystem,
> > 
> > Yes - I am a great believer in the filesystem as a simple database engine.
> > 
> >> Apache's Lucene for indexing
> > 
> > Yes
> > 
> >>  and CVS or Subversion for version control.
> > 
> > Yes
>  From the code point of view, it works so nicely. Easy to develop on a 
> local machine just by doing a server commit and local update. Easy to 
> change on the server by doing a local commit and a server update (and 
> probably an Ant build). Same for content/metadata if necessary to change 
> in different locations -- just need to run a lucene update to keep the 
> UI experience in sync.

Well, herein lies the crux of Mike's comments about if you don't start
with a DB that's likely what you'll end up building to some degree.  If
I was managing "real" documents or providing more of a content
management system, this would more than likely work.  However, I want to
be able to "slice and dice" my XML instances to provide different views
or ways of accessing the instances based on values of specific
attributes or elements.

As I said originally, if I didn't care about wanting to keep the data in
XML as the "native" format of the system for easy editing by hand (in
particular for me, using vi on Linux) as well as providing more GUI
based view/edit capabilities via a Web-based interface (most probably
using XForms), I'd just forget about the XML aspect and it would be a
"traditional" RDBMS application.

Based on all the comments thus far as well as reading some of the
articles/documentation on eXist, it would seem that an XML database is
really the only viable choice if I want to keep my data as XML and still
provide aggregated views across the instances based on values of
attributes (or other expressions using XPath and/or XQuery).

If I went with the "traditional" RDBMS approach, I'd be spending most of
my application's CPU cycles going to and from XML, so the benefits of
being able to use SQL to pull the list of instances really doesn't seem
worth it.  At the moment, I'm leaning towards trying eXist to see how
well it'll work for what I want to do.

Again, thanks for all the discussion so far.  There's likely to be some
additional comments during the week, so my decision's far from set in
stone yet.


Andrew S. Townley <ast@atownley.org>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS