Comments on: CDL’s XTF as a Front End to Fedora http://dltj.org/article/xtf-fedora-1/ We're Disrupted, We're Librarians, and We're Not Going to Take It Anymore Wed, 08 Feb 2012 17:48:39 +0000 hourly 1 By: Search - IU Digital Library Program Confluencehttp://dltj.org/article/xtf-fedora-1/comment-page-1/#comment-5848 Search - IU Digital Library Program Confluence Sat, 21 Oct 2006 13:22:43 +0000 http://dltj.org/2006/08/xtf-fedora-1/#comment-5848 <!--%kramer-ref-pre%-->[...] Peter Murray has written a series of blog articles on combining XTF with Fedora. [...]<!--%kramer-ref-post%--> Kramer auto Pingback[...] Peter Murray has written a series of blog articles on combining XTF with Fedora. [...]

]]> By: Martin Hayehttp://dltj.org/article/xtf-fedora-1/comment-page-1/#comment-2986 Martin Haye Tue, 22 Aug 2006 20:42:37 +0000 http://dltj.org/2006/08/xtf-fedora-1/#comment-2986 For the dynaXML side of things, I think it will be pretty straightforward to implement (in Java) a DocLocator that downloads a document from Fedora and creates a lazy file. The existing DefaultDocLocator would be a pretty good starting place.Issues for the long-term would be timestamp checking to update the lazy tree when the source document changes, and flushing long-unused lazy tree files to bound disk space. Though nowadays, with disk sizes growing so quickly, perhaps the latter isn't even a concern.For textIndexer, there is actually a straightforward Java API. In the XMLTextProcessor class, see these methods: open(homepath, idxInfo, clean), close(), queueText(idxSrc), processQueuedTexts(), removeSingleDoc(), and optimizeIndex().You'd just need to write a driver program that creates an XMLIndexSource for each source document and passes it to XMLTextProcessor. XMLIndexSource needs a Saxon InputSource, and the file path is optional.One downside of this route is that it won't take advantage of the textIndexer's incremental facilities. If you wanted incremental indexing, you'd probably have to roll your own to some extent. For the dynaXML side of things, I think it will be pretty straightforward to implement (in Java) a DocLocator that downloads a document from Fedora and creates a lazy file. The existing DefaultDocLocator would be a pretty good starting place.

Issues for the long-term would be timestamp checking to update the lazy tree when the source document changes, and flushing long-unused lazy tree files to bound disk space. Though nowadays, with disk sizes growing so quickly, perhaps the latter isn’t even a concern.

For textIndexer, there is actually a straightforward Java API. In the XMLTextProcessor class, see these methods: open(homepath, idxInfo, clean), close(), queueText(idxSrc), processQueuedTexts(), removeSingleDoc(), and optimizeIndex().

You’d just need to write a driver program that creates an XMLIndexSource for each source document and passes it to XMLTextProcessor. XMLIndexSource needs a Saxon InputSource, and the file path is optional.

One downside of this route is that it won’t take advantage of the textIndexer’s incremental facilities. If you wanted incremental indexing, you’d probably have to roll your own to some extent.

]]>