The versioning protocol has no explicit support for workflow management, but the "activity" object should be used as the basis for simple workflow management. Currently, an activity tracks the versions that are the "products" of that activity, but for workflow management, an activity would need to be extended with standard properties for information such as a state machine and activity dependencies.
geoffrey.clemm

There are a few reasons why Delta-V specifies that servers should not report all versioning properties to a PROPFIND requaest for DAV:allprop.

Some of the live properties defined in Delta-V are likely to be expensive for the server to compute. In fact, there are properties that will provide substantial queries over the versioning resources and these are very powerful. A server can be seriously impacted by serving such requests for numerous resources, such as in a Depth: infinity request.

It is unlikely that clients will require all the live properteis of a versioned resource if they are versioning unaware. They will neither be able to interpret the values they are given, nor know how they can cuase the values to change. It is much more appropriate for clients to query live properties 'intelligently', i.e. knowing what they are asking and what they intend to do with the information.
Tim_Ellison

No, currently not.
DeltaV introduces quite some new live properties which might
be expensive to compute for a server. Thus, the new DeltaV
live properties where excluded from PROPFIND requests with
allprop.
When a client uses prop (huge list of properties) prop in
a PROPFIND, it of course gets an answer from the server with
information about all those properties. However it will miss
all the properties, it does not know about. That could be new
live properties added by new DAV extensions, or dead properties
set by users/other clients.
propname will return the names of all properties, but a client
has to make a second PROPFIND request with all those names to
actually get the values, too. Also, note that a client cannot
cache the list of names. There are many cases (e.g. checked-in,
checked-out) where the list of names changes frequently.
Conclusion: no, a client cannot.
How bad is it? Well, a versioning aware client would want to know
what type a resource is. For this, it has to know the set of
supported live properties of a resource, but supported-live-property-set
is not part of a allprop response. That means that a client
has to make 2 PROPFIND requests for every resource it wants to
know about (using Depth 1 will help of course).

Apparently, not if the parameters are essential to identifying the version or version history.
DeltaV defines versions as resources, version histories as resources, and version-controlled resources as (duh) resources.
WebDAV (2518) defines resources as having URLs where the parameters don't matter. In other words, two URLs that differ only in their parameter information refer to the same resource.
Therefore, if a URL refers to a version or version history, it cannot have the same base URL as the URL which refers to a VCR. It must have a different base URL. (By base url I mean the part up to and not including the parameters).
lisa

"(DAV:version-history-is-tree): If the request-URL identifies a version-controlled resource that was automatically checked out because DAV:auto-version was DAV:when-locked, then the versions identified by the DAV:predecessor-set of the checked-out resource MUST be descendants of the root version of the version history for the DAV:checked-out version."

When a version-controlled resource is left checked-out (which in core can only happen because DAV:auto-version was DAV:when-locked), the DAV:predecessor-set can be updated by the client. It could update the predecessor set to refer to some random resource that is not in the version history. This postcondition prevents that. (from Geoff)
Tim_Ellison

Clemm, Geoff [gclemm@rational.com] wrote in the deltaV mailing list:
A workspace is only allowed to have one VCR for a given version
history, to ensure that baselining and merging is unambiguous
(baselining and merging in a workspace is based on finding the
version history that corresponds to the version being merged),
so if you want to create a "variant" of a resource in the same
workspace, this requires two different version histories.
In order to track the relationship between these two variants
(i.e. when the diverged, and from what common version), the
DAV:precursor-set property was introduced.
It was then decided by the working group that this "history of
a COPY" was something of general utility (using arguments similar
to those that Rick posted), and since it provides utility with
minimal server implementation cost, it was made part of the base
protocol.
stefan.eissing

Note that in the final pass for RFC3253 the DAV:precursor-set was dropped. So I guess it wasn't so important after all :-)
Tim_Ellison

Predecessors MUST be part of the same version history resource, and precursors MUST NOT be part of the same version history resource.
It makes a big difference to the client whether a version is in the same history as another version, in terms of what you can do (for example, you cannot UPDATE a version-controlled resource to be a precursor of the checked-in
version, but you can UPDATE it to a predecessor).
Tim_Ellison

There are two good reasons for having a DAV:supported-method-set
property: Consistency and speed.
A client can get a picture of the resource properties _and_ the
methods that are supported with one PROPFIND request. This
allows a consistent view on the state and type of a resource.

All members of a baseline-controlled collection (that are not members of another configuration) have a DAV:version-controlled-configuration property that identifies the version-controlled configuration whose root collection is that baseline-controlled collection. The state of a non-version-controlled member will not be captured by versions (baselines) of the VCCn identified by its DAV:version-controlled-configuration property, but this property is still useful because it indicates the VCCn that must be checked out in order to place that non-VCR under version control.
geoffrey.clemm

What's the best way to model a patch set in deltaV? (Let's say I want to
create a
configuration including only the files in a collection, recursively, that
have changed since
a particular baseline.)
Answer:
You can create a new baseline in the collection,
and then use the DAV:compare-baseline report
to describe the differences.
Creating a collection that just contains the
"changed files" doesn't really capture the change,
since it can only capture additions, and not
moves or deletions.

Delta-V FAQ :
Why are all not all Delta-V features shown as categories?

Well, I figured I could have created a bunch of empty categories, but since _you_ can create them when you have an answer to contribute, I just created enough for you to see the pattern and get going.
Go for it!
Tim_Ellison

An experiment to see if we can capture the names and semantics of WebDAV properties, to promote interoperability.

The subcategories of the registry are URI's corresponding to the XML namespaces of defined properties.
Property descriptions should contain the purpose of the property, any semantics enforced by the server, and the syntax of the value (preferably as a DTD-like description).
Tim_Ellison

From RFC2518:
The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non- null state).

From RFC2518:
Note that the last-modified date on a resource may reflect changes in any part of the state of the resource, not necessarily just a change to the response to the GET method. For example, a change in a property may cause the last-modified date to change. The getlastmodified property MUST be defined on any DAV compliant resource that returns the Last-Modified header in response to a GET.

From RFC2518:
The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. The server is free to withhold any or all of this information if the requesting principal does not have sufficient access rights to see the requested data.

From RFC2518:
The resourcetype property MUST be defined on all DAV compliant resources. The default value is empty.

<!ELEMENT resourcetype ANY >
Tim_Ellison

Note that Microsoft Webfolders interprets any non-empty resourcetype value as a colelction type resource (that is, it shows a folder icon). So if you have a resource type of, say, < DAV:version-history/> then it will appear as a collection even if it does not support collection semantics.
Tim_Ellison

From RFC2518:
The source of the link (src) is typically the URI of the output resource on which the link is defined, and there is typically only one destination (dst) of the link, which is the URI where the unprocessed source of the resource may be accessed. When more than one link destination exists, this specification asserts no policy on ordering.

From RFC2518:
The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see.

Microsoft have documented - to an extent - the namespaces they are using
for the Exchange/Sharepoint family of servers. You can find it in the
Exchange SDK documentation:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/wss_references_nsproperties.asp
This includes the proprietary extensions to DAV: that MS Explorer uses, plus
namespaces and properties for appointments, events, messages, office docs
etc. Unfortunately some information is seriously lacking, such as the format
used for dates (the examples given appear to use the locale of the server?), liveness of properties, etc.
Brian.Ewins