RE: Moving DASL to Experimental

It's been a while, and my memory is a little vague, but I assume you're
right that query schema discovery was removed in the interests of
expediency. Apparently I forgot.

                                      ---

There are two types of query applications: (1) specific applications where
knowledge of the properties are hard wired into the application, and (2)
meta applications that are designed to query any repository. 

The first type of application was expected to predominate, and doesn't need
query schema discovery, which was probably why QSD, although optional, was
dropped from the first draft and expected to reappear in the second. The
argument "Why burden this type of application with something it doesn't
need?" applies. The first type of application doesn't seem to have much of a
problem with data types on the client or the server. 

The second type of application, meta application, definitely has a problem
on the client, and would definitely benefit from query schema discovery.
Without query schema discovery, the second type of application can not check
whether the user enters illegal characters into numeric, Boolean, or
dateTime properties. In fact, the client can't even display a list of
property names for the user to choose from -- the user has to type in the
full property names if there is no query schema discovery. With no query
schema discovery, the client can not even check for typo's or spelling
errors in property names.

I would guess that you are most interested in the problems of the second
type of application.

                                      ---

I don't think putting data type information into the query on PROPERTIES is
all that useful. After all, the server knows or should know about the data
types of the properties it has stored.  I think that putting data type
information on the LITERALS in the query would be much more useful. (For
example, is "<literal>123</literal>" the integer 123 or the string "123",
i.e., what did the client intend?) If data types are put on the literals,
then even if the client doesn't know the data type of the property on the
server, at least the server will know how to coerce the literal to the
correct data type in cases where that is possible. (Some RDBMS's do, in
fact, perform such coercions, e.g. Oracle.) The client can force the user
choose what data type to enter for literals if it wants to, so the client
can know what the user intends for the data type, even without query schema
discovery. 

My suggestion of putting data types on the literals via attributes in the
literal XML element was rejected, at least partly because people expected an
XML committee to invent data types in XML itself. We, DASL, didn't want to
do anything at variance with what that committee would come up with.
Furthermore, we didn't think it was feasible to track what they were doing
or to tie our schedule to theirs. A significant amount of time has elapsed
since then, and I haven't tracked the XML data types effort. So, I don't
know what the status of data types in XML is. If XML now has data types for
literals, I would use them. If it doesn't, then, you have the same problem
we did.

                                     ---

As far as querying structured properties, I once had a proposal for that
based on the fact that no document management repositories that existed at
that time stored property values in XML. Any such document repositories
would have to have been created after that point in time. Perhaps there are
such repositories now. I don't know. Databases and document repositories
have been around for a very long time. XML is not a good way to store
property values in large document databases. I doubt that an approach to
query structured properties that would  work on the huge existing base of
document repositories as well as any XML based repositories would be based
on a query grammar designed only to query XML documents. 

Keep in mind that a query protocol is a completely different concept than a
query language. A query protocol can accommodate any number of query
languages plus query-by-filling-in-forms. Note that SQL queries can easily
be handled by DASL's basic search protocol.

Remember that there is a conceptually large distinction between DASL and the
basic search protocol. DASL allows for any number of optional query
protocols to be added, and provides for discovering which query protocol is
being used. However, all query protocols other than basic search are
optional. Everyone has to implement basic search. So basic search should be
small, simple, and easy to implement. Thus, basic search can only deal with
about "80%" of the problem, and that's OK.

Hope this helps.

Alan

 -----Original Message-----
From: 	Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent:	Wednesday, June 13, 2001 3:24 AM
To:	Babich, Alan; w3c-dist-auth@w3.org
Subject:	RE: Moving DASL to Experimental

Alan,

first of all: thanks for the feedback.

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan
> Sent: Tuesday, June 12, 2001 10:14 PM
> To: 'Julian Reschke'; w3c-dist-auth@w3.org
> Subject: RE: Moving DASL to Experimental
>
>
> (1) DASL is NOT completely silent about how the grammar engine is
> supposed to know about data types.
> (2) DASL deliberately punted on querying hierarchical data types, i.e.,
> so called "structured" data types, so that we could get the first
> draft out
> in a timely manner. The plan was to address the structured properties
> on the next draft. If you think about it, that might still be the best
> approach.
>
> Re point (1): By DBMS standards, WebDAV has an inadequate
> property model. You can not even say that a property has a
> given data type. In the WebDAV proposal, examples are given wherein

Agreed. Some do, some don't. A property "x" may have different types for
different resources. And so on...

> a property changes data type (for example, if the name of
> the property leads you to believe it is a certain data type, say,
> integer, and a collection doesn't implement it, the collection can
> return a string that says "not implemented"). WebDAV got away without

Are you referring to some live property? I don't think this is the case for
any property defined in RFC2518.

> a rigorous property model until it came time to query, i.e., DASL. At that
> point
> one can no longer duck the issue. (For example, even users that are
> computer illiterate know that "2" comes after "10" if both are
> strings, but
> before if both are integers.) Another problem was that at the
> time DASL was
> developed, XML lacked the notion of data types, but there was an XML
> effort underway to introduce data types. So, everyone wanted the
> XML effort
> to be the way of introducing data types, rather than getting them
> in through
> the back door via DASL, probably in a way that didn't quite track
> the XML effort due to lack of resources and time.

What you're saying is that there were good reasons for the spec to be silent
about these issues. I don't argue with the approach, I just state that it's
a problem if you actually want to implement DASL.

> What DASL said about data types is the following. First, you can
> have a query schema that describes the properties, including their

Query schemas were taken out of the spec, right? AFAIK, the "current" one is
at <http://www.webdav.org/dasl/protocol/draft-davis-dasl-protocol-00.html>,
and Query Schemas were taken out because they seemed to be too complex at
this point of time.

> data types. The data types included Boolean, string, int, float, and
> dateTime. Second, if you don't have a query schema, or if the
> data type of a property is not given, the property defaults to
> type string.
> A literal compared to a property in a query must be coercible to the type
> of the property. Third, people believed that in 90+% of the applications,
> knowledge of the properties would be hard wired into the application.
> Certainly, that would be true for properties defined by DAV, e.g.,
> getcontentlength. That is why the query schema was made optional.

(actually it was removed, and I wasn't really aware anymore of Query Schema
when I wrote that mail).

So some more points (in random order):

- with QS being removed, I think it would be good if the spec for
DAV:basicsearch would actually define how comparisons are meant to be made
(like: the engine may take advantage of type information available for the
server's live properties)

- maybe, for a comparison on other properties the datatype could be
submitted with the query, for instance:

<gt>
 <prop><foo:bar xsi:type="xs:integer" /></prop>
 <literal>1234</literal>
</gt>

- I think that querying into "structured" properties needs to be handled,
especially considering the live properties introduced by ACL and deltaV.
XPath still seems to be a good candidate for this.

- Is there a server implementing Query schemata?


Julian

Received on Wednesday, 13 June 2001 15:39:19 UTC