W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 1998

Re: datatyping is not needed

From: Saveen Reddy <saveenr@microsoft.com>
Date: Fri, 17 Jul 1998 12:52:00 -0700
Message-ID: <001301bdb1bc$5d035770$5ffd3b9d@saveenrx.dns.microsoft.com>
To: "Saveen Reddy (Exchange)" <saveenr@microsoft.com>, <www-webdav-dasl@w3.org>, "Jim Davis" <jdavis@parc.xerox.com>
Comments below ...

-----Original Message-----
From: Jim Davis <jdavis@parc.xerox.com>
To: Saveen Reddy (Exchange) <saveenr@exchange.microsoft.com>;
www-webdav-dasl@w3.org <www-webdav-dasl@w3.org>
Date: Wednesday, July 15, 1998 12:14 AM
Subject: RE: datatyping is not needed

>At 11:50 PM 7/14/98 PDT, Saveen Reddy (Exchange) wrote:
>> then a plausible
>>scenario exists where detatyping is required for obscure dead properties.
>>Some implementations will allow searching (even if the query is not as
>>efficient for some "famous" property).
>While I confess that I can recognize this scenario as *possible*, still I
>don't find it very probable.  Without indexing, it's hard for me to believe
>in exhaustive search.   I can admit that in some cases it might be done,
>still I also don't find it nearly as strong as the other scenarios.  I
>wouldn't call DASL a failure if it didn't have it.

OK, I disagree about how likely this is. I believe the use of obscure dead
properties + exhaustive search (as painful as that might be for server
performance) is probably the lowest bar for implementing a dav server and
because of that bound to be likely.

>And I am troubled by the notion of post-facto imposing 'typing' on
>properties people stored, and by the added work we'll have to do to define
>this precisely.  Just to take one example, the (obscure dead) property
>'foo' on resources R1 and R2 has values "BABE" and "FAD" respectively.  Now
>if we sort by 'foo' and the client says nothing about the datatype, then R1
>comes before R2 because the string "BABE" is alphabetically before "FAD".
>But if the client asserts that these are really numbers expressed in
>hexadecimal, then it's the other way around.  Will we *require* that all
>compliant DASL servers support all the type coercions?  And remember, once
>we define it, we can't easily be rid of it.

If I understand you correctly you are saying: we shouldn't define any type
casting in the query. I suspect we may be closer to agreement than it may
first appear.

Here's my attempt to summarize the views ... (someone tell me if I have this
- Jim Davis: don't need type casting in the query
- Alan Babich: need to advertise types in QSD
- Saveen Reddy: Type casting I'm not sure about, but clients do need a way
to set the type of a property with PROPPATCH, because naturally this will
affect how a query (even without type casting gets done). With either type
casting or setting the type with PROPPATCH we can't avoid the issue of

>I think we have some very hard pieces of work ahead of us without getting
>into this.  Consider all the open issues not yet resolved, surely we are
>better off letting this one go?  I mean, we still have to figure out what
>content based retrieval to support, and whether and how to support any
>structure query.  These are surely way more central and important than
>sorting on the obscure dead?

Sorting of the obscure dead may not be so important, but *query criteria*
using the obscure dead is, IMO.

Even if we simply drop type casting from the query, we still have to address
how the server will deal with types in the query (for example under what
criteria is a string equivalent to another string). Without type
casting/coercion thrown into the mix this just doesn't seem that complex.

Received on Friday, 17 July 1998 15:57:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:39 UTC