Repositories: From Argument to Architecture

[Simon St.Laurent]

The What is XML For?  and Is XML dead? threads have done a pretty good job
(I think, anyway) of advancing us from griping about XML isn't a solution
to looking for tools that would make it a better solution - in this case,
repositories for document storage.

I've downloaded Frontier (returning to my earlier roots in Mac land, to
some extent), I've been following Excelon and POET, and I'm reasonably
hopeful about the future.  Still, my brief explorations (especially brief
in the case of Frontier) leave me with as many questions as answers.

I'd like to see an XML repository be as Web-like as possible, though I
realize not everyone gets quite as enthusiastic about this as I do.  

Basically, it would mean that I could retrieve XML documents from it using
HTTP, using familiar structures like URLs.  I'd love to see support for
XPointer queries on that same server, allowing me to pull out fragments,
and another standardized query language (XQL or whatever) that would let me
do more general searches.  Ideally, I'd like to be able to add SAX filters
and DOM processors between the content and its transmission as a
fully-fledged XML document to the outside world, but at its foundation I'd
like it to look like a vanilla Web server, whatever magic it's doing
internally.

When it came time to add documents, I'd like something as simple as FTP:
upload file to a certain location, and it's retrievable from that location.
 The ability to modify and store document fragments would be a significant
advance, making management and editing a heck of a lot simpler than it is
now.  (I love making changes in 350K HTML files and FTPing them to their
home again and again.)  Versioning and security would be great as well.
(Maybe WebDAV is a better framework for this.)

The management layer is a whole other set of things to consider, and I
think I'll let vendors ponder that, but again, I'd love to see it managed
via the Web.

'Repository-in-a-box' is what I'd call this, and I'd love to see the same
architecture (with different back ends) implemented in lots of sizes and
scales.  A lot more standards have to settle before there's much chance of
implementing such boxes, but I'd love to see folks discussing what it would
take to create such a beast and make it a commodity product, not something
that takes an army of programmers and gallons of Jolt Cola.

I've been tinkering with this concept when I can find the time, but it's
way beyond the capacities of a single author/developer working from home,
no matter how many free DB downloads I can scoop up.

Tim Bray wrote:
>Just to be specific; are you claiming that I can pump a terabyte or
>so of densely structured XML text with mixed content and so on, into
>Frontier, without having to do all sorts of hand-mapping elements and
>attributes to native data structures, and then handle many complex-search 
>transactions and a few granular-update transactions per second?

All of the work I described above would have to be built on something close
to what Tim described here.

Simon St.Laurent
XML: A Primer / Building XML Applications (March)
Sharing Bandwidth / Cookies
http://www.simonstl.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)