Next message: Clemm, Geoff: "RE: postcondition for PUT"
Message-ID: <3906C56A7BD1F54593344C05BD1374B10D9E5F@SUS-MA1IT01>
From: "Clemm, Geoff" <gclemm@rational.com>
To: "'DeltaV (E-mail)'" <ietf-dav-versioning@w3.org>
Date: Mon, 11 Sep 2000 18:04:27 -0400
Subject: RE: Versioning TeleConf Agenda, 8/11/00 (Monday) 2pm-3pm EST
Participating: Boris Bokowski (OTI), Jim Doubek (Macromedia), Tim Ellison
(IBM),
Jim Amsden (IBM), Geoff Clemm (Rational).
The following issues were raised:
- JA: Do we need the new Rationale section?
(I'm happy to delete it, but it was requested at the last DeltaV meeting.)
- JA: Should the pictures use URL's instead of names like "V1", "V2".
Geoff made the point that you are severely limited with what you can
do with ASCII art (and passed the buck back to Jim saying that if he
wanted to redo the ASCII art, we could look at the result and see
whether there was a net improvement.
- JA: Do we really need DAV:version-name (aren't reserved labels by the
server sufficient)?
(I'm happy to delete it, but it was requested at the last DeltaV meeting.)
- BB: Shouldn't DAV:version-name be added to the DAV:version-tree-report.
Sure.
- JA: Why is Overwrite:update needed (isn't Overwrite:T sufficient)?
A good example is copying a new value into a working resource. With
Overwrite:T,
the working resource would first be deleted, and thus a COPY with
Overwrite:T
would not update the working resource (but rather delete it, and create a
new
resource). We could redefine Overwrite:T, but this would be clearly
incompatible with the 2518 definition.
I'll add some more text to the Overwrite section to motivate this extension.
- JA: the new 4xx response body values
- JA: PROPFIND
- JA: LOCK
We didn't have time to address these topics today. Jim: please mail
something
to the mailing list on what you had in mind for these three topics.
- JD: In the "Baselines" section, most references to "workspace" should be
"collection"
(since you now baseline a collection, not just a workspace).
Will fix.
- BB: The ordering of the predecessor-set of a version is not guaranteed to
match
that of the working resource from which it was created.
Will fix.
- JD: Would like to have something said about what happens when you try to
update
a live property of a version or version selector.
In general, as with all live properties, the answer to this depends upon the
semantics
of the particular live property. I just took a look at the document to see
where we
would put such a statement, but everywhere I looked, I already had made the
point by
indicating that the semantics only applied to *dead* properties. So I'm
inclined to
just leave it as is. JimD: Perhaps you could send me the sentence you would
like to see
added, and where you would want to see it. Does anyone else feel such a
statement
is needed?
- BB: Would like to let the client control whether or not a working resource
is checked
out in place (as is required in a workspace) or not.
I will add a "DAV:here" and a "DAV:not-here" option to CHECKIN. If DAV:here
is specified,
the CHECKOUT MUST be done in place (as is done in a workspace). If
DAV:not-here is
specified, the CHECKOUT MUST NOT be done in place. If neither is specified,
the server
can chose whether to CHECKOUT in place or not.
Note: With this option, it seems to make sense to have the "auto-set-target"
behavior of CHECKIN only applies to working resources that were checked out
in place, and then to get rid of the DAV:hidden option to CHECKIN, since it
doesn't make much sense to use DAV:hidden on a working resource that was
checked out in place.
- BB: Want OPTIONS response to indicate whether VERSION-CONTROL is
automatically
applied to newly created versionable resources.
Will do.
- JA: Need quote marks on the attribute values for "unknown".
Will fix.
- JA: Do we really need the unknown attribute?
Without this (or something like this), a client cannot tell a server that it
must
not ignore a particular part of the request (ignoring is the default
behavior for
unknown XML element types).
And that's all we had.
A quick poll of those on the conference call did not surface any desire to
defer last call. I'll get out an 8.1 draft this week, so everyone can
review
the changes resulting from this call.
If you can think of any reason why we should not go to last call this month,
please speak up now!
Cheers,
Geoff