RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

   From: Alan Kent [mailto:ajk@mds.rmit.edu.au]

   If orthogonal concepts were present, then they *could* be in separate
   properties rather than introducing the concept of sub-types etc.
   Eg:
     <resourcetype>
       <workspace/>
       <collection/>
       <version-controlled/>
     </resourcetype>

   *could* be done as

     <resourcetype>
       <collection/>
     </resourcetype>
     <version-controlled> TRUE <version-controlled/>
     <workspace> TRUE </workspace>

Yes, this is the approach that the "DAV:supported-live-property-set"
folks are advocating.  But rather than just a property whose value
is "TRUE", we try to define a property with interesting semantics that
characterize the resource (e.g. DAV:version contains the stable URL
that identifies that version).

   I am not recommending it - just raising it as an alternative. I am
   still struggling to understand all the versioning concepts flying
   around here and after reading the DeltaV draft spec!

There are never a shortage of interesting things to debate (:-).  Some
things are proposed new features or modified behavior of existing
features.  Some things are general HTTP or WebDAV issues that have
arisen in a versioning context.  Some things are questions of how
certain desired behaviors can be exposed or requested by the existing
protocol.

   In some ways I am happy to
   see that people on this list are still trying to work out things too
   (ie - its not just me!)

There are always new folks on the list, so never feel shy about
asking newbie questions ... sometimes the response will be just a
reference to an old thread, but that just helps motivate us to
get the FAQ written (:-).

   Mind you it also makes me a little worried that
   people are still trying sort out what basic concepts mean.

Those are the issues that *never* get resolved (:-).
"What is a resource?"  "When should information be
marshalled in a header or in the body?"  And our current
"What is a resource type?".  These are the kinds of
metaphysical debates that occur while there aren't any
more concrete issues open (:-).

   And the complexity of it all seems quite high to me (a new comer)
   at the moment.

I'd recommend starting by identifying the functionality that you want
to expose on your server, and then figure out how you would support
the core-versioning package (just the "version-control" feature)
with your server.  Once you have done that, you have identified
how your server will interoperate with all core-versioning clients.

If all of your functionality is exposed by the core-versioning
package, then you are done, and you can ignore the rest of the versioning
protocol.

If you still have some interesting features you would like to expose
in an interoperable way, decide whether you want to support the
in-place-checkout feature or the workspace feature.  (If you want to
support both, randomly pick one to investigate first.)

If you want to support in-place-checkout, that is included in the
server-workspace package, so you'll also need to read up on the
version-history and workspace features.

If you want to support working resources, that is included in
the client-workspace package, so you'll also need to read up on
the update and label features.

And finally, if you're doing heavy duty versioning, there are
the advanced versioning features.

Cheers,
Geoff

Received on Saturday, 23 June 2001 23:18:55 UTC