RE: property value clarification

"Frankly, accepting full XML properties seems like a no-brainer to me:
the
parsers are small, and the data model is simple. (RDBMs are going to
have
much more trouble handling nesting than they ever will with
attributes)."

I disagree with both sentences. It would be a very
large mistake to burden the DAV property model with
the artifacts of XML (e.g., saving original property
value representation including whitespace,
recording attributes, etc.), and to require servers to
handle arbitrary XML documents as property values.
Servers do not store property values as XML documents
for very good reasons, e.g., efficiency of storage,
efficiency of processing, and simplicity of concepts
for implementers and end users. Servers should not
have to be burdened with the requirement of storing
arbitrary XML documents as property values.
Just as XML is a poor format for storing some types 
of document content (e.g., images), it is not the
best format for storing simple properties or 
supporting queries against them.

Fortunately, the DAV property model is *not* XML. 
Yaron tried to make that clear in his e-mail. 

The DAV draft defines the protocol. 
XML happened to be the serialization format chosen
to represent the protocol, including property values 
going to and coming from the server. 
The DAV draft says, as it should, that
the property values must be expressible in XML
(and, in fact, that the XML has to be well formed).
Otherwise, XML could not have been chosen for the 
serialization format.

The draft does not completely constrain the property 
model. IMHO, that is OK for this draft. The property 
model is and should be independent of any particular 
serialization format that happens to be chosen for 
the protocol. The property model should not be 
overconstrained: It should accommodate what people 
have done and are doing, and much of what they 
would like to do. I would welcome a little bit 
more clarification of the property model in future 
work. For example, it would be helpful if the draft 
explicitly said that the property model is not XML. 
That would avoid a lot of confusion.

Regarding the second sentence, dealing with nesting
is not more difficult than dealing with attributes for
RDBMS's. Dealing with a statically defined property 
structure or a statically defined set of attributes 
is straightforward. What is a pain is dealing with 
arbitrary nested properties and arbitrary XML attributes 
discovered dynamically at run time, because columns and 
tables will have to be created dynamically by the server.

The XML:lang attribute is called out explicitly in
the latest version of the draft. Localization is
very important on the internet, so important, that
perhaps special emphasis is required. An RDMS would
probably use two columns to represent the value of
a string property -- one for the string contents, 
and one for the language selected. At least 
the extra column would be a known, fixed column.

Alan Babich

Received on Sunday, 1 November 1998 19:00:35 UTC