WebDAV の世界ではサーバ側にあるすべてのオブジェクト (それは URI によって記述されるものですが)は、 リソースと言われます。

標準的なHTTP PUTメソッドに 加えて(それはwebリソースを作ったり上書きしたりしますが)、WebDAV は新しいCOPY と MOVE メソッドを定義し、リソースを複製したり移動したりすることができます。

集合 は WebDAV の用語では ひとまとまりのリソースのことを言います。ほとんどの場合、それは ディレクトリのようなものになります。ファイルリソースは PUTメソッドで書き込まれたり作られたりしますが、 集合リソースは新しい MKCOLメソッドで作られます。

これはSubversionに出てるのと同じアイディアです— ファイルと集合に付随したメタデータです。クライアントは新しい PROPFIND メソッドを使ってリソースに付随 した属性を一覧表示したり抽出したりできます。そして、 PROPPATCH メソッドを使って変更できます。 いくつかの属性は完全にユーザによって作られ制御されます( たとえば、「color」と呼ばれる属性)、また他のものは 完全にWebDAVサーバによって作られ制御されます(たとえば、ファイル の最後の修正時刻を含む属性)。最初のものは「死んだ」 属性と呼ばれ、あとのものは「生きた」 属性と呼ばれます。

WebDAVサーバはクライアントに対するロックの機能を与える ことができます。 —この機能は任意です。ほとんどのWebDAVサーバはこの機能を 提供していますが。もし存在すれば、クライアントは新しい LOCK と UNLOCKメソッドを 使ってリソースへのアクセスを調停することができます。 ほとんどの場合、これらのメソッドは排他的な書き込みロックを作る ために利用されます(ロック・修正・ロック解除の解法項で議論した ように)、ただしサーバの実装によっては共有書き込みロックも可能です。

より最近の仕様(RFC 3744)では WebDAV リソースに対するアクセス制御 リスト(ACL)を定義するためのシステムを規定しています。クライアントや サーバによってはこの機能を実装し始めているものもあります。

CVSや他のバージョン管理システムのようにDeltaVはそれぞれのリソースは 無限の数の状態をとりうると仮定しています。クライアントは新しい VERSION-CONTROL メソッドを使ってリソースを バージョン管理下に置くことによって始めます。これには新しい VERSION-CONTROL メソッドを使います。

DeltaV サーバによっては仮想的な作業スペースをサーバ上に作る能力が あります。すべての作業はそこで実行されます。クライアントは MKWORKSPACEメソッドを使ってプライベートな領域を 作り、作業スペースに「チェックアウト」することで 特定のリソースを変更したいということを示し、編集した後、もう一度 「チェックイン」します。 HTTPの言葉で言えば、メソッドの 流れとしては、 CHECKOUT, PUT, CHECKIN となります。

DeltaV サーバによってはクライアントがローカルディスク上にプライベート な作業コピーを持つこともできるという考え方をサポートします。 クライアントがサーバに変更点をコミットしたい場合、まず MKACTIVITY メソッドによって一時的なサーバトランザクション( アクティビティー と呼ばれます)を作ることで処理を開始します。 それからクライアントは変更したいリソースごとにCHECKOUT を実行し、PUT要求を送ります。最後にクライアントは リソースに対する CHECKINを実行するか MERGE要求を送ってすべてのリソースを一度に チェックインします。

DeltaV では「設定」と呼ばれるリソースの 汎用的な集まりを定義することができますが、かならずしもそれは特定の ディレクトリに対応する必要はありません。設定はファイルの特定のバージョン を指し示すのに作成したり、「ベースライン」のスナップショット を作ったりできます。後者はタグによく似たものです。

DeltaV は新しいメソッドREPORTを定義しますが それはクライアントとサーバが独自データ交換を実行するのを許す ものです。DeltaV はクライアントが要求可能な標準化された履歴情報 をいくつも定義してありますが、さらに自由にカスタム情報を定義することも できます。クライアントはREPORT 要求を 独自のデータのある属性ラベルの付いたXMLのボディーをともなって 送信します。サーバがこの特定のレポート型を理解できることを 仮定して、それはやはり独自のXMLボディーを応答します。この技術は XML-RPCとよく似ています。