<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid468F109E.1070100@borwankar.com" type="cite">
<pre wrap="">One huge problem with using "standard SQL" is that we will either have
to point to an implementation of a parser - say MySQL ( historically
weak standards compliance and has non-standard extensions that people
now think are part of SQL) or Postgres (historically much stronger SQL
compliance) or build one so that it is the "standard Atlas SQL" one. We
will need to do this rather than point to a document such as the SQL
standard definition because no mature widely used implementations exist
that are 100% standard.
</pre>
</blockquote>
A solution to solving how to parse SQL would be not to parse it at all.
<br>
<br>
We could consider the option of putting in a 'stored procedure' capable
sql database as a requirement - and simply implementing<br>
the vital parts of the broker as a collection of stored procedures or
serverside code (maybe in java?). <br>
<br>
<br>
Modern portals and document archives also offers us a challenge with
searching inside structured documents - so my suggestion<br>
is that we also offer support for searching in structures. <br>
<br>
We could start with describing a query language for Content Only (CO)
based on SQL - and then build upon CO to add support <br>
for Content and Structure (CAS)<br>
<br>
Andrew Trotman has described a basic query language NEXI supporting
this here : <a class="moz-txt-link-freetext" href="http://www.cs.otago.ac.nz/postgrads/andrew/2004-4.pdf">http://www.cs.otago.ac.nz/postgrads/andrew/2004-4.pdf</a> <br>
<br>
I think the main contribution of the CAS part of our query language
should be support of using XPATH from inside the query language.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<font size="-1"><span class="a"></span></font><br>
</body>
</html>