Más allá del método PUT del HTTP estándar (que crea o sobreescribe un recurso web), WebDAV define los nuevos métodos COPY y MOVE para duplicar o reacomodar recursos.

Este es simplemente el término usado en WebDAV para el agrupamiento de recursos (URI's). En la mayoría de los casos, es el análogo a un “directorio”. Se puede decir que algo es una colección si termina con un “/”. De la misma manera que los archivos pueden ser creadoscon el método PUT, las colecciones son creadas con el nuevo método MKCOL.

Es la misma idea que está presente en Subversion—metadatos asociados a archivos y colecciones. Un cliente puede mostrar u obtener las propiedades asociadas a un recurso con el nuevo método PROPFIND, y puede cambiarlas con el método PROPPATCH. Algunas propiedades son completamente creadas y controladas por los usuarios (por ejemplo, una propiedad llamada “color”), y otras creadas y administradas por el servidor WebDAV (por ejemplo, la propiedad que contiene la última fecha de modificación de un archivo). Las primeras son llamadas propiedades “muertas” y las segundas propiedades “vivas”.

Un servidor WebDAV puede decidir ofrecer una característica de bloqueo a los clientes— esta parte de la especificación es opcional, aunque muchos servidores WebDAV ofrecen esta característica. Si está presente los clientes pueden usar los nuevos métodos LOCK y UNLOCK para mediar el acceso a un recurso. En la mayoría de los casos estos métodos son usados para crear bloqueos de escritura exclusivos (como se discutió en “La solución bloqueo-modificación-desbloqueo”), aunque también es posible tener bloqueos de escritura compartidos.

Como CVS y otros sistemas de control de versiones, DeltaV asume que cada recurso tiene un número de estados potencialmente infinito. Un cliente empieza poniendo un recurso bajo control de versiones usando el nuevo método VERSION-CONTROL. Éste crea un nuevo recurso de versión controlada (VCR, por sus siglas en inglés). Cada vez que usted cambia el VCR (vía PUT,PROPPATCH, etc.), un nuevo estado del recurso es creado, llamado recurso de versión (VR por sus siglas en inglés). Los VRs y VCRs son recursos web ordinarios, definidos por URLs. Los VRs específicos también pueden tener nombres amables con el usuario.

Algunos servidores DeltaV tienen la habilidad de crear un “espacio de trabajo” virtual en el servidor, donde se ejecuta todo el trabajo. Los clientes usan el método MKWORKSPACE para crear un área privada, luego indican que quieren cambiar VCRs específicos editándolos, y “registrando su entrada” de nuevo. En términos de HTTP, la secuencia de métodos sería CHECKOUT, PUT, CHECKIN. Después de cada CHECKIN, se crea un nuevo VR,y los contenidos de los VCR's editados ahora “apuntan” al último VR. Cada VCR tiene también un recurso “historia”, que hace el seguimiento y ordenamiento de varios estados VR.

Algunos servidores DeltaV también soportan la idea de que el cliente pueda tener una copia privada de trabajo llena de VRs específicos. (Así es como CVS y Subversion trabajan.) Cuando el cliente quiere enviar cambios al servidor, empieza creando una transacción tamporal al servidor (llamada una actividad)con el método MKACTIVITY. El cliente ejecuta entonces un CHECKOUT sobre caad VR que desea cambiar, lo que crea un número de “recursos de trabajo” temporales en la actividad, que pueden ser modificados usando los métodos PUT y PROPPATCH. Finalmente, el cliente ejecuta un CHECKIN en cad recurso de trabajo, lo que crea un nuevo VR dentro de cada VCR, y la actividad completa es borrada.

DeltaV le permite definir colecciones flexibles de VCRs llamadas “configuraciones”, que no necesariamente corresponden a directorios particulares. El contenido de cada VCR puede hacerse apuntar a un VR específico usando el método UPDATE. Una vez la configuración es perfecta, el cliente puede crear un “snapshot” de toda la configuración, llamado “baseline”. Los clientes usan los métodos CHECKOUT y CHECKIN para capturar estados específicos de las configuraciones, de manera muy similar a cuando usan estos métodos para crear estados VR específicos de VCRs.

DeltaV define un nuevo método, REPORT, que permite al clienet y al servidor llevar a cabo intercambios personalizados de datos. El cliente envía una solicitud REPORT con un cuerpo XML adecuadamente etiquetado y lleno de datos personalizados; asumiendo que el servidor entiende el tipo específico del reporte, responde con un cuerpo XML igualmente personalizado. Esta técnica es muy similar a XML-RPC.

Para muchos, esta es la aplicación “estrella” de DeltaV. Si el servidor DeltaV soporta esta característica, entonces los clientes WebDAV básico (por ejemplo, aquellos que no son compatibles con versionado) aún pueden escribir en el servidor, y el servidor silenciosamente hará el versionado. En el ejemplo más simple, un PUT ignorante de parte de un cliente WebDAV básico puede ser traducido por el servidor como un CHECKOUT, PUT, CHECKIN.