RE: What it means to be dead

My comments interspersed.

Alan Babich

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: July 21, 1998 8:39 PM
> To: www-webdav-dasl@w3.org
> Subject: What it means to be dead
> 
> 
> 
> At 09:30 PM 7/20/98 PDT, Babich, Alan wrote:
> 
> >I don't understand two things: (1) What do you mean
> >"use datatype in the query"? Does this amount to decorating 
> >literals? 
> 
> Yes.  That's all I mean.  
> 
> We've all already agreed (I think) that there is no need to specify a
> datatype in a query against live properties or against "famous" dead
> properties.  The only issue is whether to specify a datatype 
> in a query
> against obscure dead properties.
> 
> I have been trying to show that 
>  a) to do so would raise great difficulties, and
>  b) to not do so would cause only minor inconvenience.
> 
> This is the *only* point I am trying to make.
> 
> >So, how obscure are they? Can you put an integer into one
> >belonging to ordinary resource 1, put an ASCII string into one 
> >belonging to ordinary resource 2, and then put in a datetime value to
> >update the property on ordinary resource 1? 
> 
> Yes.  The meaning of "dead" is that the server does not 
> enforce syntax or
> semantics (WebDAV 3.1).  This applies to all dead, whether 
> famous or obscure.
> 
> Some implementation of DAV may have no 'famous' dead 
> properties at all.
> Any property that is searchable will be checked at PROPPATCH 
> time, which
> would make it live, not dead.  Others will not check.  They 
> will accept the
> update (thus the property is dead) but at index time will 
> either skip any
> property with bad syntax, or perhaps treat it as a string.  
> (I know you
> can't do this in SQL.)
ALAN BABICH: After sleeping on it and reading your reply,
here's what I think:  >> ALL dead properties are strings as
far as the server is concerned. << Period. If a client thinks
they are anything else, that is a figment of the imagination
of the client as far as the server is concerned. The
client can attempt to follow conventions to trick the server
into supporting its concept, but that is a fragile paradigm, 
and depends on all clients never slipping up in following 
the convention(s). Any slipup will not affect the server,
only the clients.

The WebDAV spec. says (last sentence of 3.1): "A dead property
has its syntax and semantics enforced by the client; the
server merely records the value of the property VERBATIM [emphasis
mine]." My interpretation of "verbatim" in this defining sentence,
is that the server MUST regurgitate the exact
sequence of characters that PROPPATCH stored in the property.
I can see NO wiggle room for the server on this. A sequence
of characters that just happens to match the syntax for
a hex integer or a floating point literal or a zip code
or a street address or an XML document might be intended to
be a literal string by the client -- the server can't know,
and is not allowed to guess. 

Therefore, if the dead property is a key of retrieval, it is 
a key of retrieval in exactly the same way as any other string
property that is a key of retrieval. SQL, of course, knows 
how to deal with strings.

So, let us not be confused by the two notions of datatype -- the
client's and the server's. The server's datatype is the 
only one that's relevant to DASL, and that must be String. 
I think I'm unconfused now. I didn't read 3.1 carefully enough 
until recently, and I used to think dead properties were the same 
as live properties, case (b).

> 
> So, having said all this, I'll ask again.  I know you want 
> datatype in the
> QSD.  Do you see *any* reason to put it into the *query*?  
> 
ALAN BABICH: Since you asked for "*any* reason": I would
say that I see some benefit in allowing the client 
to state its intent for the datatype of a literal explicitly 
(and I see no harm in allowing that as an option). Then just 
from the literal and its tag alone you can tell if the client 
slipped up in its own intent. (However, I do NOT insist on 
allowing or requiring decoration of literals with their datatype. 
Just using <literal> is OK with me.)

Received on Wednesday, 22 July 1998 14:28:49 UTC