Subject: RE: Moving DASL to Experimental

From: "Babich, Alan" <[email-masked]>
Date: Tue, 12 Jun 2001 13:13:58 -0700

(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
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 
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 DASL said about data types is the following. First, you can
have a query schema that describes the properties, including their
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.

Alan Babich

 -----Original Message-----
From: 	Julian Reschke [mailto:[email-masked]] 
Sent:	Tuesday, June 12, 2001 3:12 AM
To:	[email-masked]
Subject:	Re: Moving DASL to Experimental

Hi,

I'm looking for other parties that would be interested on working on DASL
again. With the current status of the spec I have mainly two problems, both
of which apply to the basicsearch grammar:

1) The spec is completely silent about how the grammar engine is supposed to
know about data types. For instance, I would suspect that property values
for getcontentlength are supposed to be compared as numbers, while
getlastmodified need a date comparison.

2) The grammar for accessing properties is not really XML-friendly, which
has led to inventions like "DAV:iscollection". Indeed, this so-called
"synthetic property" only solves one special case and leaves the rest
(lockdiscovery, attributes, deltaV computed properties) untreated. I think
DASL needs a grammar which can do "arbitrary" queries into the attributes,
so something with the power of XPath would need to be used.

In addition, I'm not happy with the language in chapter 3 (discovery of
grammars). It mixes namespace prefixes with URI schemes, which is only
correct in the very special case of "DAV:" (being a URI scheme and also the
prefix used there).

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 13 Jun 2001 12:24:24 +0200

Alan,

first of all: thanks for the feedback.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Babich, Alan
> Sent: Tuesday, June 12, 2001 10:14 PM
> To: 'Julian Reschke'; [email-masked]
> Subject: RE: Moving DASL to Experimental
>
>

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

> 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.

> 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.

> 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.

> 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