RE: Does DASL need to support structured queries?

<alan>
Jim Amsden wrote:
"... in order for DASL to be useful and effective, it must
support structured searches."

I disagree. It's obvious that that's not true.
For example, neither SQL nor SQL 92 support structured
data, let alone structured searches, and SQL is very widely
used. Years of experience have shown that SQL is both useful
and effective for many applications without the ability to
define or query structures. Similarly, DASL would be very useful
for many queries (including the most common queries) without
the ability to query structures. (Of course, that doesn't
imply that we should not add that ability in the future. I
think we should.)
</alan>
<jima>
The S in SQL stands for Structured Query Language. A table captures this
structure and its format is defined by a schema. So I guess those years of
experience support my claim. SQL is exactly analogous to XML and DTDs. But
since XML is a tagged language, it carries an instance of the schema with
each document. So it is very easy to formulate queries using tag and
attribute names. That just what XSL patterns are. No DTD is required to do
these queries. The DTD is only required to validate the document if needed.
</jima>

<alan>
"So the same mechanism can be use to search structure properties
since they are XML elements (on the wire) too."

I disagree with the implicit assumption behind this statement.
The assumption is that the serialization format (i.e., XML)
is somehow equivalent to the data model, or somehow forces
the data model to be the same.
As far as searching, it is irrelevant what the serialization
format is. Multiple different protocols could be used to access
the same data source if that were desirable. A binary
serialization format would be much more efficient than XML,
as one example. What matters for query is the data model.
</alan>
<jima>
The only assumption is I'm using is that if you have a web resource of type
text/xml, and you have webdav properties returned by a server somehow as
text/xml which is what PROPFIND is specified to do, you can use the same
query mechanisms on both. Again XSL is a good example of such a thing. I
have used it to render the results of a PROPFIND. I don't see what this has
to do with serialization, data models, etc. They're just XML documents
available to a client.
</jima>

<alan>
XML all by itself is not a data model. Conventions would have
to be added, starting with data types. Then there is the
whole question of metadata, central definition of data
(as opposed to client program definition of data),
administration of database schemas (retrieving and updating
metadata), merging metadata when querying across multiple
data sources, etc., none which are issues that XML or any
other serialization format was intended to address directly.
</alan>
<jima>
XML is a language for describing structured data, and XML DTDs specify what
constitutes valid structure. No it doesn't support primitive data types,
and a lot of the other functions of a traditional DBMS, but client and/or
server applications are free to provide these capabilities on an XML base.
DCD and other DTD replacement proposals are also addressing some of these
issues.
</jra>

<alan>
There are pros and cons for every design choice. For example,
XML is a very good format for certain types of text based documents,
and is a very poor format for others (e.g., image documents).
Similarly, XML plus extensions wouldn't be the best property
model.
</alan>
<jima>
The real power of DASL will come from being able to search for documents
having properties or content that is more than just a regular expression.
This restriction is what makes web searching and crawling so difficult with
HTML. With XML, we'll have the real business data and meta-data (in WebDAV
properties) to search on and can make much better searches. I think DASL
should address this and not require special cases for what it can search.
Alan Babich

Received on Thursday, 19 November 1998 11:57:30 UTC