Confusing words: "null", "string"

The words "null" and "string" have multiple meanings.
This has occasionally led to miscommunication. This 
e-mail is an attempt to clarify a couple of
cases where miscommunication has sometimes arisen.

To disambiguate multiple meanings of a certain word, I
will suffix the word with an integer: string1, string2,
null1, null2, value1, value2, etc. when I intend a specific 
meaning.

The meaning of null that is relevant to DASL is the 
meaning used in database theory, relational database theory,
SQL, mathematics, and set theory, since DASL is about query.
For this discussion that meaning will be designated null1.
I further define value1 as the value of a WebDAV property.
(A value1 conceptually distinct from any of its 
representations, including the UCS-ized representation
of XML documents.) In WebDAV, the meaning of null1 is simply 
(1) a property P is defined for a resource at hand R, but
(2) no value1 for P can be produced for R. 
Note that the name of a property is not its value1.
Both of the conditions must hold. If P is not defined for
R, then we can NOT say P is null1 for R -- we must say P is 
UNDEFINED for R. It does not matter why the two conditions 
hold, only that they do. (Forget about definitions that
say "Since PUTPROP was never performed, ...".)

The WebDAV draft defines the handling of null1.

Error 404 (not found) is returned by PROPFIND for a specific
property that is not defined on a resource, along with the
name of the property. PROPFIND with "allprop" does not 
return any properties that are not defined for a 
resource -- it doesn't even mention their names in the 
response. (See the example in section 7.1.2 of the WebDAV 
draft for the "get*" properties.)

If a P is null1 for R, PROPFIND returns success and the 
name of P, but no value1 is returned. That is, an empty XML 
element e.g., "<P/>" or "<P></P>" is returned. For example,
most resources have no value1 for "resourcetype", so
only "<resourcetype/>" is returned (see the example in
section 7.1.2 of the WebDAV draft). 

WebDAV deliberately uses null1 as a data compaction
technique. The designers of WebDAV made the property model 
hierarchical partly because they anticipated further future 
use of the "null1 implies the most common case" data 
compaction technique.

The convention that a null1 value implies a specific case
should not be confused with the fact that no value1 exists.

DASL must conform to the WebDAV data model.

Unfortunately, programming languages typically have
another meaning for null -- null2. For example, ASCII
defines a null2 character as zero. Include files such as
"windows.h" declares "NULL" as a macro evaluating to "0".
C strings are terminated with null2 characters, etc. .

This has lead people to say "null value", "null string", 
etc. . The confusion arises from the fact that they are 
really saying "null2 value", "null2 string", etc., but 
some DASL listeners are hearing "null1 value1". There is 
no such thing as a null1 value1, because null1 means a 
value1 can not be produced.

Further confusion is caused by the expression of the 
WebDAV data model in the XML model, because some people 
think of an empty XML element as if it were a value1 
In the WebDAV model, it is not -- it is merely the
name of the property. The name of a property and
its value1 are very different things.

Mentioning the NAME of the property in the response
is necessary, because it is necessary to label the value1's 
returned by the PROPFIND or query. A list of value1's
(possibly with some missing because there is no value1)
in the response would be useless without a way to
designate which value1 goes with which property.
Value1 is the central thing. The XML element is secondary. 
The XML model is merely the way chosen out 
of multiple alternatives to represent the value1 and 
label it with its name, and to handle the rest of the
WebDAV protocol.

String is another overloaded word. 

Since DASL is in the query business, DASL HAD to force 
the datatypes issue. (For example, you cannot tell if "01" 
is equal to "1" unless you know whether the underlying 
datatype is string1 or integer.) The WebDAV draft postponed 
the datatypes issue, but the authors knew datatypes were 
coming. The WebDAV property model datatypes must be 
explicitly recognized for DASL query, just as data types 
must be recognized for query in any database. String1 is one 
of these WebDAV basic datatypes. Unfortunately, string1 is 
sometimes confused with string2 (i.e., subsequences of UCS 
characters that are part of the sequence of UCS characters
that we choose to think of as an XML document), and string3, 
the UCS-ized representation of the "content" of an XML
"element". (Note that a string3 is always also a string2).

(Note that the XML data effort will bring the basic 
datatypes to XML. Browse to http://www.microsoft.com/xml/ 
and click in the left pane on "XML Tutorial" and then on 
"Using data types" to quickly get a flavor of what is 
coming. An XML parser that understands datatypes 
will become available at that URL and other URL's.)

The WebDAV data model is what is significant, and with
DASL it has the basic datatypes. The XML representation
of stuff is much less significant. The content of XML
elements representing property values should be viewed 
as the USC-ized representation of the WebDAV value,
which is of some datatype.

Zero length string1's are not distinguishable (in XML) 
from null1. We know that null1 is an important WebDAV data 
model concept. Therefore, zero length string1's effectively 
do not exist in the WebDAV data model, since empty
XML elements representing property values are always 
interpreted as null1. This is not a problem in any way 
as far I can tell.

Alan Babich

Received on Tuesday, 22 September 1998 18:57:58 UTC