[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Repository use cases::retrieval()
Terry: I must apologize. I didn't read your previous email thoroughly. My Bad. There is no formal White paper or description other than what is on the site. The information on the web page, in conjunction with the code, is fairly straightforward assuming you are a Perl-monger. We sometimes forget that not everyone uses Perl ;-) Accordingly, here is the elevator pitch version: XQI: XQI is an extremely simple machine API. A client opens up a socket on their local machine and issues a well-formed XML-syntax query directly to a port on the goXML.com server, which is always listening. The XML stream, if constructed properly as per the instructions on the page at http://www.goxml.com/xqi.htm , then invokes an RPC which queries the index. Additional functionality also enables XQI streams to insert XML data into the queue for spidering and indexing. The results are sorted by a relatively sophisticated algorithm which considers how the context sensetive character data relates to parent and ancestor elements as well as HTML style relevancy algorithms. There is no DTD for the XML stream. If it is improperly constructed, as error will be returned to the client application. We have not thoroughly implemented commercial spec error handling routines at this time. Instead, we rely on standard http error codes. It would probably be a good idea to build this functionality into future query daemons. Please note that the current deployment of GoXML.com only indexes XML syntax data. Once the server has assembled the results, a return XML stream is sent back to the client. A client application parses the incoming stream and then takes appropriate actions. envisioned -> a "get" command could be issued to retrieve the XML data from the physical location addressable via an HTTP URL. Alternate configurations are also possible. No secondary functionality is currently included in the free code available on our website. Although the XQI was built almost one year ago on a whim, I felt it was possibly an important step in conjunction with an XML Search Engine becuase it really supports automation of the query process. The XQI and index would obviously have to be re-tasked specifically for the RegRep deployment model. Our goal is to analyze the search requirements for RegRep's and provide a functional solution. We can allow interested parties to experiment by creating smaller "channels" on the GoXML.com which will accept and index XML data. A query can then be performed on the specific "channel" without results from the general index being included in the result subset. <IMHO> The model of a Registry handling a query to find information in a specific repository will work well in the context of a one to one relationship, however, if someone wishes to query multiple (ie: non-synchronized) Reg-reps, an application to perform those XML searches may be desireable. </IMHO> If anyone has any further questions, I would be happy to answer them. Duane Nickull XML Global
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC