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 20:10:24 UTC