- From: David G. Durand <dgd@cs.bu.edu>
- Date: Thu, 29 Oct 1998 08:34:23 -0400
- To: w3c-dist-auth@w3.org
At 11:42 PM -0400 10/29/98, Jim Davis wrote: >At 03:56 PM 10/29/98 PST, Jim Whitehead wrote: >>...My sense of the working group is there does not currently exist any >>consensus on this topic. Nor, given the depth of the issues, is it likely >>that any consensus could be achieved quickly. My recommendation is to leave >>this issue unresolved, and be silent on this topic within the spec. It's not at all clear to me that one can do that: Either you are allowed to put arbitrary XML in properties, or you are not. If you are not, then that should be specified (and we could relax the restrictions later). If you are, then servers must choose _some_ XML-preserving implementation (perhaps literal storage of the string, or portions thereof). One of the "properties of properies" is that people can make them up to solve their representational problems, and so they need to know what the syntax is). >I concur, with one exception, namely the xml:lang attribute. This >attribute must be recorded in order to provide international support. >Otherwise there is no way to do correct equality comparisons on properties. >I asked specifically about this attribute in email on 7/27, the sole reply >(8/5, from EJW) indicated that it would be preserved. >It's very important that this attribute be preserved, otherwise DAV is >limited to English language values only. (Or to be more precise, you could >store non-English values, but you couldn't operate on them reliably.) Right, this is one of many. Jim's example about namespaces is another case: and it's also a case where serer rewriting is _only_ appropriate if the client and server are both assumed to have XML processors. I don't think that XML data handling is so hard that restricting it is worthwhile. One table "other_attributes" with columns "attname", "elementreference" and "value" will handle any number of arbitrary attributes, even in a relational system. >But as for all other attributes, I recall Yaron saying that the WebDAV data >model is *not* XML, rather XML is merely one (of possibly many) on the wire >transport encodings for WebDAV values. Fortunately that's not _in_ the standard, is it? The standard defines a protocol, not a data model. The protocol either allows XML properties, or some undefined subset of them. The latter is bad (unless we define the subset) and the former says nothing about how properties must be stored in the engine. >If this is indeed the concensus opinion, then WebDAV is not obligated to >support every feature of the XML data model. It is XML that is at the >service of WebDAV, not the other way around. That's fine, but if you're going to use the syntax, you need to say something if parts of that syntax are potentially ignored by servers! 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). -- David This supports Jim Whitehead's assertion that there is no consensus, but denies that this is acceptable. If we want to outlaw all attributes other than a small fixed set, that is OK, though I'd be surprised if anyone can present an argument as to how that makes a significant savings. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________
Received on Friday, 30 October 1998 08:36:12 UTC