- From: Lisa Dusseault <lisa@xythos.com>
- Date: Fri, 3 Aug 2001 22:33:30 -0700
- To: "DeltaV" <ietf-dav-versioning@w3.org>
Is there some reason why DeltaV deviates from every prior instance of WebDAV property representation in XML? Not only does the current syntax make unnecessary use of attributes, which DAV has traditionally discouraged, but it reinvents something for which we already have a mechanism in DAV. To be consistent with how 2518 does PROPFIND, PROPPATCH, etc. I would have expected: <D:supported-live-property-set xmlns:D="DAV:" xmlns:x="http://www.xythos.com/schemas/StorageServer"/> <D:getcontentlength/> <D:getcontentlanguage/> <x:quota/> <x:size/> ... </D:supported-live-property-set> But the DeltaV draft requires the following syntax: <supported-live-property-set> <supported-live-property name="getcontentlength" namespace="DAV:"/> <supported-live-property name="getcontentlanguage" namespace="DAV:"/> <supported-live-property name="quota" namespace="http://www.xythos.com/schemas/StorageServer"/> <supported-live-property name="size" namespace="http://www.xythos.com/schemas/StorageServer"/> ... </supported-live-property-set> Is there some merit to doing things this way that isn't immediately obvious? The DeltaV syntax is rather more bloated and far less obvious. Moreover, it makes it impossible for people to reuse the code they already have for parsing DAV property lists. This is not a feature. Aside from consistency and stylistic considerations, the syntax in the draft is just plain broke. The DTD for supported-live-property set hardwires the namespace to DAV: <!ATTLIST supported-live-property namespace NMTOKEN "DAV:"> This makes it impossible to render vendor-specific extensions (thus rendering my above example technically illegal). I assume this is an error since just yesterday Geoff claimed that vendor-specific extensions were to appear in supported-live-property-set. Lisa
Received on Saturday, 4 August 2001 01:33:43 UTC