W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > January to March 2003

RE: Relationship between scopes and version histories

From: Wallmer, Martin <Martin.Wallmer@softwareag.com>
Date: Thu, 6 Feb 2003 11:24:57 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E62106063A8A71@daemsg02.software-ag.de>
To: "'Julian Reschke'" <julian.reschke@gmx.de>, www-webdav-dasl@w3.org

Hi,

just to clarify:

1. If a resource in scope has versions, the server SHOULD take care of
versions as well.
2. If the client specifies <d:include-versions />, the server MUST take care
of versions or MUST reject the request.
3. If the user does not want to get versions, he must specify <not
xmlns="DAV:"><is-defined><version-name /></is-defined></not> ...

Is my understanding correct?

However, a defined "switch" (include - exclude) could be a good hint for the
server in terms of performance, so I'd prefer a <d:exclude-versions/> as
well. 
Alternatively the server should only include the versions, if
<d:include-versions /> is specified.

Does this make sense?

Regards,
Martin


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Mittwoch, 5. Februar 2003 18:50
To: www-webdav-dasl@w3.org
Subject: RE: Relationship between scopes and version histories



Very good point, Elias.

Right now, a client can explicitly de-select versions by specifying
something like

	<not xmlns="DAV:"><is-defined><version-name /></is-defined></not>

Similarily, version histories can be excluded using

	<not xmlns="DAV:"><is-defined><version-set /></is-defined></not>

Would that suffice?

In general, I'd prefer not to change the semantics of the scope itself. If a
version happens to be in the namespace scope, the search should apply to it
as well...


Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Elias Sinderson
> Sent: Wednesday, February 05, 2003 6:39 PM
> To: www-webdav-dasl@w3.org
> Subject: Re: Relationship between scopes and version histories
>
>
>
> Julian Reschke wrote:
>
> >A relatively frequent use case for servers that both support
> versioning and
> >DASL seems to have searches that include all versions of the resources in
> >scope. In general, the version URIs may not be in the scope of the query.
> >
> Ahh, I'd not thought of this use case, thanks for recognizing this and
> pointing it out.
>
> >Therefore, I'd like to extend the DAV:scope to specify inclusion of
> >versions. This would be an optional extension -- however, a
> server that does
> >not support his feature should reject the request (so that the
> client would
> >know that the request could not be satisfied).
> >
> >Example:
> >
> >    <d:from xmlns:d="DAV:">
> >      <d:scope>
> >        <d:href>/container1/</d:href>
> >        <d:depth>infinity</d:depth>
> >        <d:include-versions />
> >      </d:scope>
> >    </d:from>
> >
> This extension seems reasonable to me. One question I have is whether
> some servers implementation of versioning would result in the version
> URIs being in the scope of the search unintentionally? If so, then it
> may also be reasonable to add <d:exclude-versions/> as well. I'd be a
> little miffed if my seemingly well-formed query returned matches on all
> the version histories of a resource and I was unable to turn it
> off easily.
>
> Without knowledge of how a given server implements versioning, it will
> be difficult for a client to know how to modify a query such that it
> excludes previous versions of resources. Further, since different
> servers will implement versioning differently, clients may end up using
> special cases for different servers - something to be avoided. An
> alternate approach to defining <d:exclude-versions/> would be to specify
> that in the absence of <d:include-versions/>, the default behavior MUST
> exclude previous versions of resources from the scope of a query.
>
>
> Elias
>
Received on Thursday, 6 February 2003 05:25:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:09 GMT