Re: Re (3): collection version resources

   From: Edgar@EdgarSchwarz.de

   > ... Greg's suggestion
   > should be fine (where you just initialize a new version history
   > with the version that you need to expose in the same workspace).

   Will be OK in practice but I still don't love it. Because it
   wouldn't be a problem in my model.

In order to achieve interoperability (which is after all the whole
point of the protocol) will usually result in many situations
which are not optimized for a particular implementation/model.
So "OK in practice" is often as good as it gets (:-).

   >    Sorry I'm not sure I understand. What's a "version resource" ? A
   >    versioned resource, a version of a resource or a versionable
   >    resource ? Just to name some guesses.

   My problem was that in the draft 10.11 there is a definition for
   "version" but not for "version resource".

In general, any "xxx" that is a resource can be referred to as "an xxx
resource" (e.g. "workspace" and "workspace resource", "activity" and
"activity resource", "baseline" and "baseline resource", etc.).
This is used whenever we want to emphasize that we are talking
about a specific resource, and not the general concept.

The only time we use the word "resource" in the definition of a new
kind of resource is when the "resource" is always required, such as in
"versionable resource", "version-controlled resource", and "working
resource".

   Also Greg (And you in
   Chapter 11) was talking about "collection versions" so I assumed
   that the equivalent term would be "resource version" and wondered
   about "version resource".

Yes, English has some wonderfully ambiguous syntax (:-).
You can say "an xxx yyy" to mean "a yyy that is an xxx" and
to mean "a yyy of an xxx".

In the case of "collection version", it is the former,
namely "a version that is a collection".  This is useful
term, because many versions are not collections.

The term "version resource" is also the former, namely
"a resource that is a version".  This emphasizes that we
are talking about an actual resource, rather than just
the concept of a version.

The term "resource version" would be the latter, i.e.
"a version of a resource".  Since all versions (for the protocol)
are versions of a resource, the "resource" qualifier
is redundant, so we don't use it.

   OK, so I suppose I can do what I want. "subbaselines" didn't exist
   yet the last time I read the complete draft.  A while ago I admit :-)
   But perhaps I can do this also with version controlled
   collection.  So I still have something to read for the next days
   :-)

Yes, if you could review the current draft, that would be great!
Note: the only place you'll find sub-baseline functionality will
be in baselines, so don't be disappointed if you don't find it in
version controlled collections (:-).

   > A deltav workspace resource is a set of version-controlled (and
   > non-version-controlled) resources.  Since you show "PUT" working
   > against a relativePath, it looks like you are supporting server
   > workspaces (not client workspaces), so your workspace would
   > not have workingResource's or workingCollection's (but rather
   > would have checked-out version-controlled resources and checked-out
   > version-controlled collections).

   There is a definition of "working resource" in 4.1 but I would
   prefer it to be in 1.3 (Terms) to get a better overview what's
   going on.

That's a good suggestion.  I'll do that if nobody objects.

   Another comment to 10.13.  5 is about Server Workspace
   Option. 5.4.1 gives an example creating a workspace.  But the
   examples for CHECKOUT and CHECKIN in look very normal and show no
   reference to a workspace. Wouldn't it be better to include the
   workspace used in 5.4.1 in them somehow ?

Another good suggestion!  Will do.

   I see that there are some important additions to the draft since I
   looked at it closely a couple of months ago (The difference between
   client and server side workspaces, subbaselines, ...)  All in all I
   think I will be able to map my model to a DAV-Server supporting
   server workspaces. The only feeling that I have is that it's too
   complex and introduces too much unnecessary terms.  But because a
   lot of stuff is optional now this shouldn't be too big a problem
   for implementors.

I've asked every implementor to mail the group a description of what
options they are planning on supporting. If you could do so, that
would be great!  In particular, that would help us discover if there
are any terms that could be left out.  As a side comment, "subbaselines"
was on the edge of being left out, but it looks like that's something
you actually want (:-).

   Neverthess my question is whether it would be possible/useful to
   give a short formal definition of DELTA-V concepts somewhere as an
   EBNF grammer like I'm trying with my stuff. Please don't look at
   the semantics but just the syntax. A small grammer can tell you a
   lot sometimes where you need a lot of text to describe it in prose.
   I changed it a little bit after reading Geoff's comments, thanks.

I have written a Rose model that does this.  If I can carve out some
time, I'll publish this to the deltav web site.  I agree that it would
be very useful (I use it whenever I give a DeltaV presentation).

Cheers,
Geoff

Received on Thursday, 4 January 2001 14:35:01 UTC