|
First, let me thank all the developers of ASPSeek
for a fine product. It is, by far, ahead of the rest. In my use of
ASPSeek I have come to the idea that XML support in ASPSeek would be a very
valuable feature, allowing any application to make use of the search
results. I came to this idea as I was wrapping the search output with my
existing web site framework (written in PHP) and deciding that it would be 10x
easier to manipulate the output if it were abstracted from the formatting /
templates in ASPSeek. PHP (as does any programming language) has libraries
supporting XML parsing and XSL transformations, making it very to parse the
output and use it however you need to or simply to write an XSL template to
display the output. So I think that XML would be perfect for abstracting
the search results from the actual formatting.
Why would
ASPSeek benefit from native XML output capabilities?
- One could query the search engine from inside an
application to perform a search of a knowledge base for that application
and display the results, inline, directly inside that
application..
- Easier output to other formats like WAP/WML,
RSS/RDF, HTML, or any other format you can dream up.
- Syndication. This is a big reason for my
proposal. I'm running a search engine where the content needs to be
available to dozens of other web sites where they can parse the results on their
own server. Using XML and an XSL stylesheet they can do the search and
parse it in under 10 lines of PHP code and a simple XSL template.
How should it be implemented?
My original thoughts on this were to replace the
means of outputting HTML now to replace it entirely with XML with XSL
transformations. Instead of s.htm you'd be able to define a
cleaner XSL template. Overall it would reduce the complexity and code
in ASPSeek a lot, as the only code you would need is the function calls to the
XSL transformer to do the processing.
Then I got to thinking about another option.
ASPSeek already has a search daemon that performs and returns the results to
s.cgi. Why not open it up to other frontends? searchd would begin
supporting the output of XML (in addidion to what s.cgi wants) for other
frontends to either just give the user the XML output to do what they please or
to do the XSL transformation. Thus, both s.cgi with the html templating
and XML output would work and be seperate. (I still prefer the first
option).
Why not use s.htm to output XML instead of
HTML?
This is a possibility, however, not exactly
suitable. Since XML is not a formatting markup language, it's pointless to
manipulate s.htm to output proper XML. In addition, since XML is picky
about valid characters, the current implementation of s.htm would require more
$XX variables to provide variables like $DU with &'s substituted for
&'s.
Why XML at all?
By supporting XML, ASPSeek will enter the world of
applications speaking to applications. Any application that can parse XML
will be able to interface directly with ASPSeek, putting ASPSeek again *far
beyond* the rest of the search engines out there. I know of no other
search engine that supports this right now, even though this is a *perfect*
application for XML.
Please, I'd love to hear your comments. If
you're interested in such a feature, please post your comments here.
Justin
|
