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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: RE: Repository use cases::retrieval()


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


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

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.

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.

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