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 06:24:36 UTC