RE: datatyping is not needed

> Let's drop datatyping.

I presume that you mean to drop data type
indications from the query schema discovery, not
just the query itself (select, where, and sortby).
I presume that this also means you withdraw the
offer of compromise that you and I nearly reached 
on the QSD. The rest of this e-mail is base on these
presumptions.

I don't believe the arguments below based on obscure
dead properties justifies your conclusion.

Whenever you step off the beaten path, you
run the risk of stepping on a land mine.
A single land mine can blow up your schedule and 
your chances of success.
The beaten path for query is "query conditions
and order by on scalar values that are of one of 
the 5 fundamental datatypes (integer, string, etc.)".

As an example, WebDAV defined the resourcetype
property values as an XML document. Ignoring
data type issues in this way caused WebDAV to
step off the beaten path for query. Deeper thought
about the situation would have revealed that
that is not the best thing to do for query.
An integer or string datatype would have been better.

In many applications, the resource type (collection,
ordinary resource, or indirect reference) won't
be explicitly stored at all. It would be implicit.
So, the return XML document value would be synthesized
based on where the server was looking (i.e.,
whether it was looking at collections, ordinary
resources, or indirect references). In fact,
in many systems, even the ordinary resources
would be in different RDBMS tables, and the
resource type would not be stored -- it would
be synthesized by the server based on which table 
was searched.

We all think it is a good idea to use the resource
type as a query criterion. So, the first thought
is to invent a way to query XML documents. Bad idea.
The value is never stored as an XML document,
and DASL is not the appropriate forum for 
standardizing how to query XML documents.
Even if DASL did that and did a good job, that would 
create an ugliness in the server implementation of
querying XML valued properties: Many
servers would have to make a special case out
of querying for the WebDAV resource type property, 
because that property is usually not
stored at all, and when it is, it is undoubtedly not
stored as an XML document. This is bad.
Better would be to invent a special operator
just to test for equality of the resource type
property against one of the three possible
cases.

DASL is not the appropriate forum for standardizing
how to query structures, either. Nor
is DASL the appropriate forum for defining
how to query over arrays, e.g., arrays of
integers, datetimes, structures, etc.
DASL should stay on the beaten path to maximize
its chances for success.

There is real value in providing the client
with the information that a property is
one of the 5 fundamental data types in the QSD info. 
The client can then choose to give instant 
feedback to the user exactly at
the point of commission of the error. There
are lots of existence proofs of this. This situation
is much better than a three digit
error code that says, in effect, "query improperly
constructed": That degrades productivity,
and provides no help to the user in correcting
his mistake. That's a bad user experience.
Since providing datatype information on the five
fundamental datatypes in the QSD result
has no downside, doing so is clearly the right 
thing to do.


Alan Babich

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: July 20, 1998 5:04 PM
> To: www-webdav-dasl@w3.org
> Subject: Re: datatyping is not needed
> 
> 
> At 12:52 PM 7/17/98 PDT, Saveen Reddy wrote:
> >If I understand you correctly you are saying: we shouldn't 
> define any type
> >casting in the query. 
> >Type casting I'm not sure [whether we need], 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
> >typing.
> 
> Saveen I think you've just nailed the issue.
> 
> It seems to me we have come to agree that datatyping is only 
> needed in a
> query if the property is "obscurely dead", right?  (The server already
> knows the type for both "live" and "famous dead" properties, 
> and does not
> need the client to tell it.)
> 
> Then the question is, how does the server know the datatype of the
> obscurely dead?  There are only two possibilities:
> 
> 1) Some client told it, at the time the property was stored, e.g. by
> annotating the value with something like 
> <integer>10</integer>.  If one did
> a PROPFIND, you'd get back the same annotated value.
> 
> 2) The datatype is in the query. The DASL server converts from the
> underlying stored value (a string) to the type in the query, 
> so for example
> if the value of property "foo" is "9", then it should compare equal to
> *either* of the following literals: 
>   <literal t:dt="t:int">9</literal>
>   <literal t:dt="t:string">9</literal>
> 
> Case 1 says, in effect "If you want to treat obscurely dead 
> properties as
> other than strings, you need to store them in a special 
> syntax that DASL
> knows about".  When the client wants to store into a 
> property, it will have
> to know (or find out) whether the property is live or dead, and apply
> annotation if (and only if) it is dead.  And I do mean if and only if,
> because if you allow (or require) annotation for *all* 
> properties, then you
> have two choices, both awful:
>  1) the value returned by a PROPFIND is not the same as that set by
> PROPPATCH.  Annotation of a live property in a PROPPATCH is 
> discarded.  
>    OR
>  2) DASL redefines the value of e.g. dav:getcontentlength
> 
> But having the client have to choose whether or not to 
> annotate is awful,
> also.
> 
> Case 2 is also bad.  If we put the datatype in the query, then
> 
> It raises the bar of implementation.  It forces DASL to define string
> representations and coercions for every datatype we want, and 
> it forces all
> servers to implement them.  We also have to define error 
> cases (e.g. for
> coercions where the integer length is too great).
> 
> It makes us choose whether this type annotation is to be used 
> for *all*
> literals, or only those being compared to the obscure dead properties.
> (The latter are the only ones that need it.)  If it applies 
> to all, then we
> have to define coercions in both directions, (e.g. to take the literal
> integer 10 into a string).  If it applies only to the dead 
> then the client
> has to know, at query time, whether the property is live or 
> dead, which is
> even worse.
> 
> WebDAV decided to not attempt to define datatyping in the 
> first release.
> DASL should follow their example.  The price we pay 
> (complexity) is far too
> high for the meagre return.  If we omit typing altogether, 
> the *only* thing
> we lose is that comparisons on the obscure dead are always 
> done as strings.
>  But this is not so bad.  First of all, ISO 8601 dates are 
> cleverly defined
> so that string compares are also valid date comparisons - 
> they sort the
> right way.  The only screw cases are integers and floats.  I 
> won't discuss
> floats, but for integers at least, I claim that a client that 
> really cares
> about integer sorting on the obscure dead can obtain this 
> simply by writing
> the (string) value as a zero-padded string, e.g. write "9" and "0009".
> This is, if you like, a "trivial" annotation.
> 
> Let's drop datatyping.
>

Received on Monday, 20 July 1998 21:01:15 UTC