RE: Null values

Actually, the isnull operator is misnamed. It
should be renamed to "isdefined". 

WHY: "Defined" means that the property is defined for 
the resource. "Undefined" means that it is not.
"Null" means that the property is defined
for the resource, but has no value. The  WebDAV spec. 
defines the WebDAV property model. Thus, the WebDAV
spec. specifies how "defined" and "null" are handled 
in the context of WebDAV. The WebDAV spec. says that 
if a property is undefined on a resource and you ask for 
it, you get back an error 404 (not found). If the property 
is null (i.e., is defined but has no value), you either you 
get the property back with no value, or you get a 403 
(forbidden) error.

(NOTE: I presume 403 is a security error. If I'm wrong,
somebody please enlighten me: For most servers,
if you don't have the rights to see a thing, the
server quietly drops it out of the response with no error. 
Otherwise, the server would be letting you know the thing 
exists, which might in itself be a breach of security. 
However, WebDAV allows such brain dead security policies. 
Therefore, an security error must be defined for attempted
access rights violations.)

As an example, consider "resourcetype". The WebDAV
spec. defines two values for this property: 
"<D:collection/>", and <null> (which indicates an ordinary
resource). The example on pages 18-19 of the WebDAV
spec. illustrates both return values.

The original motivation for WebDAV was low end servers
with property models that lack the discipline of an
overall schema definition, and even lack the concept of 
resource class. The authors of WebDAV were concerned 
with minimizing the amount of data sent over the network, 
because of the existence of low speed modems. 
For example, ordinary resources greatly outnumber
collection resources. Defining the value of resourcetype
to be null for ordinary resources minimizes data transfer 
for the value of resourcetype. It was further envisioned
that the hierarchical aspect of the WebDAV data model
would be used to minimize data transfer. For example,
most collections would not be ordered. So, the value
of resourcetype would be "<D:collection/>" for unordered
collections. For ordered collections, the property
would become explicitly hierarchical: 
"<D:collection><D:ordered/><D:collection/>". 
Again, this would minimize data transfer when
retrieving the value of resourcetype.

In such a regime it is useful to 
(1) find resources with the null value for a property, and 
(2) find resources that have a property defined. 

An example of (1) is a query to find ordinary resources 
(as opposed to collections), i.e., searching for 
"<D:isnull><D:resourcetype/><D:isnull/>".

An example of (2) is searching for ordered collections,
i.e., searching for 
    <D:isdefined>
        <D:proppath>    
            <D:resourcetype/><D:ordered/>
        <D:proppath>
    <D:isdefined/>
(Obviously I have invented an XML representation for
the equivalent of "A.B.C" syntax in hierarchical RDBMS's,
OODBMS's, programming language structure field access, etc.
for purposes of this example. I simply enclosed the
"A.B.C" in a <D:proppath> tag and drop out the unneeded
dots.)

>>> Therefore, I propose that:
(1) The name of the isnull operator be changed to
isdefined to correct the bug. (There is nothing else 
wrong with the definition.)
(2) The correct version of the isnull operator be added to DASL:

  5.12.     DAV:isnull

       The DAV:isnull operator allows clients to determine whether a
       property exists on a resource.  The DAV:isnull operator is TRUE
if
       and only if a PROPFIND response for the property on that resource
       would return the 200 status code and the value of the property
       is null.
<<<

I will be making a proposal about structure query that is 
probably going to be along the lines of the above example 
(i.e., add an optional "proppath" operator and add it as a
syntactical alternative wherever <D:prop> is used). However, 
I have a whole lot of work to get off my plate first.


Alan Babich

> -----Original Message-----

> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: September 14, 1998 9:50 AM
> To: www-webdav-dasl@w3.org
> Subject: Null values
> 
> 
> DASL draft has two difference definitions of NULL, in 5.5.3 
> and in 5.11
> 
> 5.5.3 says
> 
> A NULL value for a property identifies the following conditions:
> - The property is not defined on a resource.
> - The property is not set on a resource.
> - The value of the property is UNKNOWN.
> - Security policies prevent the retrieval of the property's value.
> 
> 5.11 says
> 
>  The DAV:isnull operator is TRUE if and only if a PROPFIND 
> response for the
> property on that resource would return the 403 (Forbidden) or 404 (Not
> Found) status code.
> 
> I think we should have exactly one definition of what it is 
> to be null, and
> I like the second definition better because it's based on observable
> behavior of a lower level of the protocol.  Also the 
> definition in 5.5.3 is
> not very "DAV" like, in that in DAV there is no concept of a 
> "schema" that
> would say whether a property is "defined on" a resource, and 
> there is no
> way to set a value of a property to "UNKNOWN".  These are 
> concepts that
> appear in DASL because we know that some DASL servers will use SQL for
> implementation, but DASL should use only the language of DAV.
> 
> 
> 
> ------------------------------------
> http://www.parc.xerox.com/jdavis/
> 650-812-4301
>

Received on Monday, 14 September 1998 15:36:14 UTC