- From: David G. Durand <dgd@cs.bu.edu>
- Date: Wed, 4 Nov 1998 21:22:14 -0400
- To: w3c-dist-auth@w3.org
At 11:21 PM -0400 11/3/98, Jim Davis wrote: >I agree that the spec must take a principled position on the issue. >I don't agree with any of the positions that have been advocated. (But I >confess, I am not sure that I have seen the alternatives clearly stated and >contrasted.) My core claim is that we _must_ specify what the server preserves. In that way, what you propose meets my most fundamental objection to the other claims I've heard. I've proposed one suggestion by reference, as I don't see the point of copying out James' prose when it's available on the web. >Let me suggest a possible set of rules for DAV's handling of XML in dead >properties: > >1. DAV servers MUST preserve the hierarchical structure of elements. >1. DAV servers MUST preserve the order of elements. >2. DAV servers MUST preserve the names of elements >3. DAV servers MUST process the xml:lang attribute >4. DAV servers MUST process the namespace attributes >5. DAV servers MUST process whitespace in accordance with the DTD (or the >relevant XML attribute, if there is one) >6. DAV servers MUST preserve the PCDATA contents. > >and that's it. > >Notably missing is: > >x. DAV servers MAY process other attributes. This means that any schema facilities (such as the ones Alan was assuming can be used (like RDF, etc.) are probably out of bounds since they use attributes (at least the drafts seem to), and thus cannot be layered over the 6 rules given. If you add attributes, we're then at almost exactly what I proposed as the best solution (which is to re-use the semantics already in place for XML). >because merely permitting it is of no use, since unless it's mandatory, >it's not safe for clients to rely on it. Exactly. We're certainly in agreement there. But point: 7. DAV servers MUST preserve other attributes, and MAY process them, if appropriate. Would allow the use of the many layered facilities being built on XML, without the need to amend DAV layer by layer, as they seem appropriate and are approved. It would also _not_ require servers to recognize or process them. You should also (for the same reason) add: 8. DAV servers MUST preserve processing instructions. (they tend to be used to declare optional layers like that). >In my opinion, the DAV object model is *not* XML. XML is merely a >convenient transport mechanism. There is no need for DAV to support every >feature of XML, only the minimum necessary to convey the data of the data >model, and to support IETF-mandated internationalized property values. Great. Explain clearly the advantages of _using XML_ and then saying "Hey, we're not really using XML, just our own customized subset." Alan says we do that without specifying what features we are using, you advocate eliminating attributes, for no reason that I can see. [Attributes can certainly be handled by naming conventions in systems that don't have them, but do support hierarchy. [This crufty little example included in case the comments about LDAP following have more to do with the server model than with on-the-wire encodings, as you seem to say]: call element foo Efoo, and attribute bar Abar. Then markup like: <foo bar="bar"><bar>x</bar></foo> becomes a little tree: Efoo Abar "bar" Ebar "x" ] >It should be perfectly reasonable to port WebDAV to use an alternate >on-the-wire encoding, for example BER (used in LDAP). No attributes there. But WebDAV _has_ an on-the-wire protocol. That's what we're defining. LDAP is irrelevant: unless we have consensus that it's better than XML, in which case we should use it, and then XML is irrelevant. I'm afraid I understand what you're proposing, but your motivation is completely opaque. If we pick a transfer format, we either need to use it, or say how we change it. I think we agree to that point. However, if we're writing a standard, and we're referencing another existing standard, we should make changes in the other standard only if we have very compelling reasons. Any changes in the referenced standard create problems of compatibility, and reduce the possible reuse of working code and human expertise. I'm not saying "XML semantics do or die." I am saying we need _documented semantics_ and that _if_ we are going to change things (and thus break tools and nullify expertise) we had better have extremely good reasons. -- David -- David _________________________________________ 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 Wednesday, 4 November 1998 21:23:57 UTC