On Fri, May 30, 2003 at 05:38:23PM -0700, Kip Hampton wrote: > John Merrells wrote: > > >The query language is XPath, which can be used to select matching > >documents in a repository, or to select nodes from the selected > >documents. > > Just off the top of my head, I can think of several cases and ways that > dbxml and AxKit could be useful together: > > 1) Replacing (or adding to) the XML content stored on the fliesystem. > Here, an AxKit Provider would be the mechanism used select data from the > dbxml data store for processing and delivery to the client. As Tod said, > the the open issue is how a given request URI is mapped to a given set > of data. A one-to-one mapping between, let's say, the request's > path_info and the internal dbxml document name is easy, but then you > lose the ability to combine data from different containers/documents > (which is a huge loss, obviously). Is there a way to set up more robust > mapping between a given URI and set of XPath statements that would be > used to construct the content that is a) generic enough to meet a > significant set of common use-cases and b) not so complex in its mapping > definitions that it creates a barrier for casual usrers? I'd like to > hear more about peoples' expectations...
I have some very large documents that I preprocess and split up into smaller documents to keep things light. It seems with dbxml I wouldn't have to preprocess and just query the parts of the document and still keep things light. > > 2) An XSP and/or SAXMachines Taglib. > The interface for this seems like it would be more obvious. For example, > with the taglib installed and registered (or appropriate SAX Filters > included in the processing chain) the following: > > <dbxml:query select="/some/xpath/statement"/> > > would be replaced by the markup returned from the query contained in the > select attribute. I can see how something like this could be damn handy > for a lot of people. Thoughts anyone? xinclude + xpointer? <xi:include href="/path/document.xml#xpointer(//section)"/> > > Another thing to consider: dbxml containers can have arbitrary bits of > metadata-- I can see cases where entries in that metadata could be used > to define which style(s) AxKit will apply when transforming the content > for delivery to the client (a less polluting alternative to in-document > xml-stylesheet processing instructions, if nothing else). How else could > we abuse^H^H^H^H^H, er, take advantage of this extended metadata to make > things cooler for users of both AxKit and dbxml? Storing the cache in dbxml seems like a natural fit, especially with the metadata. Has there been any more talk/work on a new Cache system? Could this help with the incremental caching ideas? Someone on #axkit-dahut was talking about a dbxml provider and cache module a few month ago ... has there been any progress? Ed. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
