- From: Babich, Alan <ABabich@filenet.com>
- Date: Sun, 1 Nov 1998 16:01:03 -0800
- To: "'David G. Durand'" <dgd@cs.bu.edu>, w3c-dist-auth@w3.org
"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