RFC3253 日本語訳
3253 Versioning Extensions to WebDAV (Web Distributed Authoring andVersioning). G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead. March 2002. (Format: TXT=245514 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Clemm
Request for Comments: 3253 Rational Software
Category: Standards Track J. Amsden
T. Ellison
IBM
C. Kaler
Microsoft
J. Whitehead
U.C. Santa Cruz
March 2002
コメントを求めるワーキンググループG.クレム要求をネットワークでつないでください: 3253年の合理的なソフトウェアカテゴリ: 2002年の標準化過程J.Amsden T.エリソンIBMのC.KalerマイクロソフトJ.ホワイトヘッドU.C.サンタクルスの行進
Versioning Extensions to WebDAV
(Web Distributed Authoring and Versioning)
WebDAVに拡大をVersioningします。(ウェブの分配されたオーサリングとVersioning)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.
このドキュメントはHTTP/1.1プロトコルに拡大をversioningしながらWebDAV(ウェブDistributed AuthoringとVersioning)を定義する1セットのメソッド、ヘッダー、およびリソースタイプを指定します。 WebDAV versioningはWebDAV Versioningサービスを利用できるアプリケーションの広範囲の展開を容易にするためにさまざまなversioning倉庫マネージャと共に共同利用できるクライアントの複雑さを最小にするでしょう。 WebDAV versioningはversioning気づかないクライアント、バージョン歴史管理、ワークスペース管理、基線管理、活動管理、およびURL名前空間versioningのための自動versioningを含んでいます。
Table of Contents
目次
1 Introduction.................................................... 6
1.1 Relationship to WebDAV........................................ 7
1.2 Notational Conventions........................................ 8
1.3 Terms......................................................... 8
1.4 Property Values............................................... 11
1.4.1 Initial Property Value..................................... 11
1つの序論… 6 WebDAVとの1.1関係… 7 1.2 記号法のコンベンション… 8 1.3の用語… 8 1.4 特性の値… 11 1.4 .1 資産価値に頭文字をつけてください… 11
Clemm, et al. Standards Track [Page 1] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[1ページ]。
1.4.2 Protected Property Value................................... 12
1.4.3 Computed Property Value.................................... 12
1.4.4 Boolean Property Value..................................... 12
1.4.5 DAV:href Property Value.................................... 12
1.5 DAV Namespace XML Elements.................................... 12
1.6 Method Preconditions and Postconditions....................... 12
1.6.1 Example - CHECKOUT request................................. 13
1.7 Clarification of COPY Semantics with Overwrite:T.............. 13
1.8 Versioning Methods and Write Locks............................ 14
2 Basic Versioning Features....................................... 14
2.1 Basic Versioning Packages..................................... 14
2.2 Basic Versioning Semantics.................................... 16
2.2.1 Creating a Version-Controlled Resource..................... 16
2.2.2 Modifying a Version-Controlled Resource.................... 17
2.2.3 Reporting.................................................. 19
3 Version-Control Feature......................................... 20
3.1 Additional Resource Properties................................ 20
3.1.1 DAV:comment................................................ 20
3.1.2 DAV:creator-displayname.................................... 20
3.1.3 DAV:supported-method-set (protected)....................... 20
3.1.4 DAV:supported-live-property-set (protected)................ 21
3.1.5 DAV:supported-report-set (protected)....................... 21
3.2 Version-Controlled Resource Properties........................ 21
3.2.1 DAV:checked-in (protected)................................. 21
3.2.2 DAV:auto-version........................................... 22
3.3 Checked-Out Resource Properties............................... 22
3.3.1 DAV:checked-out (protected)................................ 23
3.3.2 DAV:predecessor-set........................................ 23
3.4 Version Properties............................................ 23
3.4.1 DAV:predecessor-set (protected)............................ 23
3.4.2 DAV:successor-set (computed)............................... 23
3.4.3 DAV:checkout-set (computed)................................ 23
3.4.4 DAV:version-name (protected)............................... 24
3.5 VERSION-CONTROL Method........................................ 24
3.5.1 Example - VERSION-CONTROL.................................. 25
3.6 REPORT Method................................................. 25
3.7 DAV:version-tree Report....................................... 26
3.7.1 Example - DAV:version-tree Report.......................... 27
3.8 DAV:expand-property Report.................................... 29
3.8.1 Example - DAV:expand-property.............................. 30
3.9 Additional OPTIONS Semantics.................................. 31
3.10 Additional PUT Semantics..................................... 31
3.11 Additional PROPFIND Semantics................................ 32
3.12 Additional PROPPATCH Semantics............................... 33
3.13 Additional DELETE Semantics.................................. 33
3.14 Additional COPY Semantics.................................... 34
3.15 Additional MOVE Semantics.................................... 34
3.16 Additional UNLOCK Semantics.................................. 35
1.4.2 保護された資産価値… 12 1.4 .3は資産価値を計算しました… 12 1.4 .4 ブール資産価値… 12 1.4 .5 DAV: href資産価値… 12 1.5 DAV名前空間XML Elements… 12 1.6 メソッドの前提条件とPostconditions… 12 1.6 .1 例--CHECKOUT要求… 13 重ね書き: T.とのコピー意味論の1.7明確化… そして、13 1.8 Versioningメソッド、錠を書いてください… 14 2 基本のVersioningの特徴… 14 2.1 基本的なVersioningパッケージ… 14 2.2 基本的なVersioning意味論… 16 2.2 .1 バージョンで制御されたリソースを作成します… 16 2.2 .2 バージョンで制御されたリソースを変更します… 17 2.2 .3 報告します… 19 3バージョンコントロール機能… 20 3.1 追加リソースの特性… 20 3.1 .1 DAV: コメントしてください… 20 3.1 .2 DAV: クリエイター-displayname… 20 3.1 .3 DAV: サポートしているメソッドはセットしました(保護されます)… 20 3.1 .4 DAV: サポートしている精力の特性はセットしました(保護されます)… 21 3.1 .5 DAV: サポートしているレポートはセットしました(保護されます)… 21 3.2 バージョンで制御されたリソースの特性… 21 3.2 .1 DAV: チェックインします(保護されます)… 21 3.2 .2 DAV: 自動バージョン… 22 3.3 調べているリソースの特性… 22 3.3 .1 DAV: チェックアウトします(保護されます)… 23 3.3 .2 DAV: 前任者と同じくらいセットしてください… 23 3.4 バージョンの特性… 23 3.4 .1 DAV: 前任者と同じくらいセットしてください(保護されます)… 23 3.4 .2 DAV: 後継者と同じくらいセットしてください(計算されます)… 23 3.4 .3 DAV: チェックアウトしてセットしてください(計算されます)… 23 3.4 .4 DAV: バージョン名(保護されます)… 24 3.5 バージョンコントロールメソッド… 24 3.5 .1 例--バージョンコントロール… 25 3.6 メソッドを報告してください… 25 3.7 DAV: バージョン木のレポート… 26 3.7 .1 例--DAV: バージョン木のレポート… 27 3.8 DAV: 特性を拡張しているレポート… 29 3.8 .1 例--DAV: 特性を広げます… 30 3.9 追加オプション意味論… 31 3.10 追加かかっている意味論… 31 3.11 追加PROPFIND意味論… 32 3.12 追加PROPPATCH意味論… 33 3.13、追加、意味論を削除してください… 33 3.14 複本意味論… 34 3.15 追加移動意味論… 34 3.16 追加アンロック意味論… 35
Clemm, et al. Standards Track [Page 2] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[2ページ]。
4 Checkout-In-Place Feature....................................... 35
4.1 Additional Version Properties................................. 35
4.1.1 DAV:checkout-fork.......................................... 36
4.1.2 DAV:checkin-fork........................................... 36
4.2 Checked-Out Resource Properties............................... 36
4.2.1 DAV:checkout-fork.......................................... 36
4.2.2 DAV:checkin-fork........................................... 37
4.3 CHECKOUT Method............................................... 37
4.3.1 Example - CHECKOUT......................................... 38
4.4 CHECKIN Method................................................ 38
4.4.1 Example - CHECKIN.......................................... 40
4.5 UNCHECKOUT Method............................................. 40
4.5.1 Example - UNCHECKOUT....................................... 41
4.6 Additional OPTIONS Semantics.................................. 42
5 Version-History Feature......................................... 42
5.1 Version History Properties.................................... 42
5.1.1 DAV:version-set (protected)................................ 42
5.1.2 DAV:root-version (computed)................................ 42
5.2 Additional Version-Controlled Resource Properties............. 42
5.2.1 DAV:version-history (computed)............................. 43
5.3 Additional Version Properties................................. 43
5.3.1 DAV:version-history (computed)............................. 43
5.4 DAV:locate-by-history Report.................................. 43
5.4.1 Example - DAV:locate-by-history Report..................... 44
5.5 Additional OPTIONS Semantics.................................. 45
5.6 Additional DELETE Semantics................................... 46
5.7 Additional COPY Semantics..................................... 46
5.8 Additional MOVE Semantics..................................... 46
5.9 Additional VERSION-CONTROL Semantics.......................... 46
5.10 Additional CHECKIN Semantics................................. 47
6 Workspace Feature............................................... 47
6.1 Workspace Properties.......................................... 48
6.1.1 DAV:workspace-checkout-set (computed)...................... 48
6.2 Additional Resource Properties................................ 48
6.2.1 DAV:workspace (protected).................................. 48
6.3 MKWORKSPACE Method............................................ 48
6.3.1 Example - MKWORKSPACE...................................... 49
6.4 Additional OPTIONS Semantics.................................. 49
6.4.1 Example - OPTIONS.......................................... 51
6.5 Additional DELETE Semantics................................... 51
6.6 Additional MOVE Semantics..................................... 52
6.7 Additional VERSION-CONTROL Semantics.......................... 52
6.7.1 Example - VERSION-CONTROL.................................. 53
7 Update Feature.................................................. 53
7.1 UPDATE Method................................................. 53
7.1.1 Example - UPDATE........................................... 55
7.2 Additional OPTIONS Semantics.................................. 55
8 Label Feature................................................... 56
4適所でのチェックアウト機能… 35 4.1 追加バージョンの特性… 35 4.1 .1 DAV: チェックアウトして分岐してください… 36 4.1 .2 DAV: チェックインで分岐してください… 36 4.2 調べているリソースの特性… 36 4.2 .1 DAV: チェックアウトして分岐してください… 36 4.2 .2 DAV: チェックインで分岐してください… 37 4.3 チェックアウトメソッド… 37 4.3 .1の例--、チェックアウト… 38 4.4 チェックインメソッド… 38 4.4 .1の例--、チェックイン… 40 4.5 UNCHECKOUTメソッド… 40 4.5 .1の例--、UNCHECKOUT… 41 4.6 追加オプション意味論… 42 5バージョンヒストリ機能… 42 5.1 バージョン歴史の特性… 42 5.1 .1 DAV: バージョンでセットしてください(保護されます)… 42 5.1 .2 DAV: 根バージョン(計算されます)… 42 5.2 追加バージョンで制御されたリソースの特性… 42 5.2 .1 DAV: バージョン歴史(計算されます)… 43 5.3 追加バージョンの特性… 43 5.3 .1 DAV: バージョン歴史(計算されます)… 43 5.4 DAV: 歴史で、レポートの場所を見つけてください… 43 5.4 .1 例--DAV: 歴史で、レポートの場所を見つけてください… 44 5.5 追加オプション意味論… 45、5.6、追加、意味論を削除してください… 46 5.7 複本意味論… 46 5.8 追加移動意味論… 46 5.9 追加バージョンコントロール意味論… 46 5.10 追加チェックイン意味論… 47 6ワークスペース機能… 47 6.1 ワークスペースの特性… 48 6.1 .1 DAV: ワークスペースチェックアウトはセットしました(計算されます)… 48 6.2 追加リソースの特性… 48 6.2 .1 DAV: ワークスペース(保護されます)… 48 6.3 MKWORKSPACEメソッド… 48 6.3 .1の例--、MKWORKSPACE… 49 6.4 追加オプション意味論… 49 6.4 .1 例--ゆだねます。 51、6.5、追加、意味論を削除してください… 51 6.6 追加移動意味論… 52 6.7 追加バージョンコントロール意味論… 52 6.7 .1 例--バージョンコントロール… 53 7 特徴をアップデートしてください… 53 7.1 メソッドをアップデートしてください… 53 7.1 .1 例--アップデートします。 55 7.2 追加オプション意味論… 55 8 特徴をラベルしてください… 56
Clemm, et al. Standards Track [Page 3] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[3ページ]。
8.1 Additional Version Properties................................. 56
8.1.1 DAV:label-name-set (protected)............................. 56
8.2 LABEL Method.................................................. 56
8.2.1 Example - Setting a label.................................. 58
8.3 Label Header.................................................. 58
8.4 Additional OPTIONS Semantics.................................. 59
8.5 Additional GET Semantics...................................... 59
8.6 Additional PROPFIND Semantics................................. 59
8.7 Additional COPY Semantics..................................... 60
8.8 Additional CHECKOUT Semantics................................. 60
8.9 Additional UPDATE Semantics................................... 61
9 Working-Resource Feature........................................ 62
9.1 Additional Version Properties................................. 62
9.1.1 DAV:checkout-fork.......................................... 62
9.1.2 DAV:checkin-fork........................................... 63
9.2 Working Resource Properties................................... 63
9.2.1 DAV:auto-update (protected)................................ 63
9.2.2 DAV:checkout-fork.......................................... 63
9.2.3 DAV:checkin-fork........................................... 63
9.3 CHECKOUT Method (applied to a version)........................ 63
9.3.1 Example - CHECKOUT of a version............................ 65
9.4 CHECKIN Method (applied to a working resource)................ 65
9.4.1 Example - CHECKIN of a working resource.................... 66
9.5 Additional OPTIONS Semantics.................................. 67
9.6 Additional COPY Semantics..................................... 67
9.7 Additional MOVE Semantics..................................... 67
10 Advanced Versioning Features.................................. 67
10.1 Advanced Versioning Packages................................. 68
10.2 Advanced Versioning Terms.................................... 68
11 MERGE Feature................................................. 70
11.1 Additional Checked-Out Resource Properties................... 70
11.1.1 DAV:merge-set............................................. 70
11.1.2 DAV:auto-merge-set........................................ 71
11.2 MERGE Method................................................. 71
11.2.1 Example - MERGE........................................... 74
11.3 DAV:merge-preview Report..................................... 75
11.3.1 Example - DAV:merge-preview Report........................ 76
11.4 Additional OPTIONS Semantics................................. 77
11.5 Additional DELETE Semantics.................................. 77
11.6 Additional CHECKIN Semantics................................. 77
12 Baseline Feature.............................................. 77
12.1 Version-Controlled Configuration Properties.................. 78
12.1.1 DAV:baseline-controlled-collection (protected)............ 78
12.2 Checked-Out Configuration Properties......................... 78
12.2.1 DAV:subbaseline-set....................................... 78
12.3 Baseline Properties.......................................... 78
12.3.1 DAV:baseline-collection (protected)....................... 79
12.3.2 DAV:subbaseline-set (protected)........................... 79
8.1 追加バージョンの特性… 56 8.1 .1 DAV: ラベル名はセットしました(保護されます)… 56 8.2 メソッドをラベルしてください… 56 8.2 .1 例--ラベルを設定します… 58 8.3 ヘッダーにレッテルを貼ってください… 58 8.4 追加オプション意味論… 59、8.5、追加、意味論を得てください… 59 8.6 追加PROPFIND意味論… 59 8.7 複本意味論… 60 8.8 追加チェックアウト意味論… 60 8.9 追加アップデート意味論… 61 9働くリソース機能… 62 9.1 追加バージョンの特性… 62 9.1 .1 DAV: チェックアウトして分岐してください… 62 9.1 .2 DAV: チェックインで分岐してください… 63 9.2 働くリソースの特性… 63 9.2 .1 DAV: 自動アップデート(保護されます)… 63 9.2 .2 DAV: チェックアウトして分岐してください… 63 9.2 .3 DAV: チェックインで分岐してください… 63 9.3CHECKOUT Method(バージョンに適用されます)… 63 9.3 .1 例--バージョンのCHECKOUT… 65 9.4CHECKIN Method(働くリソースに適用されます)… 65 9.4 .1 例--働くリソースのCHECKIN… 66 9.5 追加オプション意味論… 67 9.6 複本意味論… 67 9.7 追加移動意味論… 67 10の高度なVersioningの特徴… 67 10.1 Versioningパッケージを進めます… 68 10.2 Versioning用語を唱えます… 68 11は特徴を合併します… 70 11.1 調べている追加リソースの特性… 70 11.1.1 DAV: マージでセットしてください… 70 11.1.2 DAV: 自動マージのセット… 71 11.2 メソッドを合併してください… 71 11.2.1 例--合併してください… 74 11.3 DAV: マージプレビューレポート… 75 11.3.1 例--DAV: レポートをマージで下見してください… 76 11.4 追加オプション意味論… 77 11.5、追加、意味論を削除してください… 77 11.6 追加チェックイン意味論… 77 12基線機能… 77 12.1 バージョンで制御された構成の特性… 78 12.1.1 DAV: 基線の制御収集(保護されます)… 78 12.2 調べている構成の特性… 78 12.2.1 DAV: 「副-基線」でセットしてください… 78 12.3 基線の特性… 78 12.3.1 DAV: 基線収集(保護されます)… 79 12.3.2 DAV: 「副-基線」でセットしてください(保護されます)… 79
Clemm, et al. Standards Track [Page 4] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[4ページ]。
12.4 Additional Resource Properties............................... 79
12.4.1 DAV:version-controlled-configuration (computed)........... 79
12.5 Additional Workspace Properties.............................. 80
12.5.1 DAV:baseline-controlled-collection-set (computed)......... 80
12.6 BASELINE-CONTROL Method...................................... 80
12.6.1 Example - BASELINE-CONTROL................................ 82
12.7 DAV:compare-baseline Report.................................. 84
12.7.1 Example - DAV:compare-baseline Report..................... 85
12.8 Additional OPTIONS Semantics................................. 86
12.9 Additional MKCOL Semantics................................... 86
12.10 Additional COPY Semantics................................... 86
12.11 Additional CHECKOUT Semantics............................... 86
12.12 Additional CHECKIN Semantics................................ 86
12.13 Additional UPDATE Semantics................................. 87
12.14 Additional MERGE Semantics.................................. 89
13 Activity Feature.............................................. 90
13.1 Activity Properties.......................................... 91
13.1.1 DAV:activity-version-set (computed)....................... 91
13.1.2 DAV:activity-checkout-set (computed)...................... 92
13.1.3 DAV:subactivity-set....................................... 92
13.1.4 DAV:current-workspace-set (computed)...................... 92
13.2 Additional Version Properties................................ 92
13.2.1 DAV:activity-set.......................................... 93
13.3 Additional Checked-Out Resource Properties................... 93
13.3.1 DAV:unreserved............................................ 93
13.3.2 DAV:activity-set.......................................... 93
13.4 Additional Workspace Properties.............................. 93
13.4.1 DAV:current-activity-set.................................. 94
13.5 MKACTIVITY Method............................................ 94
13.5.1 Example - MKACTIVITY...................................... 95
13.6 DAV:latest-activity-version Report........................... 95
13.7 Additional OPTIONS Semantics................................. 96
13.8 Additional DELETE Semantics.................................. 96
13.9 Additional MOVE Semantics.................................... 97
13.10 Additional CHECKOUT Semantics............................... 97
13.10.1 Example - CHECKOUT with an activity...................... 98
13.11 Additional CHECKIN Semantics................................ 99
13.12 Additional MERGE Semantics.................................. 99
14 Version-Controlled-Collection Feature.........................100
14.1 Version-Controlled Collection Properties.....................102
14.1.1 DAV:eclipsed-set (computed)...............................102
14.2 Collection Version Properties................................103
14.2.1 DAV:version-controlled-binding-set (protected)............103
14.3 Additional OPTIONS Semantics.................................103
14.4 Additional DELETE Semantics..................................103
14.5 Additional MKCOL Semantics...................................104
14.6 Additional COPY Semantics....................................104
14.7 Additional MOVE Semantics....................................104
12.4 追加リソースの特性… 79 12.4.1 DAV: バージョンの制御構成(計算されます)… 79 12.5 追加ワークスペースの特性… 80 12.5.1 基線の制御収集がセットしている(計算されます)DAV… 80 12.6 基線コントロールメソッド… 80 12.6.1 基線例--コントロール… 82 12.7 DAV: 基線を比較しているレポート… 84 12.7.1、例--DAV: 基線を比較しているレポート… 85 12.8 追加オプション意味論… 86 12.9 追加MKCOL意味論… 86 12.10 複本意味論… 86 12.11 追加チェックアウト意味論… 86 12.12 追加チェックイン意味論… 86 12.13 追加アップデート意味論… 87 12.14 追加マージ意味論… 89 13活動機能… 90 13.1 活動の特性… 91 13.1.1 DAV: 活動バージョンセット(計算されます)… 91 13.1.2 DAV: 活動チェックアウトセット(計算されます)… 92 13.1.3 DAV: 「副-活動」でセットしてください… 92 13.1.4 現在のワークスペースがセットしている(計算されます)DAV… 92 13.2 追加バージョンの特性… 92 13.2.1 DAV: 活動でセットしてください… 93 13.3 調べている追加リソースの特性… 93 13.3.1、DAV: 無遠慮… 93 13.3.2 DAV: 活動でセットしてください… 93 13.4 追加ワークスペースの特性… 93 13.4.1 DAV: 現在の活動セット… 94 13.5 MKACTIVITYメソッド… 94 13.5.1 例--、MKACTIVITY… 95 13.6 DAV: 最新の活動バージョンレポート… 95 13.7 追加オプション意味論… 96 13.8、追加、意味論を削除してください… 96 13.9 追加移動意味論… 97 13.10 追加チェックアウト意味論… 97 13.10.1 例--、活動があるCHECKOUT… 98 13.11 追加チェックイン意味論… 99 13.12 追加マージ意味論… 99 14バージョンの制御収集機能…100 14.1 バージョンで制御された収集の特性…102 14.1 .1 DAV: おおい隠されたセット(計算されます)…102 14.2 収集バージョンの特性…103 14.2 .1 DAV: バージョンの制御結合はセットしました(保護されます)…103 14.3 追加オプション意味論…103、14.4、追加、意味論を削除してください…103 14.5 追加MKCOL意味論…104 14.6 複本意味論…104 14.7 追加移動意味論…104
Clemm, et al. Standards Track [Page 5] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[5ページ]。
14.8 Additional VERSION-CONTROL Semantics.........................104 14.9 Additional CHECKOUT Semantics................................105 14.10 Additional CHECKIN Semantics................................105 14.11 Additional UPDATE and MERGE Semantics.......................106 15 Internationalization Considerations...........................106 16 Security Considerations.......................................107 16.1 Auditing and Traceability....................................107 16.2 Increased Need for Access Control............................108 16.3 Security Through Obscurity...................................108 16.4 Denial of Service............................................108 17 IANA Considerations...........................................109 18 Intellectual Property.........................................109 19 Acknowledgements..............................................109 20 References....................................................110 Appendix A - Resource Classification..............................111 A.1 DeltaV-Compliant Unmapped URL.................................111 A.2 DeltaV-Compliant Resource.....................................111 A.3 DeltaV-Compliant Collection...................................112 A.4 Versionable Resource..........................................112 A.5 Version-Controlled Resource...................................112 A.6 Version.......................................................113 A.7 Checked-In Version-Controlled Resource........................113 A.8 Checked-Out Resource..........................................113 A.9 Checked-Out Version-Controlled Resource.......................114 A.10 Working Resource.............................................114 A.11 Version History..............................................114 A.12 Workspace....................................................115 A.13 Activity.....................................................115 A.14 Version-Controlled Collection................................115 A.15 Collection Version...........................................115 A.16 Version-Controlled Configuration.............................116 A.17 Baseline.....................................................116 A.18 Checked-Out Version-Controlled Configuration.................116 Authors' Addresses................................................117 Full Copyright Statement..........................................118
14.8 追加バージョンコントロール意味論…104 14.9 追加チェックアウト意味論…105 14.10 追加チェックイン意味論…105 14.11の追加アップデートとマージ意味論…106 15 国際化問題…106 16 セキュリティ問題…107 16.1の監査と追随性…107 16.2はアクセスコントロールの必要性を増強しました…108 不鮮明を通した16.3セキュリティ…108 16.4サービス妨害…108 17 IANA問題…109 18知的所有権…109 19の承認…109 20の参照箇所…110 付録A--リソース分類…111のA.1 DeltaV対応することのUnmapped URL…111のA.2 DeltaV対応することのリソース…111 A.3 DeltaV対応することの収集…112A.4 Versionableリソース…112 A.5はリソースをバージョンで制御しました…112 A.6バージョン…113 A.7はバージョンで制御されたリソースを預けました…113 A.8はリソースを調べました…113 A.9はバージョンで制御されたリソースを調べました…114のA.10の働くリソース…114 A.11バージョン歴史…114 A.12ワークスペース…115 A.13活動…115 A.14は収集をバージョンで制御しました…115 A.15収集バージョン…115 A.16は構成をバージョンで制御しました…116A.17基線…116 A.18はバージョンで制御された構成を調べました…116人の作者のアドレス…117 完全な著作権宣言文…118
1 Introduction
1つの序論
This document specifies a set of methods, headers, and properties that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. Versioning is concerned with tracking and accessing the history of important states of a web resource, such as a standalone web page. The benefits of versioning in the context of the worldwide web include:
このドキュメントはHTTP/1.1プロトコルに拡大をversioningしながらWebDAV(ウェブDistributed AuthoringとVersioning)を定義する1セットのメソッド、ヘッダー、および特性を指定します。 Versioningはウェブリソースの重要な州の歴史を追跡して、アクセスするのに関係があります、スタンドアロンウェブページのように。 世界的なウェブの文脈でversioningする利益は:
Clemm, et al. Standards Track [Page 6] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[6ページ]。
- A resource has an explicit history and a persistent identity
across the various states it has had during the course of that
history. It allows browsing through past and alternative versions
of a resource. Frequently the modification and authorship history
of a resource is critical information in itself.
- リソースはそれがその歴史のコースの間に持っている様々な州の向こう側に明白な歴史と永続的なアイデンティティを持っています。 それは過去とリソースの異本にブラウジングの通ることを許します。 本来頻繁に、リソースの変更と著述業歴史は重要情報です。
- Resource states (versions) are given stable names that can support
externally stored links for annotation and link server support.
Both annotation and link servers frequently need to store stable
references to portions of resources that are not under their
direct control. By providing stable states of resources, version
control systems allow not only stable pointers into those
resources, but also well defined methods to determine the
relationships of those states of a resource.
- 注釈のために外部的に保存されたリンクを支えて、サーバサポートをリンクできる安定した名前をリソース州(バージョン)に与えます。 注釈とリンクサーバの両方が、頻繁に彼らの直轄でないリソースの部分の安定した参照を保存する必要があります。 リソースの安定状態を提供することによって、バージョン管理システムはそれらのリソースへの安定した指針だけではなく、リソースのそれらの州の関係を決定するよく定義されたメソッドも許容します。
WebDAV Versioning defines both basic and advanced versioning functionality.
WebDAV Versioningは基本的なものと同様に高度なversioningの機能性を定義します。
Basic versioning allows users to:
基本的なversioningは、以下のことをユーザは許容します。
- Put a resource under version control
- Determine whether a resource is under version control
- Determine whether a resource update will automatically be captured
as a new version
- Create and access distinct versions of a resource
- リソースをバージョンコントロールの下に置いてください--リソースがバージョンコントロールの下にあるか決定してください--リソース最新版が新しいバージョンとして自動的に得られるかどうか決定してください--リソースの異なったバージョンを作成して、アクセスしてください。
Advanced versioning provides additional functionality for parallel development and configuration management of sets of web resources.
高度なversioningはウェブリソースのセットの並行開発と構成管理のための追加機能性を提供します。
This document will first define the properties and method semantics for the basic versioning features, and then define the additional properties and method semantics for the advanced versioning features. An implementer that is only interested in basic versioning should skip the advanced versioning sections (Section 10 to Section 14).
このドキュメントは、最初に基本的なversioningのための意味論が特徴とする特性とメソッドを定義して、次に、高度なversioningのための意味論が特徴とする追加特性とメソッドを定義するでしょう。 基本的なversioningするだけでありたいimplementerは高度なversioningセクション(セクション10からセクション14)をスキップするはずです。
1.1 Relationship to WebDAV
1.1 WebDAVとの関係
To maximize interoperability and the use of existing protocol functionality, versioning support is designed as extensions to the WebDAV protocol [RFC2518], which itself is an extension to the HTTP protocol [RFC2616]. All method marshalling and postconditions defined by RFC 2518 and RFC 2616 continue to hold, to ensure that versioning unaware clients can interoperate successfully with versioning servers. Although the versioning extensions are designed to be orthogonal to most aspects of the WebDAV and HTTP protocols, a clarification to RFC 2518 is required for effective interoperable versioning. This clarification is described in Section 1.7.
既存のプロトコルの機能性の相互運用性と使用を最大にするために、WebDAVへの拡大が[RFC2518](それ自体で、HTTPプロトコル[RFC2616]への拡大である)について議定書の中で述べるとき、サポートをversioningするのは設計されます。 RFC2518とRFC2616によって定義されたすべてのメソッドの整理とpostconditionsは成立して、気づかないクライアントをversioningするのがサーバをversioningするのに首尾よく共同利用できるのを保証し続けています。 versioning拡大はWebDAVとHTTPプロトコルのほとんどの局面と直交しているように設計されていますが、RFC2518への明確化が有効な共同利用できるversioningに必要です。 この明確化はセクション1.7で説明されます。
Clemm, et al. Standards Track [Page 7] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[7ページ]。
1.2 Notational Conventions
1.2 記号法のコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
The term "protected" is placed in parentheses following the definition of a protected property (see Section 1.4.2).
保護された特性の定義に続いて、「保護」という用語は括弧に置かれます(セクション1.4.2を見てください)。
The term "computed" is placed in parentheses following the definition of a computed property (see Section 1.4.3).
計算された特性の定義に続いて、「計算」という用語は括弧に置かれます(セクション1.4.3を見てください)。
When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type.
中のXML要素型である、「DAV:」 名前空間が本書ではXML断片、ストリングの文脈の外で参照をつけられる、「DAV:」 要素型へ前に置かれるでしょう。
When a method is defined in this document, a list of preconditions and postconditions will be defined for that method. If the semantics of an existing method is being extended, a list of additional preconditions and postconditions will be defined. A precondition or postcondition is prefixed by a parenthesized XML element type that identifies that precondition or postcondition (see Section 1.6).
メソッドが本書では定義されるとき、前提条件とpostconditionsのリストはそのメソッドのために定義されるでしょう。 既存のメソッドの意味論が敷衍されていると、追加前提条件とpostconditionsのリストは定義されるでしょう。 前提条件かpostconditionがその前提条件かpostconditionを特定するparenthesized XML要素型によって前に置かれています(セクション1.6を見てください)。
1.3 Terms
1.3 用語
This document uses the terms defined in RFC 2616, in RFC 2518, and in this section. Section 2.2 defines the semantic versioning model underlying this terminology.
このドキュメントはRFC2616、RFC2518、およびこのセクションで定義された用語を使用します。 セクション2.2はこの用語の基礎となる意味versioningモデルを定義します。
Version Control, Checked-In, Checked-Out
預けているバージョンコントロールはチェックアウトされました。
"Version control" is a set of constraints on how a resource can be
updated. A resource under version control is either in a
"checked-in" or "checked-out" state, and the version control
constraints apply only while the resource is in the checked-in
state.
「バージョンコントロール」はどうリソースをアップデートできるかにおける1セットの規制です。 バージョンコントロールの下におけるリソースが「預けられた」aか「チェックのアウト」状態にあります、そして、リソースが預けている状態にあるだけである間、バージョンコントロール規制は適用されます。
Versionable Resource
「バージョン-可能」リソース
A "versionable resource" is a resource that can be put under
version control.
「「バージョン-可能」リソース」はバージョンコントロールの下で置くことができるリソースです。
Version-Controlled Resource
バージョンで制御されたリソース
When a versionable resource is put under version control, it
becomes a "version-controlled resource". A version-controlled
resource can be "checked out" to allow modification of its content
or dead properties by standard HTTP and WebDAV methods.
「バージョン-可能」リソースがバージョンコントロールの下で置かれるとき、それは「バージョンで制御されたリソース」になります。 標準のHTTPとWebDAVメソッドによる満足しているか死んでいる特性の変更を許すためにバージョンで制御されたリソースを「調べることができます」。
Clemm, et al. Standards Track [Page 8] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[8ページ]。
Checked-Out Resource
調べているリソース
A "checked-out resource" is a resource under version control that
is in the checked-out state.
「調べているリソース」は調べている状態にあるバージョンコントロールの下でリソースです。
Version Resource
バージョンリソース
A "version resource", or simply "version", is a resource that
contains a copy of a particular state (content and dead
properties) of a version-controlled resource. A version is
created by "checking in" a checked-out resource. The server
allocates a distinct new URL for each new version, and this URL
will never be used to identify any resource other than that
version. The content and dead properties of a version never
change.
「バージョンリソース」、または単に「バージョン」がバージョンで制御されたリソースの特定の状態(満足していて死んでいる特性)のコピーを含むリソースです。 バージョンは、調べているリソースが「記帳」であることによって、作成されます。 サーバはそれぞれの新しいバージョンのために異なった新しいURLを割り当てます、そして、このURLは、そのバージョン以外のどんなリソースも特定するのに決して使用されないでしょう。 バージョンの満足していて死んでいる資産は決して変化しません。
Version History Resource
バージョン歴史リソース
A "version history resource", or simply "version history", is a
resource that contains all the versions of a particular version-
controlled resource.
「バージョン歴史リソース」、または単に「バージョン歴史」が特定のバージョン制御リソースのすべてのバージョンを含むリソースです。
Version Name
バージョン名
A "version name" is a string chosen by the server to distinguish
one version of a version history from the other versions of that
version history. Versions from different version histories may
have the same version name.
「バージョン名」はそのバージョン歴史の他のバージョンからのバージョン歴史の1つのバージョンを区別するサーバによって選ばれたストリングです。 異なった見解歴史からのバージョンには、同じバージョン名があるかもしれません。
Predecessor, Successor, Ancestor, Descendant
前任者、後継者、先祖、子孫
When a version-controlled resource is checked out and then
subsequently checked in, the version that was checked out becomes
a "predecessor" of the version created by the checkin. A client
can specify multiple predecessors for a new version if the new
version is logically a merge of those predecessors. When a
version is connected to another version by traversing one or more
predecessor relations, it is called an "ancestor" of that version.
The inverse of the predecessor and ancestor relations are the
"successor" and "descendant" relations. Therefore, if X is a
predecessor of Y, then Y is a successor of X, and if X is an
ancestor of Y, then Y is a descendant of X.
バージョンで制御されたリソースが調べられて、次に、次に預けられるとき、調べられたバージョンはチェックインで作成されたバージョンの「前任者」になります。 新しいバージョンが論理的に、aがそれらの前任者に合併するということであるなら、クライアントは新しいバージョンに複数の前任者を指定できます。 バージョンが1つ以上の前任者関係を横断することによって別のバージョンに関連づけられるとき、それはそのバージョンの「先祖」と呼ばれます。 前任者の逆と先祖関係は、「後継者」と「下降」の関係です。 したがって、XがYの前任者であるなら、YはXの後継者です、そして、XがYの先祖であるなら、YはXの子孫です。
Root Version Resource
根のバージョンリソース
The "root version resource", or simply "root version", is the
version in a version history that is an ancestor of every other
version in that version history.
「根のバージョンリソース」、または単に「根のバージョン」がそのバージョン歴史の他のあらゆるバージョンの先祖であるバージョン歴史のバージョンです。
Clemm, et al. Standards Track [Page 9] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[9ページ]。
Workspace Resource
ワークスペースリソース
A "workspace resource", or simply "workspace", is a collection
that contains at most one version-controlled resource for a given
version history (see Section 6).
「ワークスペースリソース」、または単に「ワークスペース」が与えられたバージョン歴史のための1つのバージョンで制御されたリソースを高々含む収集(セクション6を見る)です。
Working Resource
働くリソース
A "working resource" is a checked-out resource created by the
server at a server-defined URL when a version (instead of a
version-controlled resource) is checked out. Unlike a checked-out
version-controlled resource, a working resource is deleted when it
is checked in.
「働くリソース」はバージョン(バージョンで制御されたリソースの代わりに)が調べられるときサーバで定義されたURLでサーバによって作成された調べているリソースです。 それが預けられるとき、調べているバージョンで制御されたリソースと異なって、働くリソースは削除されます。
Fork, Merge
フォーク、マージ
When a second successor is added to a version, this creates a
"fork" in the version history. When a version is created with
multiple predecessors, this creates a "merge" in the version
history. A server may restrict the version history to be linear
(with no forks or merges), but an interoperable versioning client
should be prepared to deal with both forks and merges in the
version history.
2番目の後継者がバージョンに追加されるとき、これはバージョン歴史で「フォーク」を作成します。 バージョンが複数の前任者と共に作成されるとき、これはバージョン歴史における「マージ」を作成します。 サーバが直線的になるようにバージョン歴史を制限するかもしれない、(いいえが分岐するか、または合併する、)、共同利用できるversioningクライアントだけが、両方のフォークに対処するように準備されるべきであり、バージョン歴史で合併します。
Clemm, et al. Standards Track [Page 10] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[10ページ]。
The following diagram illustrates several of the previous definitions. Each box represents a version and each line between two boxes represents a predecessor/successor relationship. For example, it shows V3 is a predecessor of V5, V7 is a successor of V5, V1 is an ancestor of V4, and V7 is a descendant of V4. It also shows that there is a fork at version V2 and a merge at version V7.
以下のダイヤグラムは前のいくつかの定義を例証します。 各箱はバージョンを表します、そして、2個の箱の間の各系列は前任者/後継者関係を表します。 例えば、V3がV5の前任者であることを示します、そして、V7はV5の後継者です、そして、V1はV4の先祖です、そして、V7はV4の子孫です。 また、それは、バージョンV2とマージにはフォークがバージョンV7にあるのを示します。
History of foo.html
foo.htmlの歴史
+---+
Root Version -------> | | V1
+---+ ^
| |
| |
+---+ |
Version Name ----> V2 | | | Ancestor
+---+ |
/ \ |
/ \ |
+---+ +---+
| | V3 | | V4
^ +---+ +---+
| | | |
Predecessor | | | |
+---+ +---+ |
| | V5 | | V6 | Descendant
+---+ +---+ |
Successor | \ / |
| \ / |
v +---+ v
| | V7
+---+
+---+ ルートバージョン------->|、| V1+---+ ^ | | | | +---+ | バージョン名---->V2| | | 先祖+---+ | / \ | / \ | +---+ +---+ | | V3| | V4^ +---+ +---+ | | | | 前任者| | | | +---+ +---+ | | | V5| | V6| 子孫+---+ +---+ | 後継者| \ / | | \ / | +に対して---+ v| | V7+---+
Label
ラベル
A "label" is a name that can be used to select a version from a
version history. A label can be assigned by either a client or
the server. The same label can be used in different version
histories.
「ラベル」はバージョン歴史からバージョンを選択するのに使用できる名前です。 クライアントかサーバのどちらかはラベルを割り当てることができます。異なった見解歴史で同じラベルを使用できます。
1.4 Property Values
1.4 特性の値
1.4.1 Initial Property Value
1.4.1 初期の資産価値
Unless an initial value of a property of a given type is defined by this document, the initial value of a property of that type is implementation dependent.
与えられたタイプの属性の初期の価値がこのドキュメントによって定義されない場合、そのタイプの属性の初期の価値は実装に依存しています。
Clemm, et al. Standards Track [Page 11] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[11ページ]。
1.4.2 Protected Property Value
1.4.2 保護された資産価値
When a property of a specific kind of resource is "protected", the property value cannot be updated on that kind of resource except by a method explicitly defined as updating that specific property. In particular, a protected property cannot be updated with a PROPPATCH request. Note that a given property can be protected on one kind of resource, but not protected on another kind of resource.
特定の種類に関するリソースの特性を「保護する」とき、明らかにその特定の性質をアップデートすると定義されたメソッド以外に、その種類に関するリソースで資産価値をアップデートできません。 特に、PROPPATCH要求で保護された特性をアップデートできません。 与えられた特性は1種類のリソースに保護されますが、もう1種類のリソースに保護できないことに注意してください。
1.4.3 Computed Property Value
1.4.3 計算された資産価値
When a property is "computed", its value is defined in terms of a computation based on the content and other properties of that resource, or even of some other resource. When the semantics of a method is defined in this document, the effect of that method on non-computed properties will be specified; the effect of that method on computed properties will not be specified, but can be inferred from the computation defined for those properties. A computed property is always a protected property.
特性が「計算される」とき、値はそのリソース、またはある他のリソースさえの内容と他の特性に基づく計算で定義されます。 メソッドの意味論が本書では定義されるとき、非計算された所有地へのそのメソッドの効果は指定されるでしょう。 計算された所有地へのそのメソッドの効果を指定されませんが、それらの特性のために定義された計算から推論できます。 いつも計算された特性は保護された特性です。
1.4.4 Boolean Property Value
1.4.4 ブール資産価値
Some properties take a Boolean value of either "false" or "true".
いくつかの特性がどちらかのブール値を「虚偽で」取るか、「本当に。」
1.4.5 DAV:href Property Value
1.4.5 DAV: href資産価値
The DAV:href XML element is defined in RFC 2518, Section 12.3.
DAV: href XML要素はRFC2518、セクション12.3で定義されます。
1.5 DAV Namespace XML Elements in Request and Response Bodies
1.5 要求におけるDAV名前空間XML要素と応答本体
Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC.
WebDAV要求と応答本体を任意のXML要素(メッセージ受取人は無視できる)で広げることができますが、そのXML要素がIETF RFCで明らかに定義されない場合、versioningメソッドの要求か応答本体でDAV名前空間におけるXML要素を使用してはいけません。
1.6 Method Preconditions and Postconditions
1.6 メソッド前提条件とPostconditions
A "precondition" of a method describes the state of the server that must be true for that method to be performed. A "postcondition" of a method describes the state of the server that must be true after that method has been completed. If a method precondition or postcondition for a request is not satisfied, the response status of the request MUST be either 403 (Forbidden) if the request should not be repeated because it will always fail, or 409 (Conflict) if it is expected that the user might be able to resolve the conflict and resubmit the request.
メソッドの「前提条件」はその実行されるべきメソッドに、正しいに違いないサーバの事情について説明します。 メソッドの"postcondition"はそのメソッドが完成した後に正しいに違いないサーバの事情について説明します。 要求のためのメソッド前提条件かpostconditionが満たされていないなら、要求の状態が403(禁じられる)がいつも失敗するので要求を繰り返すべきでないか、そして、409(闘争)であったならユーザが対立を解決して、要求を再提出できるかもしれないと予想されるならそうしなければならない応答です。
Clemm, et al. Standards Track [Page 12] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[12ページ]。
In order to allow better client handling of 403 and 409 responses, a distinct XML element type is associated with each method precondition and postcondition of a request. When a particular precondition is not satisfied or a particular postcondition cannot be achieved, the appropriate XML element MUST be returned as the child of a top-level DAV:error element in the response body, unless otherwise negotiated by the request. In a 207 Multi-Status response, the DAV:error element would appear in the appropriate DAV:responsedescription element.
403と409の、より良いクライアント取り扱いに応答、異なったXMLを許容するために、要素型は要求のそれぞれのメソッド前提条件とpostconditionに関連しています。 特定の前提条件を満たさないことができないか、特定のpostconditionを達成できないとき、トップレベルDAV: 誤り要素の子供として応答本体で適切なXML要素を返さなければなりません、別の方法で要求で交渉されない場合。 207Multi-状態応答、DAVで: 誤り要素は適切なDAVに現れるでしょう: responsedescription要素
1.6.1 Example - CHECKOUT request with DAV:must-be-checked-in response
1.6.1 例--DAV: 預けなければならない応答によるCHECKOUT要求
>>REQUEST
>>要求
CHECKOUT /foo.html HTTP/1.1
Host: www.webdav.org
チェックアウト/foo.html HTTP/1.1ホスト: www.webdav.org
>>RESPONSE
>>応答
HTTP/1.1 409 Conflict
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 409闘争コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:error xmlns:D="DAV:">
<D:must-be-checked-in/>
</D:error>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 誤りxmlns: Dが等しい、「DAV: 「><D: 中でチェックしなければならない/></D: 誤り>」
In this example, the request to CHECKOUT /foo.html fails because /foo.html is not checked in.
この例では、/foo.htmlが預けられないので、CHECKOUT /foo.htmlへの要求は失敗します。
1.7 Clarification of COPY Semantics with Overwrite:T
重ね書きとのコピー意味論の1.7明確化: T
RFC 2518, Section 8.8.4 states:
RFC2518、セクション8.8.4の州:
"If a resource exists at the destination and the Overwrite header is "T" then prior to performing the copy the server MUST perform a DELETE with "Depth: infinity" on the destination resource."
「リソースが目的地とOverwriteヘッダーに存在しているならそして、サーバが実行しなければならないコピーを実行する前の「T」がaである、削除、「深さ:」 目的地リソースに関する「無限」、」
The purpose of this sentence is to ensure that following a COPY, all destination resources have the same content and dead properties as the corresponding resources identified by the request-URL (where a resource with a given name relative to the Destination URL "corresponds" to a resource with the same name relative to the request-URL). If at the time of the request, there already is a resource at the destination that has the same resource type as the corresponding resource at the request-URL, that resource MUST NOT be deleted, but MUST be updated to have the content and dead properties
この文の目的はCOPYに続いて、要求URL(Destination URLに比例した名がいるリソースが同じ名前で要求URLに比例してリソースに「対応する」ところ)で対応するリソースが特定したようにすべての目的地リソースには同じ内容と死んでいる特性があるのを保証することです。 リソースが要求時点で対応するリソースと同じリソースタイプが要求URLにある目的地に既にあれば、そのリソースを削除してはいけませんが、満足していて死んでいる特性を持つためにアップデートしなければなりません。
Clemm, et al. Standards Track [Page 13] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[13ページ]。
of its corresponding member. If a client wishes all resources at the destination to be deleted prior to the COPY, it MUST explicitly issue a DELETE request.
通信会員について。 クライアントが、目的地のすべてのリソースがCOPYの前で削除されて欲しいなら、それは明らかにDELETE要求を出さなければなりません。
The difference between updating a resource and replacing a resource with a new resource is especially important when resource history is being maintained (the former adds to an existing history, while the latter creates a new history). In addition, locking and access control constraints might allow you to update a resource, but not allow you to delete it and create a new one in its place.
リソース歴史が維持されているとき(前者は既存の歴史に加えます、後者が新しい歴史を引き起こしますが)、リソースをアップデートして、リソースを新しいリソースに取り替えるところの違いは特に重要です。 さらに、ロックとアクセス制御規制は、あなたをリソースをアップデートしますが、あなたが場所でそれを削除して、新しいものを作成するのを許容しないかもしれません。
Note that this clarification does not apply to a MOVE request. A MOVE request with Overwrite:T MUST perform the DELETE with "Depth:infinity" on the destination resource prior to performing the MOVE.
この明確化がMOVE要求に適用されないことに注意してください。 OverwriteとのMOVE要求: MOVEを実行する前に、Tは目的地リソースに関する「深さ: 無限」でDELETEを実行しなければなりません。
1.8 Versioning Methods and Write Locks
1.8、メソッドをVersioningして、錠を書きます。
If a write-locked resource has a non-computed property defined by this document, the property value MUST NOT be changed by a request unless the appropriate lock token is included in the request. Since every method introduced in this document other than REPORT modifies at least one property defined by this document, every versioning method other than REPORT is affected by a write lock. In particular, the method MUST fail with a 423 (Locked) status if the resource is write-locked and the appropriate token is not specified in an If request header.
aである、書く、-、ロック、リソースには、このドキュメントによって定義された非計算された特性があって、要求に適切なロックトークンを含んでいない場合、要求で資産価値を変えてはいけません。 本書ではREPORTを除いて、導入されたあらゆるメソッドが定義された少なくとも1つの特性を変更するので、このドキュメント、影響を受けるREPORT以外のあらゆるversioningメソッドで、aで錠を書いてください。 そして、リソースが失敗するなら423(ロックされる)状態に応じて特に、メソッドが失敗しなければならない、書く、-、ロック、適切なトークンはIf要求ヘッダーで指定されません。
2 Basic Versioning Features
2 基本のVersioningの特徴
Each basic versioning feature defines extensions to existing HTTP and WebDAV methods, as well as new resource types, live properties, and methods.
それぞれの基本のversioningの特徴は既存のHTTPとWebDAVメソッドと拡大を定義します、新しいリソースタイプ、精力の特性、およびメソッドと同様に。
2.1 Basic Versioning Packages
2.1 基本的なVersioningパッケージ
A server MAY support any combination of versioning features. However, in order to minimize the complexity of a WebDAV basic versioning client, a WebDAV basic versioning server SHOULD support one of the following three "packages" (feature sets):
サーバはversioningの特徴のどんな組み合わせもサポートするかもしれません。 しかしながら、WebDAVの基本的なversioningクライアントの複雑さを最小にするために、SHOULDが以下の3の1つをサポートするWebDAVの基本的なversioningサーバは(特徴セット)を「パッケージします」:
- Core-Versioning Package: version-control
- Basic-Server-Workspace Package: version-control, workspace,
version-history, checkout
- Basic-Client-Workspace Package: version-control, working-
resource, update, label
- コア-Versioningは以下をパッケージします。 バージョンコントロール--基本的なサーバワークスペースパッケージ: バージョンコントロール、ワークスペース、バージョン歴史、チェックアウト--基本的なクライアントワークスペースパッケージ: バージョンコントロール、働くリソース、アップデート、ラベル
Clemm, et al. Standards Track [Page 14] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[14ページ]。
The core-versioning package supports linear versioning by both versioning-aware and versioning-unaware clients. A versioning-aware client can use reports and properties to access previous versions of a version-controlled resource.
コアをversioningするパッケージはversioning意識しているものと同様にversioning気づかないクライアントによる直線的なversioningをサポートします。 versioning意識しているクライアントは、バージョンで制御されたリソースの旧バージョンにアクセスするのにレポートと特性を使用できます。
The basic workspace packages support parallel development of version-controlled resources. Each client has its own configuration of the shared version-controlled resources, and can make changes to its configuration without disturbing that of another client.
基本的なワークスペースパッケージはバージョンで制御されたリソースの並行開発をサポートします。 別のクライアントのものを擾乱しないで、各クライアントは、それ自身の共有されたバージョンで制御されたリソースの構成を持って、構成への変更を行うことができます。
In the basic-server-workspace package, all persistent state is maintained on the server. Each client has its own workspace resource allocated on the server, where each workspace identifies a configuration of the shared version-controlled resources. Each client makes changes to its workspace, and can transfer changes when appropriate from one workspace to another. The server workspace package is appropriate for clients with no local persistent state, or for clients that wish to expose their working configurations to other clients.
基本的なサーバワークスペースパッケージの中では、すべての永続的な状態がサーバで主張されます。各クライアントはサーバにそれ自身のワークスペースリソースを割り当てさせます。(そこでは、各ワークスペースが共有されたバージョンで制御されたリソースの構成を特定します)。 各クライアントは、ワークスペースへの変更を行って、1つのワークスペースから別のワークスペースまで適切であるときに、変化を移すことができます。 地方の永続的な状態のないクライアント、または他のクライアントに彼らの仕事の構成を暴露したがっているクライアントにとって、サーバワークスペースパッケージは適切です。
In the basic-client-workspace package, each client maintains in local persistent storage the state for its configuration of the shared version-controlled resources. When a client is ready to make its changes visible to other clients, it allocates a set of "working resources" on the server, updates the content and dead properties of these working resources, and then uses the set of working resources to update the version-controlled resources. The working resources are used, instead of directly updating the version-controlled resources, so that sets of consistent updates can be prepared in parallel by multiple clients. Also, a working resource allows a client to prepare a single update that requires multiple server requests (e.g. updating both the content and dead properties of a resource requires both a PUT and a PROPPATCH). The client workspace package simplifies the server implementation by requiring each client to maintain its own namespace, but this requires that the clients have local persistent state, and does not allow clients to expose their working configurations to other clients.
基本的なクライアントワークスペースパッケージの中では、各クライアントは共有されたバージョンで制御されたリソースの構成のために地方の永続的なストレージで状態を維持します。 クライアントが変更を他のクライアントにとって目に見えるようにする準備ができているなら、それは、1セットのサーバに関する「働くリソース」を割り当てて、これらの働くリソースの満足していて死んでいる特性をアップデートして、バージョンで制御されたリソースをアップデートするのに働くリソースのセットを使用します。 直接バージョンで制御されたリソースをアップデートすることの代わりに働くリソースは使用されます、複数のクライアントが平行で一貫したアップデートのセットを準備できるように。 また、働くリソースで、クライアントは複数のサーバ要求を必要とするただ一つのアップデートを準備できます(例えば、リソースの両方の満足していて死んでいる特性をアップデートするのはPUTとPROPPATCHの両方を必要とします)。 クライアントワークスペースパッケージは、各クライアントが、しかし、それ自身の名前空間、これが、クライアントには地方の永続的な状態があるのを必要とすると主張するのを必要とすることによってサーバ実装を簡素化して、クライアントが他のクライアントに彼らの仕事の構成を暴露するのを許容しません。
A server that supports both basic workspace packages will interoperate with all basic versioning clients.
すべてが基本的に両方が基本的なワークスペースパッケージであるとサポートするサーバは、クライアントをversioningしながら、共同利用するでしょう。
Clemm, et al. Standards Track [Page 15] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[15ページ]。
2.2 Basic Versioning Semantics
2.2 基本的なVersioning意味論
2.2.1 Creating a Version-Controlled Resource
2.2.1 バージョンで制御されたリソースを作成すること。
In order to track the history of the content and dead properties of a versionable resource, a user can put the resource under version control with a VERSION-CONTROL request. A VERSION-CONTROL request performs three distinct operations:
「バージョン-可能」リソースの満足していて死んでいる特性の歴史を追跡するために、ユーザはリソースをバージョン-CONTROL要求によるバージョンコントロールの下に置くことができます。 バージョン-CONTROL要求は3つの異なった操作を実行します:
1) It creates a new "version history resource". In basic versioning,
a version history resource is not assigned a URL, and hence is not
visible in the http scheme URL space. However, when the version-
history feature (see Section 5) is supported, this changes, and
each version history resource is assigned a new distinct and
unique server-defined URL.
1) それは新しい「バージョン歴史リソース」を作成します。 基本的なversioningでは、バージョン歴史リソースは、URLが割り当てられないで、またしたがって、http体系URLスペースで目に見えません。 しかしながら、バージョンヒストリ機能(セクション5を見る)がサポートされるとき、これは変化します、そして、新しい異なってユニークなサーバで定義されたURLはそれぞれのバージョン歴史リソースに割り当てられます。
2) It creates a new "version resource" and adds it to the new version
history resource. The body and dead properties of the new version
resource are a copy of those of the versionable resource.
2) それは、新しい「バージョンリソース」を作成して、新しいバージョン歴史リソースにそれを追加します。 新しいバージョンリソースのボディーと死んでいる特性は「バージョン-可能」リソースのもののコピーです。
The server assigns the new version resource a new distinct and
unique URL.
サーバは新しい異なってユニークなURLを新しいバージョンリソースに割り当てます。
3) It converts the versionable resource into a "version-controlled
resource". The version-controlled resource continues to be
identified by the same URL that identified it as a versionable
resource. As part of this conversion, it adds a DAV:checked-in
property, whose value contains the URL of the new version
resource.
3) それは「バージョンで制御されたリソース」に「バージョン-可能」リソースを変換します。 バージョンで制御されたリソースは、それが「バージョン-可能」リソースであると認識したのと同じURLによって特定され続けています。 この変換の一部として、DAVを加えます: 値が新しいバージョンリソースのURLを含む特性を預けます。
Note that a versionable resource and a version-controlled resource are not new types of resources (i.e. they introduce no new DAV:resourcetype), but rather they are any type of resource that supports the methods and live properties defined for them in this document, in addition to all the methods and live properties implied by their DAV:resourcetype. For example, a collection (whose DAV:resourcetype is DAV:collection) is a versionable resource if it supports the VERSION-CONTROL method, and is a version-controlled resource if it supports the version-controlled resource methods and live properties.
すべてのメソッドとそれらのDAVによって含意された精力の特性に加えて「バージョン-可能」リソースとバージョンで制御されたリソースが新しいタイプに関するリソース(すなわち、それらは新しいDAVがありません: resourcetypeを導入する)ではありませんが、むしろそれらがそれらのために本書では定義されたメソッドと精力の特性を支えるどんなタイプに関するリソースであることにも注意してください: resourcetype。 例えば、収集、(DAV: resourcetypeがだれのものである、DAV: 収集) 「バージョン-可能」リソースは、それが、バージョン-CONTROLメソッドをサポートして、バージョンで制御されたリソースがメソッドであるとサポートするなら、バージョンで制御されたリソースであるか、そして、精力の特性ですか?
In the following example, foo.html is a versionable resource that is put under version control. After the VERSION-CONTROL request succeeds, there are two additional resources: a new version history resource and a new version resource in that version history. The versionable resource is converted into a version-controlled resource, whose DAV:checked-in property identifies the new version resource.
以下の例では、foo.htmlはバージョンコントロールの下で置かれる「バージョン-可能」リソースです。 バージョン-CONTROL要求が成功した後に、2つの追加リソースがあります: 新しいバージョン歴史リソースとそのバージョン歴史の新しいバージョンリソース。 DAV、「バージョン-可能」リソースはバージョンで制御されたリソースに変換されます: 預けている特性は新しいバージョンリソースを特定します。
Clemm, et al. Standards Track [Page 16] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[16ページ]。
The content and dead properties of a resource are represented by the symbol appearing inside the box for that resource (e.g., "S1" in the following example).
リソースの満足していて死んでいる特性が箱の中にそのリソースに関して現れるシンボルによって表される、(例えば、「以下の例のS1")」
===VERSION-CONTROL==>
===バージョンコントロール=>。
| +----+ version
| version- | | history
versionable | controlled +----+ resource
resource | resource |
/foo.html | /foo.html |
| v
+----+ | +----+ checked-in +----+ version
| S1 | | | S1 |----------->| S1 | resource
+----+ | +----+ +----+ /his/73/ver/1
| +----+ バージョン| バージョン| | 歴史「バージョン-可能」| +を制御します。----+ リソースリソース| リソース| /foo.html| /foo.html| | +に対して----+ | +----+は+を預けました。----+ バージョン| S1| | | S1|、-、-、-、-、-、-、-、-、-、--、>| S1| リソース+----+ | +----+ +----+ /his/73/ver/1
Thus, whereas before the VERSION-CONTROL request there was only one, non-version-controlled resource, after VERSION-CONTROL there are three separate, distinct resources, each containing its own state and properties: the version-controlled resource, the version resource, and the version history resource. Since the version-controlled resource and the version resource are separate, distinct resources, when a method is applied to a version-controlled resource, it is only applied to that version-controlled resource, and is not applied to the version resource that is currently identified by the DAV:checked-in property of that version-controlled resource. Although the content and dead properties of a checked-in version- controlled resource are required to be the same as those of its current DAV:checked-in version, its live properties may differ. An implementation may optimize storage by retrieving the content and dead properties of a checked-in version-controlled resource from its current DAV:checked-in version rather than storing them in the version-controlled resource, but this is just an implementation optimization.
そこでの唯一のバージョン-CONTROL要求は1であっただけです、非バージョンが制御されたリソース、そこのバージョン-CONTROLが3つの別々の、そして、異なったリソースであった後に、それぞれそれ自身の状態と特性を含んでいて: バージョンで制御されたリソース、バージョンリソース、およびバージョン歴史リソース。 メソッドがバージョンで制御されたリソースに適用されるとき、バージョンで制御されたリソースとバージョンリソースが別々の、そして、異なったリソースであるので、それは、そのバージョンで制御されたリソースに適用されるだけであり、現在DAVによって特定されるバージョンリソースに適用されません: そのバージョンで制御されたリソースの特性を預けます。 預けているバージョン制御リソースの満足していて死んでいる特性が現在のDAVのものと同じであることが必要ですが、: 預けているバージョン、精力の特性は異なるかもしれません。 実装は現在のDAVからの預けているバージョンで制御されたリソースの満足していて死んでいる特性を検索することによって、ストレージを最適化するかもしれません: バージョンで制御されたリソースにそれらを保存するよりむしろバージョンを預けます、しかし、これはただ実装最適化です。
Normally, a resource is placed under version control with an explicit VERSION-CONTROL request. A server MAY automatically place every new versionable resource under version control. In this case, the resulting state on the server MUST be the same as if the client had explicitly applied a VERSION-CONTROL request to the versionable resource.
通常、リソースはバージョンコントロールの下で明白なバージョン-CONTROL要求に置かれます。 サーバは自動的にあらゆる新しい「バージョン-可能」リソースをバージョンコントロールの下に置くかもしれません。 この場合、まるでクライアントが明らかにバージョン-CONTROL要求を「バージョン-可能」リソースに適用したかのようにサーバの結果として起こる状態は同じであるに違いありません。
2.2.2 Modifying a Version-Controlled Resource
2.2.2 バージョンで制御されたリソースを変更すること。
In order to use methods like PUT and PROPPATCH to directly modify the content or dead properties of a version-controlled resource, the version-controlled resource must first be checked out. When the checked-out resource is checked in, a new version is created in the
直接バージョンで制御されたリソースの満足しているか死んでいる特性を変更するのにPUTとPROPPATCHのようなメソッドを使用するために、最初に、バージョンで制御されたリソースを調べなければなりません。 いつ調べているリソースは預けられて、新しいバージョンは作成されるか。
Clemm, et al. Standards Track [Page 17] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[17ページ]。
version history of that version-controlled resource. The version that was checked out is remembered as the predecessor of the new version.
そのバージョンで制御されたリソースのバージョン歴史。 調べられたバージョンは新しいバージョンの前任者として覚えていられます。
The DAV:auto-version property (see Sections 3.2.2) of a checked-in version-controlled resource determines how it responds to a method that attempts to modify its content or dead properties. Possible responses include:
DAV: 預けているバージョンで制御されたリソースの自動バージョンの特性(セクション3.2.2を見る)は、それがどのように満足しているか死んでいる特性を変更するのを試みるメソッドに応じるかを決定します。 可能な応答は:
- Fail the request. The resource requires an explicit CHECKOUT
request for it to be modified (see Sections 4 and 9.2.1).
- 要求に失敗してください。 リソースはそれが変更されるという明白なCHECKOUT要求を必要とします(セクション4と9.2.1を見てください)。
- Automatically checkout the resource, perform the modification, and
automatically checkin the resource. This ensures that every state
of the resource is tracked by the server, but can result in an
excessive number of versions being created.
- 自動的にチェックアウト、リソース、変更を実行してください。そうすれば、自動的にチェックインはリソースを実行します。 これは、リソースのあらゆる状態がサーバによって追跡されますが、作成される過度の数のバージョンをもたらすことができるのを確実にします。
- Automatically checkout the resource, perform the modification, and
then if the resource is not write-locked, automatically checkin
the resource. If the resource is write-locked, it remains
checked-out until the write-lock is removed (either explicitly
through a subsequent UNLOCK request or implicitly through a time-
out of the write-lock). This helps a locking client avoid the
proliferation of versions, while still allowing a non-locking
client to update the resource.
- 自動的にチェックアウト、リソース、リソースが実行しないなら変更、およびその時を実行してください、書く、-、ロック、自動的にチェックイン、リソース。 リソースがそうである、書く、-、ロック、錠を書くのを取り除くまで調べられたままで残っている、(aを通して明らかにその後のUNLOCK要求かそれとなく調節する、錠を書きます) これは、非固定しているクライアントがリソースをアップデートするのをまだ許容している間、ロッククライアントがバージョンの増殖を避けるのを助けます。
- Automatically checkout the resource, perform the modification, and
then leave the resource checked out. If the resource is write-
locked, it will be automatically checked in when the write-lock is
removed, but an explicit CHECKIN operation (see Section 4.4) is
required for a non-write-locked resource. This minimizes the
number of new versions that will be created by a versioning
unaware client, but only a versioning aware client can create new
versions of a non-write-locked resource.
- 自動的にチェックアウト、リソースであり、変更を実行して、調べられたリソースはその時、いなくなります。 錠を書くのを取り除くとき、リソースがロックされていた状態で書くことであるなら、自動的にそれを預けますが、aのために、明白なCHECKIN操作(セクション4.4を見る)を必要とする、非、ロックされていた状態で書いてください、リソース。 これがversioning気づかないクライアントによって作成される新しいバージョンの数を最小にしますが、versioning意識しているクライアントだけがaの新しいバージョンを作成できる、非、ロックされていた状態で書いてください、リソース。
- Fail the request unless the resource is write-locked. If it is
write-locked, automatically checkout the resource and perform the
modification. The resource is automatically checked in when the
write-lock is removed. This minimizes the number of new versions
that will be created by a versioning unaware client, but never
automatically checks out a resource that will not subsequently be
automatically checked in.
- リソースが失敗しない場合要求に失敗してください、書く、-、ロック そして、それがそうである、書く、-、ロック、自動的にチェックアウト、リソース、変更を実行してください。 錠を書くのを取り除くとき、自動的にリソースを預けます。 これは、versioning気づかないクライアントによって作成される新しいバージョンの数を最小にしますが、自動的に次に自動的に預けられないリソースを決して調べません。
Clemm, et al. Standards Track [Page 18] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[18ページ]。
The following diagram illustrates the effect of the checkout/checkin process on a version-controlled resource and its version history. The symbol inside a box (S1, S2, S3) represents the current content and dead properties of the resource represented by that box. The symbol next to a box (V1, V2, V3) represents the URL for that resource.
以下のダイヤグラムはバージョンで制御されたリソースとそのバージョン歴史へのチェックアウト/チェックインプロセスの効果を例証します。 箱(S1、S2、S3)の中のシンボルはその箱によって表されたリソースの現在の内容と死んでいる特性を表します。 箱(V1、V2、V3)の横のシンボルはそのリソースのためにURLを表します。
===checkout==> ===PUT==> ===checkin==>
===チェックアウト=>。====>を置いてください。===チェックイン=>。
/foo.html (version-controlled resource)
/foo.html(バージョンで制御されたリソース)
+----+ | +----+ | +----+ | +----+
| S2 | | | S2 | | | S3 | | | S3 |
+----+ | +----+ | +----+ | +----+
Checked-In=V2|Checked-Out=V2|Checked-Out=V2|Checked-In=V3
+----+ | +----+ | +----+ | +----+ | S2| | | S2| | | S3| | | S3| +----+ | +----+ | +----+ | +----+ 預けている=V2|調べている=V2|調べている=V2|預けている=V3
/his/73 (version history for /foo.html)
/his/73(/foo.htmlのためのバージョン歴史)
+----+ | +----+ | +----+ | +----+
| S1 | V1 | | S1 | V1 | | S1 | V1 | | S1 | V1
+----+ | +----+ | +----+ | +----+
| | | | | | |
| | | | | | |
+----+ | +----+ | +----+ | +----+
| S2 | V2 | | S2 | V2 | | S2 | V2 | | S2 | V2
+----+ | +----+ | +----+ | +----+
| | | |
| | | |
| | | +----+
| | | | S3 | V3
| | | +----+
+----+ | +----+ | +----+ | +----+ | S1 | V1 | | S1 | V1 | | S1 | V1 | | S1 | V1 +----+ | +----+ | +----+ | +----+ | | | | | | | | | | | | | | +----+ | +----+ | +----+ | +----+ | S2 | V2 | | S2 | V2 | | S2 | V2 | | S2 | V2 +----+ | +----+ | +----+ | +----+ | | | | | | | | | | | +----+ | | | | S3 | V3 | | | +----+
Note that a version captures only a defined subset of the state of a resource. In particular, a version of a basic resource captures its content and dead properties, but not its live properties.
Note that a version captures only a defined subset of the state of a resource. In particular, a version of a basic resource captures its content and dead properties, but not its live properties.
2.2.3 Reporting
2.2.3 Reporting
Some versioning information about a resource requires that parameters be specified along with that request for information. Included in basic versioning is the required support for an extensible reporting mechanism, which includes a REPORT method as well as a live property for determining what reports are supported by a particular resource. The REPORT method is required by versioning, but it can be used in non-versioning WebDAV extensions.
Some versioning information about a resource requires that parameters be specified along with that request for information. Included in basic versioning is the required support for an extensible reporting mechanism, which includes a REPORT method as well as a live property for determining what reports are supported by a particular resource. The REPORT method is required by versioning, but it can be used in non-versioning WebDAV extensions.
Clemm, et al. Standards Track [Page 19] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 19] RFC 3253 Versioning Extensions to WebDAV March 2002
To allow a client to query the properties of all versions in the version history of a specified version-controlled resource, basic versioning provides the DAV:version-tree report (see Section 3.7). A more powerful version history reporting mechanism is provided by applying the DAV:expand-property report (see Section 3.8) to a version history resource (see Section 5).
To allow a client to query the properties of all versions in the version history of a specified version-controlled resource, basic versioning provides the DAV:version-tree report (see Section 3.7). A more powerful version history reporting mechanism is provided by applying the DAV:expand-property report (see Section 3.8) to a version history resource (see Section 5).
3 Version-Control Feature
3 Version-Control Feature
The version-control feature provides support for putting a resource under version control, creating an associated version-controlled resource and version history resource as described in Section 2.2.1. A server indicates that it supports the version-control feature by including the string "version-control" as a field in the DAV header in the response to an OPTIONS request. The version-control feature MUST be supported if any other versioning feature is supported.
The version-control feature provides support for putting a resource under version control, creating an associated version-controlled resource and version history resource as described in Section 2.2.1. A server indicates that it supports the version-control feature by including the string "version-control" as a field in the DAV header in the response to an OPTIONS request. The version-control feature MUST be supported if any other versioning feature is supported.
3.1 Additional Resource Properties
3.1 Additional Resource Properties
The version-control feature introduces the following REQUIRED properties for any WebDAV resource.
The version-control feature introduces the following REQUIRED properties for any WebDAV resource.
3.1.1 DAV:comment
3.1.1 DAV:comment
This property is used to track a brief comment about a resource that is suitable for presentation to a user. The DAV:comment of a version can be used to indicate why that version was created.
This property is used to track a brief comment about a resource that is suitable for presentation to a user. The DAV:comment of a version can be used to indicate why that version was created.
<!ELEMENT comment (#PCDATA)> PCDATA value: string
<!ELEMENT comment (#PCDATA)> PCDATA value: string
3.1.2 DAV:creator-displayname
3.1.2 DAV:creator-displayname
This property contains a description of the creator of the resource that is suitable for presentation to a user. The DAV:creator- displayname of a version can be used to indicate who created that version.
This property contains a description of the creator of the resource that is suitable for presentation to a user. The DAV:creator- displayname of a version can be used to indicate who created that version.
<!ELEMENT creator-displayname (#PCDATA)> PCDATA value: string
<!ELEMENT creator-displayname (#PCDATA)> PCDATA value: string
3.1.3 DAV:supported-method-set (protected)
3.1.3 DAV:supported-method-set (protected)
This property identifies the methods that are supported by the resource. A method is supported by a resource if there is some state of that resource for which an application of that method will
This property identifies the methods that are supported by the resource. A method is supported by a resource if there is some state of that resource for which an application of that method will
Clemm, et al. Standards Track [Page 20] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 20] RFC 3253 Versioning Extensions to WebDAV March 2002
successfully satisfy all postconditions of that method, including any additional postconditions added by the features supported by that resource.
successfully satisfy all postconditions of that method, including any additional postconditions added by the features supported by that resource.
<!ELEMENT supported-method-set (supported-method*)> <!ELEMENT supported-method ANY> <!ATTLIST supported-method name NMTOKEN #REQUIRED> name value: a method name
<!ELEMENT supported-method-set (supported-method*)> <!ELEMENT supported-method ANY> <!ATTLIST supported-method name NMTOKEN #REQUIRED> name value: a method name
3.1.4 DAV:supported-live-property-set (protected)
3.1.4 DAV:supported-live-property-set (protected)
This property identifies the live properties that are supported by the resource. A live property is supported by a resource if that property has the semantics defined for that property. The value of this property MUST identify all live properties defined by this document that are supported by the resource, and SHOULD identify all live properties that are supported by the resource.
This property identifies the live properties that are supported by the resource. A live property is supported by a resource if that property has the semantics defined for that property. The value of this property MUST identify all live properties defined by this document that are supported by the resource, and SHOULD identify all live properties that are supported by the resource.
<!ELEMENT supported-live-property-set (supported-live-property*)> <!ELEMENT supported-live-property name> <!ELEMENT prop ANY> ANY value: a property element type
<!ELEMENT supported-live-property-set (supported-live-property*)> <!ELEMENT supported-live-property name> <!ELEMENT prop ANY> ANY value: a property element type
3.1.5 DAV:supported-report-set (protected)
3.1.5 DAV:supported-report-set (protected)
This property identifies the reports that are supported by the resource.
This property identifies the reports that are supported by the resource.
<!ELEMENT supported-report-set (supported-report*)> <!ELEMENT supported-report report> <!ELEMENT report ANY> ANY value: a report element type
<!ELEMENT supported-report-set (supported-report*)> <!ELEMENT supported-report report> <!ELEMENT report ANY> ANY value: a report element type
3.2 Version-Controlled Resource Properties
3.2 Version-Controlled Resource Properties
The version-control feature introduces the following REQUIRED properties for a version-controlled resource.
The version-control feature introduces the following REQUIRED properties for a version-controlled resource.
3.2.1 DAV:checked-in (protected)
3.2.1 DAV:checked-in (protected)
This property appears on a checked-in version-controlled resource, and identifies a version that has the same content and dead properties as the version-controlled resource. This property is removed when the resource is checked out, and then added back (identifying a new version) when the resource is checked back in.
This property appears on a checked-in version-controlled resource, and identifies a version that has the same content and dead properties as the version-controlled resource. This property is removed when the resource is checked out, and then added back (identifying a new version) when the resource is checked back in.
<!ELEMENT checked-in (href)>
<!ELEMENT checked-in (href)>
Clemm, et al. Standards Track [Page 21] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 21] RFC 3253 Versioning Extensions to WebDAV March 2002
3.2.2 DAV:auto-version
3.2.2 DAV:auto-version
If the DAV:auto-version value is DAV:checkout-checkin, when a modification request (such as PUT/PROPPATCH) is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout and followed by a checkin operation.
If the DAV:auto-version value is DAV:checkout-checkin, when a modification request (such as PUT/PROPPATCH) is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout and followed by a checkin operation.
If the DAV:auto-version value is DAV:checkout-unlocked-checkin, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation. If the resource is not write-locked, the request is automatically followed by a checkin operation.
If the DAV:auto-version value is DAV:checkout-unlocked-checkin, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation. If the resource is not write-locked, the request is automatically followed by a checkin operation.
If the DAV:auto-version value is DAV:checkout, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation.
If the DAV:auto-version value is DAV:checkout, when a modification request is applied to a checked-in version-controlled resource, the request is automatically preceded by a checkout operation.
If the DAV:auto-version value is DAV:locked-checkout, when a modification request is applied to a write-locked checked-in version-controlled resource, the request is automatically preceded by a checkout operation.
If the DAV:auto-version value is DAV:locked-checkout, when a modification request is applied to a write-locked checked-in version-controlled resource, the request is automatically preceded by a checkout operation.
If an update to a write-locked checked-in resource is automatically preceded by a checkout of that resource, the checkout is associated with the write lock. When this write lock is removed (e.g. from an UNLOCK or a lock timeout), if the resource has not yet been checked in, the removal of the write lock is automatically preceded by a checkin operation.
If an update to a write-locked checked-in resource is automatically preceded by a checkout of that resource, the checkout is associated with the write lock. When this write lock is removed (e.g. from an UNLOCK or a lock timeout), if the resource has not yet been checked in, the removal of the write lock is automatically preceded by a checkin operation.
A server MAY refuse to allow the value of the DAV:auto-version property to be modified, or MAY only support values from a subset of the valid values.
A server MAY refuse to allow the value of the DAV:auto-version property to be modified, or MAY only support values from a subset of the valid values.
<!ELEMENT auto-version (checkout-checkin | checkout-unlocked-checkin
| checkout | locked-checkout)? >
<!ELEMENT checkout-checkin EMPTY>
<!ELEMENT checkout-unlocked-checkin EMPTY>
<!ELEMENT checkout EMPTY>
<!ELEMENT locked-checkout EMPTY>
<!ELEMENT auto-version (checkout-checkin | checkout-unlocked-checkin | checkout | locked-checkout)? > <!ELEMENT checkout-checkin EMPTY> <!ELEMENT checkout-unlocked-checkin EMPTY> <!ELEMENT checkout EMPTY> <!ELEMENT locked-checkout EMPTY>
3.3 Checked-Out Resource Properties
3.3 Checked-Out Resource Properties
The version-control feature introduces the following REQUIRED properties for a checked-out resource.
The version-control feature introduces the following REQUIRED properties for a checked-out resource.
Clemm, et al. Standards Track [Page 22] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 22] RFC 3253 Versioning Extensions to WebDAV March 2002
3.3.1 DAV:checked-out (protected)
3.3.1 DAV:checked-out (protected)
This property identifies the version that was identified by the DAV:checked-in property at the time the resource was checked out. This property is removed when the resource is checked in.
This property identifies the version that was identified by the DAV:checked-in property at the time the resource was checked out. This property is removed when the resource is checked in.
<!ELEMENT checked-out (href)>
<!ELEMENT checked-out (href)>
3.3.2 DAV:predecessor-set
3.3.2 DAV:predecessor-set
This property determines the DAV:predecessor-set property of the version that results from checking in this resource.
This property determines the DAV:predecessor-set property of the version that results from checking in this resource.
A server MAY reject attempts to modify the DAV:predecessor-set of a version-controlled resource.
A server MAY reject attempts to modify the DAV:predecessor-set of a version-controlled resource.
<!ELEMENT predecessor-set (href+)>
<!ELEMENT predecessor-set (href+)>
3.4 Version Properties
3.4 Version Properties
The version-control feature introduces the following REQUIRED properties for a version.
The version-control feature introduces the following REQUIRED properties for a version.
3.4.1 DAV:predecessor-set (protected)
3.4.1 DAV:predecessor-set (protected)
This property identifies each predecessor of this version. Except for the root version, which has no predecessors, each version has at least one predecessor.
This property identifies each predecessor of this version. Except for the root version, which has no predecessors, each version has at least one predecessor.
<!ELEMENT predecessor-set (href*)>
<!ELEMENT predecessor-set (href*)>
3.4.2 DAV:successor-set (computed)
3.4.2 DAV:successor-set (computed)
This property identifies each version whose DAV:predecessor-set identifies this version.
This property identifies each version whose DAV:predecessor-set identifies this version.
<!ELEMENT successor-set (href*)>
<!ELEMENT successor-set (href*)>
3.4.3 DAV:checkout-set (computed)
3.4.3 DAV:checkout-set (computed)
This property identifies each checked-out resource whose DAV:checked-out property identifies this version.
This property identifies each checked-out resource whose DAV:checked-out property identifies this version.
<!ELEMENT checkout-set (href*)>
<!ELEMENT checkout-set (href*)>
Clemm, et al. Standards Track [Page 23] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 23] RFC 3253 Versioning Extensions to WebDAV March 2002
3.4.4 DAV:version-name (protected)
3.4.4 DAV:version-name (protected)
This property contains a server-defined string that is different for each version in a given version history. This string is intended for display for a user, unlike the URL of a version, which is normally only used by a client and not displayed for a user.
This property contains a server-defined string that is different for each version in a given version history. This string is intended for display for a user, unlike the URL of a version, which is normally only used by a client and not displayed for a user.
<!ELEMENT version-name (#PCDATA)> PCDATA value: string
<!ELEMENT version-name (#PCDATA)> PCDATA value: string
3.5 VERSION-CONTROL Method
3.5 VERSION-CONTROL Method
A VERSION-CONTROL request can be used to create a version-controlled resource at the request-URL. It can be applied to a versionable resource or to a version-controlled resource.
A VERSION-CONTROL request can be used to create a version-controlled resource at the request-URL. It can be applied to a versionable resource or to a version-controlled resource.
If the request-URL identifies a versionable resource, a new version history resource is created, a new version is created whose content and dead properties are copied from the versionable resource, and the resource is given a DAV:checked-in property that is initialized to identify this new version.
If the request-URL identifies a versionable resource, a new version history resource is created, a new version is created whose content and dead properties are copied from the versionable resource, and the resource is given a DAV:checked-in property that is initialized to identify this new version.
If the request-URL identifies a version-controlled resource, the resource just remains under version-control. This allows a client to be unaware of whether or not a server automatically puts a resource under version control when it is created.
If the request-URL identifies a version-controlled resource, the resource just remains under version-control. This allows a client to be unaware of whether or not a server automatically puts a resource under version control when it is created.
If a VERSION-CONTROL request fails, the server state preceding the request MUST be restored.
If a VERSION-CONTROL request fails, the server state preceding the request MUST be restored.
Marshalling:
Marshalling:
If a request body is included, it MUST be a DAV:version-control
XML element.
If a request body is included, it MUST be a DAV:version-control XML element.
<!ELEMENT version-control ANY>
<!ELEMENT version-control ANY>
If a response body for a successful request is included, it MUST
be a DAV:version-control-response XML element. Note that this
document does not define any elements for the VERSION-CONTROL
response body, but the DAV:version-control-response element is
defined to ensure interoperability between future extensions that
do define elements for the VERSION-CONTROL response body.
If a response body for a successful request is included, it MUST be a DAV:version-control-response XML element. Note that this document does not define any elements for the VERSION-CONTROL response body, but the DAV:version-control-response element is defined to ensure interoperability between future extensions that do define elements for the VERSION-CONTROL response body.
<!ELEMENT version-control-response ANY>
<!ELEMENT version-control-response ANY>
Clemm, et al. Standards Track [Page 24] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 24] RFC 3253 Versioning Extensions to WebDAV March 2002
Postconditions:
Postconditions:
(DAV:put-under-version-control): If the request-URL identified a
versionable resource at the time of the request, the request MUST
have created a new version history and MUST have created a new
version resource in that version history. The resource MUST have
a DAV:checked-in property that identifies the new version. The
content, dead properties, and DAV:resourcetype of the new version
MUST be the same as those of the resource. Note that an
implementation can choose to locate the version history and
version resources anywhere that it wishes. In particular, it
could locate them on the same host and server as the version-
controlled resource, on a different virtual host maintained by the
same server, on the same host maintained by a different server, or
on a different host maintained by a different server.
(DAV:put-under-version-control): If the request-URL identified a versionable resource at the time of the request, the request MUST have created a new version history and MUST have created a new version resource in that version history. The resource MUST have a DAV:checked-in property that identifies the new version. The content, dead properties, and DAV:resourcetype of the new version MUST be the same as those of the resource. Note that an implementation can choose to locate the version history and version resources anywhere that it wishes. In particular, it could locate them on the same host and server as the version- controlled resource, on a different virtual host maintained by the same server, on the same host maintained by a different server, or on a different host maintained by a different server.
(DAV:must-not-change-existing-checked-in-out): If the request-URL
identified a resource already under version control at the time of
the request, the request MUST NOT change the DAV:checked-in or
DAV:checked-out property of that version-controlled resource.
(DAV:must-not-change-existing-checked-in-out): If the request-URL identified a resource already under version control at the time of the request, the request MUST NOT change the DAV:checked-in or DAV:checked-out property of that version-controlled resource.
3.5.1 Example - VERSION-CONTROL
3.5.1 Example - VERSION-CONTROL
>>REQUEST
>>REQUEST
VERSION-CONTROL /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
VERSION-CONTROL /foo.html HTTP/1.1 Host: www.webdav.org Content-Length: 0
>>RESPONSE
>>RESPONSE
HTTP/1.1 200 OK
HTTP/1.1 200 OK
In this example, /foo.html is put under version control. A new version history is created for it, and a new version is created that has a copy of the content and dead properties of /foo.html. The DAV:checked-in property of /foo.html identifies this new version.
In this example, /foo.html is put under version control. A new version history is created for it, and a new version is created that has a copy of the content and dead properties of /foo.html. The DAV:checked-in property of /foo.html identifies this new version.
3.6 REPORT Method
3.6 REPORT Method
A REPORT request is an extensible mechanism for obtaining information about a resource. Unlike a resource property, which has a single value, the value of a report can depend on additional information specified in the REPORT request body and in the REPORT request headers.
A REPORT request is an extensible mechanism for obtaining information about a resource. Unlike a resource property, which has a single value, the value of a report can depend on additional information specified in the REPORT request body and in the REPORT request headers.
Clemm, et al. Standards Track [Page 25] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 25] RFC 3253 Versioning Extensions to WebDAV March 2002
Marshalling:
Marshalling:
The body of a REPORT request specifies which report is being
requested, as well as any additional information that will be used
to customize the report.
The body of a REPORT request specifies which report is being requested, as well as any additional information that will be used to customize the report.
The request MAY include a Depth header. If no Depth header is
included, Depth:0 is assumed.
The request MAY include a Depth header. If no Depth header is included, Depth:0 is assumed.
The response body for a successful request MUST contain the
requested report.
The response body for a successful request MUST contain the requested report.
If a Depth request header is included, the response MUST be a 207
Multi-Status. The request MUST be applied separately to the
collection itself and to all members of the collection that
satisfy the Depth value. The DAV:prop element of a DAV:response
for a given resource MUST contain the requested report for that
resource.
If a Depth request header is included, the response MUST be a 207 Multi-Status. The request MUST be applied separately to the collection itself and to all members of the collection that satisfy the Depth value. The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource.
Preconditions:
Preconditions:
(DAV:supported-report): The specified report MUST be supported by
the resource identified by the request-URL.
(DAV:supported-report): The specified report MUST be supported by the resource identified by the request-URL.
Postconditions:
Postconditions:
(DAV:no-modification): The REPORT method MUST NOT have changed the
content or dead properties of any resource.
(DAV:no-modification): The REPORT method MUST NOT have changed the content or dead properties of any resource.
3.7 DAV:version-tree Report
3.7 DAV:version-tree Report
The DAV:version-tree report describes the requested properties of all the versions in the version history of a version. If the report is requested for a version-controlled resource, it is redirected to its DAV:checked-in or DAV:checked-out version.
The DAV:version-tree report describes the requested properties of all the versions in the version history of a version. If the report is requested for a version-controlled resource, it is redirected to its DAV:checked-in or DAV:checked-out version.
The DAV:version-tree report MUST be supported by all version resources and all version-controlled resources.
The DAV:version-tree report MUST be supported by all version resources and all version-controlled resources.
Marshalling:
Marshalling:
The request body MUST be a DAV:version-tree XML element.
The request body MUST be a DAV:version-tree XML element.
<!ELEMENT version-tree ANY>
ANY value: a sequence of zero or more elements, with at most one
DAV:prop element.
prop: see RFC 2518, Section 12.11
<!ELEMENT version-tree ANY> ANY value: a sequence of zero or more elements, with at most one DAV:prop element. prop: see RFC 2518, Section 12.11
Clemm, et al. Standards Track [Page 26] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 26] RFC 3253 Versioning Extensions to WebDAV March 2002
The response body for a successful request MUST be a
DAV:multistatus XML element.
The response body for a successful request MUST be a DAV:multistatus XML element.
multistatus: see RFC 2518, Section 12.9
multistatus: see RFC 2518, Section 12.9
The response body for a successful DAV:version-tree REPORT request
MUST contain a DAV:response element for each version in the
version history of the version identified by the request-URL.
The response body for a successful DAV:version-tree REPORT request MUST contain a DAV:response element for each version in the version history of the version identified by the request-URL.
3.7.1 Example - DAV:version-tree Report
3.7.1 Example - DAV:version-tree Report
The version history drawn below would produce the following version tree report.
The version history drawn below would produce the following version tree report.
foo.html History
foo.html History
+---+
| | V1
+---+
/ \
/ \
+---+ +---+
| | V2 | | V2.1.1
+---+ +---+
+---+ | | V1 +---+ / \ / \ +---+ +---+ | | V2 | | V2.1.1 +---+ +---+
>>REQUEST
>>REQUEST
REPORT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
REPORT /foo.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:version-tree xmlns:D="DAV:">
<D:prop>
<D:version-name/>
<D:creator-displayname/>
<D:successor-set/>
</D:prop>
</D:version-tree>
<?xml version="1.0" encoding="utf-8" ?> <D:version-tree xmlns:D="DAV:"> <D:prop> <D:version-name/> <D:creator-displayname/> <D:successor-set/> </D:prop> </D:version-tree>
Clemm, et al. Standards Track [Page 27] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 27] RFC 3253 Versioning Extensions to WebDAV March 2002
>>RESPONSE
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/V1</D:href>
<D:propstat>
<D:prop>
<D:version-name>V1</D:version-name>
<D:creator-displayname>Fred</D:creator-displayname>
<D:successor-set>
<D:href>http://repo.webdav.org/his/23/ver/V2</D:href>
<D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href>
</D:successor-set>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/V2</D:href>
<D:propstat>
<D:prop>
<D:version-name>V2</D:version-name>
<D:creator-displayname>Fred</D:creator-displayname>
<D:successor-set/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href>
<D:propstat>
<D:prop>
<D:version-name>V2.1.1</D:version-name>
<D:creator-displayname>Sally</D:creator-displayname>
<D:successor-set/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://repo.webdav.org/his/23/ver/V1</D:href> <D:propstat> <D:prop> <D:version-name>V1</D:version-name> <D:creator-displayname>Fred</D:creator-displayname> <D:successor-set> <D:href>http://repo.webdav.org/his/23/ver/V2</D:href> <D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href> </D:successor-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://repo.webdav.org/his/23/ver/V2</D:href> <D:propstat> <D:prop> <D:version-name>V2</D:version-name> <D:creator-displayname>Fred</D:creator-displayname> <D:successor-set/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://repo.webdav.org/his/23/ver/V2.1.1</D:href> <D:propstat> <D:prop> <D:version-name>V2.1.1</D:version-name> <D:creator-displayname>Sally</D:creator-displayname> <D:successor-set/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
Clemm, et al. Standards Track [Page 28] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 28] RFC 3253 Versioning Extensions to WebDAV March 2002
3.8 DAV:expand-property Report
3.8 DAV:expand-property Report
Many property values are defined as a DAV:href, or a set of DAV:href elements. The DAV:expand-property report provides a mechanism for retrieving in one request the properties from the resources identified by those DAV:href elements. This report not only decreases the number of requests required, but also allows the server to minimize the number of separate read transactions required on the underlying versioning store.
Many property values are defined as a DAV:href, or a set of DAV:href elements. The DAV:expand-property report provides a mechanism for retrieving in one request the properties from the resources identified by those DAV:href elements. This report not only decreases the number of requests required, but also allows the server to minimize the number of separate read transactions required on the underlying versioning store.
The DAV:expand-property report SHOULD be supported by all resources that support the REPORT method.
The DAV:expand-property report SHOULD be supported by all resources that support the REPORT method.
Marshalling:
Marshalling:
The request body MUST be a DAV:expand-property XML element.
The request body MUST be a DAV:expand-property XML element.
<!ELEMENT expand-property (property*)>
<!ELEMENT property (property*)>
<!ATTLIST property name NMTOKEN #REQUIRED>
name value: a property element type
<!ATTLIST property namespace NMTOKEN "DAV:">
namespace value: an XML namespace
<!ELEMENT expand-property (property*)> <!ELEMENT property (property*)> <!ATTLIST property name NMTOKEN #REQUIRED> name value: a property element type <!ATTLIST property namespace NMTOKEN "DAV:"> namespace value: an XML namespace
The response body for a successful request MUST be a
DAV:multistatus XML element.
The response body for a successful request MUST be a DAV:multistatus XML element.
multistatus: see RFC 2518, Section 12.9
multistatus: see RFC 2518, Section 12.9
The properties reported in the DAV:prop elements of the
DAV:multistatus element MUST be those identified by the
DAV:property elements in the DAV:expand-property element. If
there are DAV:property elements nested within a DAV:property
element, then every DAV:href in the value of the corresponding
property is replaced by a DAV:response element whose DAV:prop
elements report the values of the properties identified by the
nested DAV:property elements. The nested DAV:property elements
can in turn contain DAV:property elements, so that multiple levels
of DAV:href expansion can be requested.
The properties reported in the DAV:prop elements of the DAV:multistatus element MUST be those identified by the DAV:property elements in the DAV:expand-property element. If there are DAV:property elements nested within a DAV:property element, then every DAV:href in the value of the corresponding property is replaced by a DAV:response element whose DAV:prop elements report the values of the properties identified by the nested DAV:property elements. The nested DAV:property elements can in turn contain DAV:property elements, so that multiple levels of DAV:href expansion can be requested.
Note that a validating parser MUST be aware that the DAV:expand-
property report effectively modifies the DTD of every property by
replacing every occurrence of "href" in the DTD with "href |
response".
Note that a validating parser MUST be aware that the DAV:expand- property report effectively modifies the DTD of every property by replacing every occurrence of "href" in the DTD with "href | response".
Clemm, et al. Standards Track [Page 29] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 29] RFC 3253 Versioning Extensions to WebDAV March 2002
3.8.1 Example - DAV:expand-property
3.8.1 Example - DAV:expand-property
This example describes how to query a version-controlled resource to determine the DAV:creator-display-name and DAV:activity-set of every version in the version history of that version-controlled resource. This example assumes that the server supports the version-history feature (see Section 5).
This example describes how to query a version-controlled resource to determine the DAV:creator-display-name and DAV:activity-set of every version in the version history of that version-controlled resource. This example assumes that the server supports the version-history feature (see Section 5).
>>REQUEST
>>REQUEST
REPORT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
REPORT /foo.html HTTP/1.1 Host: www.webdav.org Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:expand-property xmlns:D="DAV:">
<D:property name="version-history">
<D:property name="version-set">
<D:property name="creator-displayname"/>
<D:property name="activity-set"/>
</D:property>
</D:property>
</D:expand-property>
<?xml version="1.0" encoding="utf-8" ?> <D:expand-property xmlns:D="DAV:"> <D:property name="version-history"> <D:property name="version-set"> <D:property name="creator-displayname"/> <D:property name="activity-set"/> </D:property> </D:property> </D:expand-property>
>>RESPONSE
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/foo.html</D:href>
<D:propstat>
<D:prop>
<D:version-history>
<D:response>
<D:href>http://repo.webdav.org/his/23</D:href>
<D:propstat>
<D:prop>
<D:version-set>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/1</D:href>
<D:propstat>
<D:prop>
<D:creator-displayname>Fred</D:creator-displayname>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/foo.html</D:href> <D:propstat> <D:prop> <D:version-history> <D:response> <D:href>http://repo.webdav.org/his/23</D:href> <D:propstat> <D:prop> <D:version-set> <D:response> <D:href>http://repo.webdav.org/his/23/ver/1</D:href> <D:propstat> <D:prop> <D:creator-displayname>Fred</D:creator-displayname>
Clemm, et al. Standards Track [Page 30] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 30] RFC 3253 Versioning Extensions to WebDAV March 2002
<D:activity-set> <D:href>
http://www.webdav.org/ws/dev/sally
</D:href> </D:activity-set> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
<D:response>
<D:href>http://repo.webdav.org/his/23/ver/2</D:href>
<D:propstat>
<D:prop>
<D:creator-displayname>Sally</D:creator-displayname>
<D:activity-set>
<D:href>http://repo.webdav.org/act/add-refresh-cmd</D:href>
</D:activity-set> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
</D:version-set> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
</D:version-history> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:response>
</D:multistatus>
<D:activity-set> <D:href> http://www.webdav.org/ws/dev/sally </D:href> </D:activity-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://repo.webdav.org/his/23/ver/2</D:href> <D:propstat> <D:prop> <D:creator-displayname>Sally</D:creator-displayname> <D:activity-set> <D:href>http://repo.webdav.org/act/add-refresh-cmd</D:href> </D:activity-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:version-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:version-history> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
In this example, the DAV:creator-displayname and DAV:activity-set properties of the versions in the DAV:version-set of the DAV:version-history of http://www.webdav.org/foo.html are reported.
In this example, the DAV:creator-displayname and DAV:activity-set properties of the versions in the DAV:version-set of the DAV:version-history of http://www.webdav.org/foo.html are reported.
3.9 Additional OPTIONS Semantics
3.9 Additional OPTIONS Semantics
If the server supports the version-control feature, it MUST include "version-control" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
If the server supports the version-control feature, it MUST include "version-control" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
3.10 Additional PUT Semantics
3.10 追加かかっている意味論
Additional Preconditions:
追加前提条件:
(DAV:cannot-modify-version-controlled-content): If the request-URL
identifies a resource with a DAV:checked-in property, the request
MUST fail unless DAV:auto-version semantics will automatically
check out the resource.
(DAV:、バージョンの制御内容を変更できない、)、: 要求URLがDAV: 預けている特性とリソースを同一視して、DAV: 自動バージョン意味論が自動的にリソースを調べないなら、要求は失敗しなければなりません。
(DAV:cannot-modify-version): If the request-URL identifies a
version, the request MUST fail.
(DAV:、バージョンを変更できない、)、: 要求URLがバージョンを特定するなら、要求は失敗しなければなりません。
Clemm, et al. Standards Track [Page 31] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[31ページ]。
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
要求がバージョンコントロールの下で自動的に置かれる新しいリソースを作成するなら、バージョン-CONTROLのためのすべての前提条件が要求に適用されます。
Additional Postconditions:
追加Postconditions:
(DAV:auto-checkout): If the resource was a checked-in version-
controlled resource whose DAV:auto-version property indicates it
should be automatically checked out but not automatically checked
in for a modification request, then the server MUST have
automatically checked out the resource prior to executing the
request. In particular, the value of the DAV:checked-out property
of the resource MUST be that of the DAV:checked-in property prior
to the request, the DAV:checked-in property MUST have been
removed, and the DAV:predecessor-set property MUST be initialized
to be the same as the DAV:checked-out property. If any part of
the checkout/update sequence failed, the status from the failed
part of the request MUST be returned, and the server state
preceding the request sequence MUST be restored.
(DAV: 自動チェックアウト): リソースが預けているバージョン制御リソースであったなら、DAV: 自動バージョンの特性は、それが自動的に調べられますが、変更要求のために自動的に預けられるべきでないのを示して、要求を実行する前に、次に、サーバは自動的にリソースを調べたに違いありません。 DAVの値: リソースの調べている特性は特に、DAVのものであるに違いありません: 要求の前に特性を預けます、DAV: DAVと同じになるようにDAV: 前任者セット所有地を初期化しなければなりません: 預けている資産は取り外されたに違いありません、そして、調べている特性。 何かチェックアウト/アップデート系列の部分が失敗したなら、要求の機能しなくなった部分からの状態を返さなければなりません、そして、要求系列に先行するサーバ州を回復しなければなりません。
(DAV:auto-checkout-checkin): If the resource was a checked-in
version-controlled resource whose DAV:auto-version property
indicates it should be automatically checked out and automatically
checked in for a modification request, then the server MUST have
automatically checked out the resource prior to executing the
request and automatically checked it in after the request. In
particular, the DAV:checked-in property of the resource MUST
identify a new version whose content and dead properties are the
same as those of the resource. The DAV:predecessor-set of the new
version MUST identify the version identified by the DAV:checked-in
property prior to the request. If any part of the
checkout/update/checkin sequence failed, the status from the
failed part of the request MUST be returned, and the server state
preceding the request sequence MUST be restored.
(DAV: 自動チェックアウトしているチェックイン): DAV: 自動バージョンの特性が、リソースが預けているバージョンで制御されたリソースであったならそれが自動的に調べられて、変更要求のために自動的に預けられるべきであるのを示して、次に、サーバは、要求を実行する前に、自動的にリソースを調べて、自動的に要求の後にそれを預けたに違いありません。 特に、DAV: リソースの預けている特性は満足していて死んでいる特性がリソースのものと同じである新しいバージョンを特定しなければなりません。 DAV: 新しいバージョンの前任者セットはDAVによって特定されたバージョンを特定しなければなりません: 要求の前に特性を預けます。 何かチェックアウト/アップデート/チェックイン系列の部分が失敗したなら、要求の機能しなくなった部分からの状態を返さなければなりません、そして、要求系列に先行するサーバ州を回復しなければなりません。
If the request creates a new resource, the new resource MAY have
automatically been placed under version control, and all
postconditions for VERSION-CONTROL apply to the request.
要求が新しいリソースを作成するなら、新しいリソースはバージョンコントロールの下で自動的に置かれたかもしれません、そして、バージョン-CONTROLのためのすべてのpostconditionsが要求に適用されます。
3.11 Additional PROPFIND Semantics
3.11 追加PROPFIND意味論
A DAV:allprop PROPFIND request SHOULD NOT return any of the properties defined by this document. This allows a versioning server to perform efficiently when a naive client, which does not understand the cost of asking a server to compute all possible live properties, issues a DAV:allprop PROPFIND request.
DAV: allprop PROPFINDは、SHOULD NOTがこのドキュメントによって定義された特性のどれかを返すよう要求します。 ナイーブなクライアント(すべての可能な精力の特性を計算するようにサーバに頼む費用を理解していない)がDAVを発行するとき、これで、versioningサーバは効率的に働きます: allprop PROPFIND要求。
Clemm, et al. Standards Track [Page 32] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[32ページ]。
Additional Preconditions:
追加前提条件:
(DAV:supported-live-property): If the request attempts to access a
property defined by this document, the semantics of that property
MUST be supported by the server.
(DAV: サポートしている精力の特性): 要求が、このドキュメントによって定義された特性にアクセスするのを試みるなら、サーバでその特性の意味論をサポートしなければなりません。
3.12 Additional PROPPATCH Semantics
3.12 追加PROPPATCH意味論
Additional Preconditions:
追加前提条件:
(DAV:cannot-modify-version-controlled-property): If the request
attempts to modify a dead property, same semantics as PUT (see
Section 3.10).
(DAV:、バージョンの制御特性を変更できない、)、: 要求が、死んでいる特性を変更するのを試みるなら、PUT(セクション3.10を見る)と同じ意味論です。
(DAV:cannot-modify-version): If the request attempts to modify a
dead property, same semantics as PUT (see Section 3.10).
(DAV:、バージョンを変更できない、)、: 要求が、死んでいる特性を変更するのを試みるなら、PUT(セクション3.10を見る)と同じ意味論です。
(DAV:cannot-modify-protected-property): An attempt to modify a
property that is defined by this document, as being protected for
that kind of resource, MUST fail.
(DAV:、保護された特性を変更できない、)、: その種類に関するリソースのために保護されるとして、このドキュメントによって定義される特性を変更する試みは失敗しなければなりません。
(DAV:supported-live-property): An attempt to modify a property
defined by this document, but whose semantics are not enforced by
the server, MUST fail. This helps ensure that a client will be
notified when it is trying to use a property whose semantics are
not supported by the server.
(DAV: サポートしている精力の特性): このドキュメントによって定義された特性を変更する試み(意味論だけがサーバによって励行されない)は失敗しなければなりません。 これは、意味論がサーバによってサポートされない特性を使用しようとしているとき、クライアントが通知されるのを確実にするのを助けます。
Additional Postconditions:
追加Postconditions:
(DAV:auto-checkout): If the request modified a dead property, same
semantics as PUT (see Section 3.10).
(DAV: 自動チェックアウト): 要求が死んでいる特性を変更したなら、PUT(セクション3.10を見る)と同じ意味論です。
(DAV:auto-checkout-checkin): If the request modified a dead
property, same semantics as PUT (see Section 3.10).
(DAV: 自動チェックアウトしているチェックイン): 要求が死んでいる特性を変更したなら、PUT(セクション3.10を見る)と同じ意味論です。
3.13 Additional DELETE Semantics
3.13、追加、意味論を削除してください。
Additional Preconditions:
追加前提条件:
(DAV:no-version-delete): A server MAY fail an attempt to DELETE a
version.
(DAV: いいえバージョンが削除する): サーバはDELETE aバージョンに試みに失敗するかもしれません。
Additional Postconditions:
追加Postconditions:
(DAV:update-predecessor-set): If a version was deleted, the server
MUST have replaced any reference to that version in a
DAV:predecessor-set by a copy of the DAV:predecessor-set of the
deleted version.
(DAV: アップデート前任者セット): バージョンが削除されたなら、サーバはDAV: 前任者セットでそのバージョンのどんな参照もDAVのコピーに置き換えたに違いありません: 削除されたバージョンの前任者セット。
Clemm, et al. Standards Track [Page 33] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[33ページ]。
3.14 Additional COPY Semantics
3.14 複本意味論
Additional Preconditions:
追加前提条件:
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
要求がバージョンコントロールの下で自動的に置かれる新しいリソースを作成するなら、バージョン-CONTROLのためのすべての前提条件が要求に適用されます。
Additional Postconditions:
追加Postconditions:
(DAV:must-not-copy-versioning-property): A property defined by
this document MUST NOT have been copied to the new resource
created by this request, but instead that property of the new
resource MUST have the default initial value it would have had if
the new resource had been created by a non-versioning method such
as PUT or a MKCOL.
(特性をversioningしながらコピーするはずがないDAV): この要求で作成された新しいリソースにこのドキュメントによって定義された特性をコピーしていてはいけませんが、PUTかMKCOLなどの非versioningメソッドで新しいリソースを作成してあったなら、代わりに、デフォルトは新しいリソースのその特性でそれが持っていた値に頭文字をつけなければなりません。
(DAV:auto-checkout): If the destination is a version-controlled
resource, same semantics as PUT (see Section 3.10).
(DAV: 自動チェックアウト): 目的地がバージョンで制御されたリソースであるなら、PUT(セクション3.10を見る)と同じ意味論です。
(DAV:auto-checkout-checkin): If the destination is a version-
controlled resource, same semantics as PUT (see Section 3.10).
(DAV: 自動チェックアウトしているチェックイン): 目的地がバージョンの制御リソースであるなら、PUT(セクション3.10を見る)と同じ意味論です。
(DAV:copy-creates-new-resource): If the source of a COPY is a
version-controlled resource or version, and if there is no
resource at the destination of the COPY, then the COPY creates a
new non-version-controlled resource at the destination of the
COPY. The new resource MAY automatically be put under version
control, but the resulting version-controlled resource MUST be
associated with a new version history created for that new
version-controlled resource, and all postconditions for
VERSION-CONTROL apply to the request.
(コピーがリソースを新しく作成しているDAV): COPYの源がバージョンで制御されたリソースかバージョンであり、リソースが全くCOPYの目的地になければ、COPYはCOPYの目的地で新しい非バージョンが制御されたリソースを作成します。 結果として起こるバージョンで制御されたリソースはその新しいバージョンで制御されたリソースのために引き起こされる新しいバージョン歴史に関連しているに違いありません、そして、新しいリソースはバージョンコントロールの下で自動的に置かれるかもしれませんが、バージョン-CONTROLのためのすべてのpostconditionsが要求に適用されます。
3.15 Additional MOVE Semantics
3.15 追加移動意味論
Additional Preconditions:
追加前提条件:
(DAV:cannot-rename-version): If the request-URL identifies a
version, the request MUST fail.
(DAV:、バージョンを改名できない、)、: 要求URLがバージョンを特定するなら、要求は失敗しなければなりません。
Additional Postconditions:
追加Postconditions:
(DAV:preserve-versioning-properties): When a resource is moved
from a source URL to a destination URL, a property defined by this
document MUST have the same value at the destination URL as it had
at the source URL.
(DAV: 特性をversioningする保護区): リソースがソースURLから目的地URLまで動かされるとき、それがソースURLに攻撃したので、このドキュメントによって定義された特性は目的地URLにおける同じ値を持たなければなりません。
Clemm, et al. Standards Track [Page 34] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[34ページ]。
3.16 Additional UNLOCK Semantics
3.16 追加アンロック意味論
Note that these semantics apply both to an explicit UNLOCK request, as well as to the removal of a lock because of a lock timeout. If a precondition or postcondition cannot be satisfied, the lock timeout MUST NOT occur.
これらの意味論が明白なUNLOCK要求に両方を適用することに注意してください、よくロックタイムアウトによる錠の取り外しのように。 前提条件かpostconditionを満たすことができないなら、ロックタイムアウトは起こってはいけません。
Additional Preconditions:
追加前提条件:
(DAV:version-history-is-tree): If the request-URL identifies a
checked-out version-controlled resource that will be automatically
checked in when the lock is removed, 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.
(DAV:、バージョン歴史が木である、)、: 要求URLが錠が取り外されるとき自動的に預けられる調べているバージョンで制御されたリソースを特定するなら、DAVによって特定されたバージョン: 調べているリソースの前任者セットはDAVのためのバージョン歴史の根のバージョンの子孫であるに違いありません: バージョンを調べます。
Additional Postconditions:
追加Postconditions:
(DAV:auto-checkin): If the request-URL identified a checked-out
version-controlled resource that had been automatically checked
out because of its DAV:auto-version property, the request MUST
have created a new version in the version history of the
DAV:checked-out version. The request MUST have allocated a URL
for the version that MUST NOT have previously identified any other
resource, and MUST NOT ever identify a resource other than this
version. The content, dead properties, DAV:resourcetype, and
DAV:predecessor-set of the new version MUST be copied from the
checked-out resource. The DAV:version-name of the new version
MUST be set to a server-defined value distinct from all other
DAV:version-name values of other versions in the same version
history. The request MUST have removed the DAV:checked-out
property of the version-controlled resource, and MUST have added a
DAV:checked-in property that identifies the new version.
(DAV: 自動チェックイン): 要求URLが調べているバージョンで制御されたリソースを特定したなら、それはDAVのために自動的に調べられました: 自動バージョンの特性、要求はDAVのバージョン歴史の新しいバージョンを作成したに違いありません: 調べているバージョン。 要求は以前にいかなる他のリソースも特定していてはいけなくて、このバージョン以外のリソースは特定してはいけないバージョンのために、URLを割り当てたに違いありません。 内容、死んでいる特性、DAV: resourcetype、およびDAV: 調べているリソースから新しいバージョンの前任者セットをコピーしなければなりません。 DAV: 他のすべてのDAVと異なったサーバで定義された値に新しいバージョンのバージョン名を設定しなければなりません: 同じバージョン歴史の他のバージョンのバージョン名値。 要求は、DAV: バージョンで制御されたリソースの調べている資産を取り外したに違いなくて、DAVを加えたに違いありません: 新しいバージョンを特定する特性を預けます。
4 CHECKOUT-IN-PLACE FEATURE
4適所でのチェックアウト機能
With the version-control feature, WebDAV locking can be used to avoid the proliferation of versions that would result if every modification to a version-controlled resource produced a new version. The checkout-in-place feature provides an alternative mechanism that allows a client to explicitly check out and check in a resource to create a new version.
バージョンコントロール機能と共に、バージョンで制御されたリソースへのあらゆる変更が新しいバージョンを生産するなら結果として生じるバージョンの増殖を避けるのにWebDAVロックを使用できます。 適所でのチェックアウト機能はクライアントが新しいバージョンを作成するために明らかにチェックアウトして、リソースを預ける代替のメカニズムを、提供します。
4.1 Additional Version Properties
4.1 追加バージョンの特性
The checkout-in-place feature introduces the following REQUIRED properties for a version.
適所でのチェックアウト機能はバージョンのために以下のREQUIRED資産を紹介します。
Clemm, et al. Standards Track [Page 35] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[35ページ]。
4.1.1 DAV:checkout-fork
4.1.1 DAV: チェックアウトフォーク
This property controls the behavior of CHECKOUT when a version already is checked out or has a successor. If the DAV:checkout-fork of a version is DAV:forbidden, a CHECKOUT request MUST fail if it would result in that version appearing in the DAV:predecessor-set or DAV:checked-out property of more than one version or checked-out resource. If DAV:checkout-fork is DAV:discouraged, such a CHECKOUT request MUST fail unless DAV:fork-ok is specified in the CHECKOUT request body.
バージョンに、既に調べられるか、または後継者がいるとき、この特性はCHECKOUTの動きを制御します。 DAVであるなら、: バージョンのチェックアウトフォークはDAVです: 禁制であることで、CHECKOUT要求はDAVに現れるそのバージョンをもたらすでしょう: DAV: 1つ以上のバージョンか調べているリソースの前任者セットか調べている特性なら失敗しなければなりません。 DAVであるなら、: チェックアウトフォークはDAVです: 妨げて、CHECKOUTで指定されて、-OKに分岐しているDAVが失敗しない場合CHECKOUT要求が失敗しなければならないそのようなものはボディーを要求します。
A server MAY reject attempts to modify the DAV:checkout-fork of a version.
サーバはDAVを変更する試みを拒絶するかもしれません: バージョンのチェックアウトフォーク。
<!ELEMENT checkout-fork ANY> ANY value: A sequence of elements with at most one DAV:discouraged or DAV:forbidden element. <!ELEMENT discouraged EMPTY> <!ELEMENT forbidden EMPTY>
どんな>も少しも評価する<!ELEMENTチェックアウトフォーク: 高々1DAVがある要素の系列:、妨げ、DAV: または、禁制の要素。 <!ELEMENTはEMPTY>が禁じられたEMPTY><!ELEMENTをがっかりさせました。
4.1.2 DAV:checkin-fork
4.1.2 DAV: チェックインフォーク
This property controls the behavior of CHECKIN when a version already has a successor. If the DAV:checkin-fork of a version is DAV:forbidden, a CHECKIN request MUST fail if it would result in that version appearing in the DAV:predecessor-set of more than one version. If DAV:checkin-fork is DAV:discouraged, such a CHECKIN request MUST fail unless DAV:fork-ok is specified in the CHECKIN request body.
バージョンに後継者が既にいるとき、この特性はCHECKINの動きを制御します。 DAVであるなら、: バージョンのチェックインフォークはDAVです: 禁制であることで、CHECKIN要求はDAVに現れるそのバージョンをもたらすでしょう: 1つ以上のバージョンの前任者セットなら失敗しなければなりません。 DAVであるなら、: チェックインフォークはDAVです: 妨げて、CHECKINで指定されて、-OKに分岐しているDAVが失敗しない場合CHECKIN要求が失敗しなければならないそのようなものはボディーを要求します。
A server MAY reject attempts to modify the DAV:checkout-fork of a version.
サーバはDAVを変更する試みを拒絶するかもしれません: バージョンのチェックアウトフォーク。
<!ELEMENT checkin-fork ANY> ANY value: A sequence of elements with at most one DAV:discouraged or DAV:forbidden element. <!ELEMENT discouraged EMPTY> <!ELEMENT forbidden EMPTY>
どんな>も少しも評価する<!ELEMENTチェックインフォーク: 高々1DAVがある要素の系列:、妨げ、DAV: または、禁制の要素。 <!ELEMENTはEMPTY>が禁じられたEMPTY><!ELEMENTをがっかりさせました。
4.2 Checked-Out Resource Properties
4.2 調べているリソースの特性
The checkout-in-place feature introduces the following REQUIRED properties for a checked-out resource.
適所でのチェックアウト機能は調べているリソースのために以下のREQUIRED資産を紹介します。
4.2.1 DAV:checkout-fork
4.2.1 DAV: チェックアウトフォーク
This property determines the DAV:checkout-fork property of the version that results from checking in this resource.
この特性はDAVを決定します: このリソースを預けるそれが生じるバージョンのチェックアウトフォークの特性。
Clemm, et al. Standards Track [Page 36] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[36ページ]。
4.2.2 DAV:checkin-fork
4.2.2 DAV: チェックインフォーク
This property determines the DAV:checkin-fork property of the version that results from checking in this resource.
この特性はDAVを決定します: このリソースを預けるそれが生じるバージョンのチェックインフォークの特性。
4.3 CHECKOUT Method (applied to a version-controlled resource)
4.3 チェックアウトメソッド(バージョンで制御されたリソースに適用されます)
A CHECKOUT request can be applied to a checked-in version-controlled resource to allow modifications to the content and dead properties of that version-controlled resource.
そのバージョンで制御されたリソースの満足していて死んでいる特性への変更を許すために預けているバージョンで制御されたリソースにCHECKOUT要求を適用できます。
If a CHECKOUT request fails, the server state preceding the request MUST be restored.
CHECKOUT要求が失敗するなら、要求に先行するサーバ州を回復しなければなりません。
Marshalling:
整理します:
If a request body is included, it MUST be a DAV:checkout XML
element.
要求本体が含まれているなら、それはDAVであるに違いありません: チェックアウトXML要素。
<!ELEMENT checkout ANY>
<!ELEMENTチェックアウトいずれも>。
ANY value: A sequence of elements with at most one DAV:fork-ok
element.
どんな値も: 高々1DAVがある要素の系列: -OKに要素をまたぐわで掘ってください。
<!ELEMENT fork-ok EMPTY>
<!ELEMENTフォークOK EMPTY>。
If a response body for a successful request is included, it MUST
be a DAV:checkout-response XML element.
うまくいっている要求のための応答本体が含まれているなら、それはDAVであるに違いありません: チェックアウト応答XML要素。
<!ELEMENT checkout-response ANY>
<!ELEMENTチェックアウト応答いずれも>。
The response MUST include a Cache-Control:no-cache header.
応答はCache-コントロールを含まなければなりません: キャッシュがないヘッダー。
Preconditions:
前提条件:
(DAV:must-be-checked-in): If a version-controlled resource is
being checked out, it MUST have a DAV:checked-in property.
(中でチェックしなければならないDAV): バージョンで制御されたリソースが調べられているなら、DAVを持たなければなりません: 特性を預けます。
(DAV:checkout-of-version-with-descendant-is-forbidden): If the
DAV:checkout-fork property of the version being checked out is
DAV:forbidden, the request MUST fail if a version identifies that
version in its DAV:predecessor-set.
(DAV:、子孫とのバージョンのチェックアウトが禁じられる、)、: DAV: バージョンのチェックアウトフォークの特性であるなら、調べられるのは、DAVです: 禁制であることで、バージョンはDAVのそのバージョンを特定します: 前任者によって設定されているなら、要求は失敗しなければなりません。
(DAV:checkout-of-version-with-descendant-is-discouraged): If the
DAV:checkout-fork property of the version being checked out is
DAV:discouraged, the request MUST fail if a version identifies
that version in its DAV:predecessor-set unless DAV:fork-ok is
specified in the request body.
(DAV:、子孫とのバージョンのチェックアウトがお勧めできない、)、: DAV: バージョンのチェックアウトフォークの特性であるなら、調べられるのは、DAVです: がっかりして、バージョンがそのバージョンを特定するなら、要求に失敗しなければなりません。DAVで: 要求本体で指定されて、-OKに分岐しているDAVがセットしない場合、前任者と同じくらいセットしてください。
Clemm, et al. Standards Track [Page 37] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[37ページ]。
(DAV:checkout-of-checked-out-version-is-forbidden): If the
DAV:checkout-fork property of the version being checked out is
DAV:forbidden, the request MUST fail if a checked-out resource
identifies that version in its DAV:checked-out property.
(DAV: バージョンが禁じられるチェックのアウトのチェックアウト): DAV: バージョンのチェックアウトフォークの特性であるなら、調べられるのは、DAVです: 禁制であることで、要求は調べているリソースはDAVのそのバージョンを特定します: 調べている特性なら失敗しなければなりません。
(DAV:checkout-of-checked-out-version-is-discouraged): If the
DAV:checkout-fork property of the version being checked out is
DAV:discouraged, the request MUST fail if a checked-out resource
identifies that version in its DAV:checked-out property unless
DAV:fork-ok is specified in the request body.
(DAV:、チェックの出ているバージョンのチェックアウトがお勧めできない、)、: DAV: バージョンのチェックアウトフォークの特性であるなら、調べられるのは、DAVです: 妨げて、調べているリソースがDAVのそのバージョンを特定するなら、要求は失敗しなければなりません: -OKに分岐しているDAVが調べない場合、特性を調べます。要求本体では、指定されています。
Postconditions:
Postconditions:
(DAV:is-checked-out): The checked-out resource MUST have a
DAV:checked-out property that identifies the DAV:checked-in
version preceding the checkout. The version-controlled resource
MUST NOT have a DAV:checked-in property.
(DAV:、調べられる、)、: 調べているリソースには、DAVがなければなりません: DAV: チェックアウトに先行する預けているバージョンを特定する特性を調べます。 バージョンで制御されたリソースには、DAVがあってはいけません: 特性を預けます。
(DAV:initialize-predecessor-set): The DAV:predecessor-set property
of the checked-out resource MUST be initialized to be the
DAV:checked-out version.
(設定していた状態で前任者を初期化しているDAV): DAV: DAVになるように調べているリソースの前任者セット所有地を初期化しなければなりません: バージョンを調べます。
4.3.1 Example - CHECKOUT of a version-controlled resource
4.3.1 例--バージョンで制御されたリソースのCHECKOUT
>>REQUEST
>>要求
CHECKOUT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
チェックアウト/foo.html HTTP/1.1ホスト: www.webdav.org Content-長さ: 0
>>RESPONSE
>>応答
HTTP/1.1 200 OK
Cache-Control: no-cache
HTTP/1.1 200はキャッシュ制御を承認します: キャッシュがありません。
In this example, the version-controlled resource /foo.html is checked out.
この例では、バージョンで制御されたリソース/foo.htmlは調べられます。
4.4 CHECKIN Method (applied to a version-controlled resource)
4.4 チェックインメソッド(バージョンで制御されたリソースに適用されます)
A CHECKIN request can be applied to a checked-out version-controlled resource to produce a new version whose content and dead properties are copied from the checked-out resource.
満足していて死んでいる特性が調べているリソースからコピーされる新しいバージョンを生産するために調べているバージョンで制御されたリソースにCHECKIN要求を適用できます。
If a CHECKIN request fails, the server state preceding the request MUST be restored.
CHECKIN要求が失敗するなら、要求に先行するサーバ州を回復しなければなりません。
Clemm, et al. Standards Track [Page 38] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[38ページ]。
Marshalling:
整理します:
If a request body is included, it MUST be a DAV:checkin XML
element.
要求本体が含まれているなら、それはDAVであるに違いありません: チェックインXML要素。
<!ELEMENT checkin ANY>
ANY value: A sequence of elements with at most one
DAV:keep-checked-out element and at most one DAV:fork-ok element.
どんな>も少しも評価する<!ELEMENTチェックイン: 高々あるDAVがある要素の系列: 生活費がチェックアウトされた要素と高々あるDAV: -OKに要素をまたぐわで掘ってください。
<!ELEMENT keep-checked-out EMPTY>
<!ELEMENT fork-ok EMPTY>
<!ELEMENT外でチェックされた生活費EMPTY><!ELEMENTフォークOK EMPTY>。
If a response body for a successful request is included, it MUST
be a DAV:checkin-response XML element.
うまくいっている要求のための応答本体が含まれているなら、それはDAVであるに違いありません: チェックイン応答XML要素。
<!ELEMENT checkin-response ANY>
<!ELEMENTチェックイン応答いずれも>。
The response MUST include a Cache-Control:no-cache header.
応答はCache-コントロールを含まなければなりません: キャッシュがないヘッダー。
Preconditions:
前提条件:
(DAV:must-be-checked-out): The request-URL MUST identify a
resource with a DAV:checked-out property.
(外でチェックしなければならないDAV): 要求URLはリソースをDAVと同一視しなければなりません: 特性を調べます。
(DAV:version-history-is-tree) 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.
(DAV:、バージョン歴史が木である、)、DAVによって特定されたバージョン: 調べているリソースの前任者セットはDAVのためのバージョン歴史の根のバージョンの子孫であるに違いありません: バージョンを調べます。
(DAV:checkin-fork-forbidden): A CHECKIN request MUST fail if it
would cause a version whose DAV:checkin-fork is DAV:forbidden to
appear in the DAV:predecessor-set of more than one version.
(DAV: 禁じられたチェックインフォーク): DAV: チェックインフォークをバージョンに引き起こすなら、要求が失敗しなければならないCHECKINはDAVです: DAV: 1つ以上のバージョンの前任者セットに現れるのが禁じられます。
(DAV:checkin-fork-discouraged): A CHECKIN request MUST fail if it
would cause a version whose DAV:checkin-fork is DAV:discouraged to
appear in the DAV:predecessor-set of more than one version, unless
DAV:fork-ok is specified in the request body.
(DAV: がっかりするチェックインフォーク): DAV: チェックインフォークをバージョンに引き起こすなら、要求が失敗しなければならないCHECKINはDAVです: -OKに分岐しているDAVがセットしない場合1つ以上のバージョンを前任者と同じくらいセットしたDAVに要求本体で指定されているのに現れるので、がっかりしています。
Postconditions:
Postconditions:
(DAV:create-version): The request MUST have created a new version
in the version history of the DAV:checked-out version. The
request MUST have allocated a distinct new URL for the new
(DAV:、バージョンを作成する、)、: 要求はDAVのバージョン歴史の新しいバージョンを作成したに違いありません: バージョンを調べます。 要求は新しさのために異なった新しいURLを割り当てたに違いありません。
Clemm, et al. Standards Track [Page 39] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[39ページ]。
version, and that URL MUST NOT ever identify any resource other
than that version. The URL for the new version MUST be returned in
a Location response header.
バージョン、およびそのURLは特定してはいけません。そのバージョン以外のあらゆるリソースを特定してください。 Location応答ヘッダで新しいバージョンのためのURLを返さなければなりません。
(DAV:initialize-version-content-and-properties): The content, dead
properties, DAV:resourcetype, and DAV:predecessor-set of the new
version MUST be copied from the checked-out resource. The
DAV:version-name of the new version MUST be set to a server-
defined value distinct from all other DAV:version-name values of
other versions in the same version history.
(DAV: バージョン内容と特性を初期化してください): 内容、死んでいる特性、DAV: resourcetype、およびDAV: 調べているリソースから新しいバージョンの前任者セットをコピーしなければなりません。 DAV: 他のすべてのDAVと異なったサーバ定義された値に新しいバージョンのバージョン名を設定しなければなりません: 同じバージョン歴史の他のバージョンのバージョン名値。
(DAV:checked-in): If the request-URL identifies a version-
controlled resource and DAV:keep-checked-out is not specified in
the request body, the DAV:checked-out property of the version-
controlled resource MUST have been removed and a DAV:checked-in
property that identifies the new version MUST have been added.
(DAV: チェックのコネ): 要求URLはバージョンの制御リソースを特定するかどうか、そして、DAV: 調べられた生活費は要求本体で指定されません、DAV: バージョンの制御リソースの調べている資産は取り外されたに違いなくて、DAV: 新しいバージョンを特定する預けている特性は加えられたに違いありません。
(DAV:keep-checked-out): If DAV:keep-checked-out is specified in
the request body, the DAV:checked-out property of the checked-out
resource MUST have been updated to identify the new version.
(DAV: 調べられた生活費): 要求本体でDAV: 調べられた生活費を指定するなら、新しいバージョンを特定するためにDAV: 調べているリソースの調べている特性をアップデートしたに違いありません。
4.4.1 Example - CHECKIN
4.4.1 例--チェックイン
>>REQUEST
>>要求
CHECKIN /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
チェックイン/foo.html HTTP/1.1ホスト: www.webdav.org Content-長さ: 0
>>RESPONSE
>>応答
HTTP/1.1 201 Created
Location: http://repo.webdav.org/his/23/ver/32
Cache-Control: no-cache
HTTP/1.1 201は位置を作成しました: http://repo.webdav.org/his/23/ver/32 キャッシュ制御: キャッシュがありません。
In this example, version-controlled resource /foo.html is checked in, and a new version is created at http://repo.webdav.org/his/23/ver/32.
この例では、バージョンで制御されたリソース/foo.htmlは預けられます、そして、新しいバージョンは http://repo.webdav.org/his/23/ver/32 に作成されます。
4.5 UNCHECKOUT Method
4.5 UNCHECKOUTメソッド
An UNCHECKOUT request can be applied to a checked-out version- controlled resource to cancel the CHECKOUT and restore the pre- CHECKOUT state of the version-controlled resource.
CHECKOUTを取り消して、バージョンで制御されたリソースのプレCHECKOUT状態を回復するために調べているバージョン制御リソースにUNCHECKOUT要求を適用できます。
If an UNCHECKOUT request fails, the server MUST undo any partial effects of the UNCHECKOUT request.
UNCHECKOUT要求が失敗するなら、サーバはUNCHECKOUT要求のどんな部分的な効果も元に戻さなければなりません。
Clemm, et al. Standards Track [Page 40] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[40ページ]。
Marshalling:
整理します:
If a request body is included, it MUST be a DAV:uncheckout XML
element.
要求本体が含まれているなら、それはDAVであるに違いありません: uncheckout XML要素。
<!ELEMENT uncheckout ANY>
<!ELEMENT uncheckoutはあらゆる>です。
If a response body for a successful request is included, it MUST
be a DAV:uncheckout-response XML element.
うまくいっている要求のための応答本体が含まれているなら、それはDAVであるに違いありません: 非チェックアウト-応答XML要素。
<!ELEMENT uncheckout-response ANY>
<!ELEMENT uncheckout-応答いずれも>。
The response MUST include a Cache-Control:no-cache header.
応答はCache-コントロールを含まなければなりません: キャッシュがないヘッダー。
Preconditions:
前提条件:
(DAV:must-be-checked-out-version-controlled-resource): The
request-URL MUST identify a version-controlled resource with a
DAV:checked-out property.
(DAV:、バージョンの制御リソースからチェックしていなければならない、)、: 要求URLはバージョンで制御されたリソースをDAVと同一視しなければなりません: 特性を調べます。
Postconditions:
Postconditions:
(DAV:cancel-checked-out): The value of the DAV:checked-in property
is that of the DAV:checked-out property prior to the request, and
the DAV:checked-out property has been removed.
(DAV: 調べられたキャンセル): DAVの値: 預けている特性はDAVのものです: 要求の前に特性を調べます、そして、DAV: 調べている資産を取り外してあります。
(DAV:restore-content-and-dead-properties): The content and dead
properties of the version-controlled resource are copies of its
DAV:checked-in version.
(DAV: 満足していて死んでいる特性を返してください): バージョンで制御されたリソースの満足していて死んでいる特性はDAVのコピーです: バージョンを預けます。
4.5.1 Example - UNCHECKOUT
4.5.1 例--UNCHECKOUT
>>REQUEST
>>要求
UNCHECKOUT /foo.html HTTP/1.1
Host: www.webdav.org
Content-Length: 0
UNCHECKOUT /foo.html HTTP/1.1ホスト: www.webdav.org Content-長さ: 0
>>RESPONSE
>>応答
HTTP/1.1 200 OK
Cache-Control: no-cache
HTTP/1.1 200はキャッシュ制御を承認します: キャッシュがありません。
In this example, the content and dead properties of the version- controlled resource identified by http://www.webdav.org/foo.html are restored to their values preceding the most recent CHECKOUT of that version-controlled resource.
この例では、 http://www.webdav.org/foo.html によって特定されたバージョンの制御リソースの満足していて死んでいる特性はそのバージョンで制御されたリソースの最新のCHECKOUTに先行するそれらの値に返されます。
Clemm, et al. Standards Track [Page 41] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[41ページ]。
4.6 Additional OPTIONS Semantics
4.6 追加オプション意味論
If a server supports the checkout-in-place feature, it MUST include "checkout-in-place" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
サーバが適所でのチェックアウト機能をサポートするなら、それはDAV応答ヘッダの分野としてどんなversioningの特性、レポートもサポートするどんなリソースに関するOPTIONS要求、またはメソッドからも「適所でのチェックアウト」を含まなければなりません。
5 Version-History Feature
5バージョンヒストリ機能
It is often useful to have access to a version history even after all version-controlled resources for that version history have been deleted. A server can provide this functionality by supporting version history resources. A version history resource is a resource that exists in a server defined namespace and therefore is unaffected by any deletion or movement of version-controlled resources. A version history resource is an appropriate place to add a property that logically applies to all states of a resource. The DAV:expand- property report (see Section 3.8) can be applied to the DAV:version- set of a version history resource to provide a variety of useful reports on all versions in that version history.
そのバージョン歴史のためのすべてのバージョンで制御されたリソースが削除された後にさえバージョン歴史に近づく手段を持っているのはしばしば役に立ちます。 バージョン歴史がリソースであるとサポートすることによって、サーバはこの機能性を提供できます。 バージョン歴史リソースは、サーバの定義された名前空間で存在するリソースであり、したがって、バージョンで制御されたリソースのどんな削除や動きでも影響を受けないです。 バージョン歴史リソースはリソースのすべての州に論理的に適用される特性を加える適切な場所です。 DAV: DAVに適用できます: バージョンがそのバージョン歴史のすべてのバージョンに関するさまざまな役に立つレポートを提供するためにバージョン歴史リソースをセットしたという特性のレポート(セクション3.8を見る)を広げてください。
5.1 Version History Properties
5.1 バージョン歴史の特性
The DAV:resourcetype of a version history MUST be DAV:version- history.
DAV: バージョン歴史のresourcetypeはDAVであるに違いありません: バージョン歴史。
The version-history feature introduces the following REQUIRED properties for a version history.
バージョンヒストリ機能はバージョン歴史のために以下のREQUIRED資産を紹介します。
5.1.1 DAV:version-set (protected)
5.1.1 DAV: バージョンセット(保護されます)
This property identifies each version of this version history.
この特性はこのバージョン歴史の各バージョンを特定します。
<!ELEMENT version-set (href+)>
ELEMENTがバージョンで設定する<!(href+)>。
5.1.2 DAV:root-version (computed)
5.1.2 DAV: 根バージョン(計算されます)
This property identifies the root version of this version history.
この特性はこのバージョン歴史の根のバージョンを特定します。
<!ELEMENT root-version (href)>
<!ELEMENT根バージョン(href)>。
5.2 Additional Version-Controlled Resource Properties
5.2 追加バージョンで制御されたリソースの特性
The version-history feature introduces the following REQUIRED property for a version-controlled resource.
バージョンヒストリ機能はバージョンで制御されたリソースのために以下のREQUIRED資産を紹介します。
Clemm, et al. Standards Track [Page 42] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[42ページ]。
5.2.1 DAV:version-history (computed)
5.2.1 DAV: バージョン歴史(計算されます)
This property identifies the version history resource for the DAV:checked-in or DAV:checked-out version of this version-controlled resource.
この特性はDAVのためのバージョン歴史リソースを特定します: DAV: チェックのコネかこのバージョンで制御されたリソースの調べているバージョン。
<!ELEMENT version-history (href)>
<!ELEMENTバージョン歴史(href)>。
5.3 Additional Version Properties
5.3 追加バージョンの特性
The version-history feature introduces the following REQUIRED property for a version.
バージョンヒストリ機能はバージョンのために以下のREQUIRED資産を紹介します。
5.3.1 DAV:version-history (computed)
5.3.1 DAV: バージョン歴史(計算されます)
This property identifies the version history that contains this version.
この特性はこのバージョンを含むバージョン歴史を特定します。
<!ELEMENT version-history (href)>
<!ELEMENTバージョン歴史(href)>。
5.4 DAV:locate-by-history Report
5.4DAV: 歴史で、レポートの場所を見つけてください。
Many properties identify a version from some version history. It is often useful to be able to efficiently locate a version-controlled resource for that version history. The DAV:locate-by-history report can be applied to a collection to locate the collection member that is a version-controlled resource for a specified version history resource.
多くの特性が何らかのバージョン歴史からバージョンを特定します。 効率的にそのバージョン歴史のためのバージョンで制御されたリソースの場所を見つけることができるのはしばしば役に立ちます。 DAV: 指定されたバージョン歴史リソースのためのバージョンで制御されたリソースである収集メンバーの居場所を見つけるように歴史の場所を見つけているレポートは収集に適用できます。
Marshalling:
整理します:
The request body MUST be a DAV:locate-by-history XML element.
要求本体はDAVであるに違いありません: 歴史で、XML要素の場所を見つけてください。
<!ELEMENT locate-by-history (version-history-set, prop)>
<!ELEMENT version-history-set (href+)>
prop: see RFC 2518, Section 12.11
<!ELEMENTは歴史で><!ELEMENTバージョン歴史セット(href+)>支柱の場所を見つけます(バージョン歴史セット、支柱): RFC2518、セクション12.11を見てください。
The response body for a successful request MUST be a
DAV:multistatus XML element containing every version-controlled
resource that is a member of the collection identified by the
request-URL, and whose DAV:version-history property identifies one
of the version history resources identified by the request body.
The DAV:prop element in the request body identifies which
properties should be reported in the DAV:prop elements in the
response body.
DAV: multistatus XML要素含有があらゆるバージョンで制御されたリソースであったに違いないならそれが要求URLによって特定された収集のメンバーであり、DAV: バージョン歴史の特性が要求本体によって特定されたバージョン歴史リソースの1つを特定するといううまくいっている要求のための応答本体。 DAV: 要求本体の支柱要素は、どの特性がDAVで報告されるべきであるかを特定します: 応答本体で要素を支えてください。
Clemm, et al. Standards Track [Page 43] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[43ページ]。
Preconditions:
前提条件:
(DAV:must-be-version-history): Each member of the DAV:version-
history-set element in the request body MUST identify a version
history resource.
(DAV:、バージョン歴史でなければならない、)、: DAVの各メンバー: 要求本体のバージョン歴史セット要素はバージョン歴史リソースを特定しなければなりません。
5.4.1 Example - DAV:locate-by-history Report
5.4.1 例--DAV: 歴史で、レポートの場所を見つけてください。
>>REQUEST
>>要求
REPORT /ws/public HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
/ws/public HTTP/1.1ホストを報告してください: www.webdav.orgコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:locate-by-history xmlns:D="DAV:">
<D:version-history-set>
<D:href>http://repo.webdav.org/his/23</D:href>
<D:href>http://repo.webdav.org/his/84</D:href>
<D:href>http://repo.webdav.org/his/129</D:href>
<D:version-history-set/>
<D:prop>
</D:version-history>
</D:prop>
</D:locate-by-history>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 歴史の場所を見つけているxmlns: Dが等しい、「DAV: 「><D: バージョン歴史で設定している><D: 彼の/23</D: href>http://repo.webdav.org/href><D: href>http://repo.webdav。」; 彼の/84</D: href><D: 彼の/129</D: href><D: バージョン歴史セット/><D: org/href>http://repo.webdav.org/支柱></D: バージョン歴史></D: 歴史>の場所を見つけている></Dを支えてください。
>>RESPONSE
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/ws/public/x/test.html</D:href>
<D:propstat>
<D:prop>
<D:version-history>
<D:href>http://repo.webdav.org/his/23</D:href>
</D:version-history>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:multistatus xmlns:Dが等しい、「DAV: 「><D: 応答><D: href>http://www.webdav.org/ws/公衆/x/test.html</D: href><D: propstat><D: ><Dを支えてください: バージョン歴史><D: href>http://repo」; ></D: 支柱><D: 状態>HTTP/1.1 200OK</D: 状態></D: propstat></D: 応答></D: webdav.org/彼の/23</D: href></D: バージョン歴史「マルチ-状態」>。
Clemm, et al. Standards Track [Page 44] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[44ページ]。
In this example, there is only one version-controlled member of /ws/public that is a version-controlled resource for one of the three specified version history resources. In particular, /ws/public/x/test.html is the version-controlled resource for http://repo.webdav.org/his/23.
この例には、3つの指定されたバージョン歴史リソースの1つのバージョンで制御されたリソースである/ws/publicの1人のバージョンで制御されたメンバーしかいません。 /ws/public/x/test.htmlは特に、 http://repo.webdav.org/his/23 のためのバージョンで制御されたリソースです。
5.5 Additional OPTIONS Semantics
5.5 追加オプション意味論
If the server supports the version-history feature, it MUST include "version-history" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
サーバがバージョンヒストリ機能をサポートするなら、それはOPTIONS要求からのDAV応答ヘッダの分野としてのどんなversioningの特性も支えるどんなリソースに関する「バージョン歴史」、レポート、またはメソッドも含まなければなりません。
A DAV:version-history-collection-set element MAY be included in the request body to identify collections that may contain version history resources.
DAV: バージョン歴史収集セット要素は、バージョン歴史リソースを含むかもしれない収集を特定するために要求本体に含まれるかもしれません。
Additional Marshalling:
追加整理:
If an XML request body is included, it MUST be a DAV:options XML
element.
XML要求ボディーが含まれているなら、それはDAVであるに違いありません: オプションXML要素。
<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
DAV:version-history-collection-set element.
いずれも>が少しも評価する<!ELEMENTオプション: 高々1DAVがある要素の系列: バージョン歴史収集セット要素。
If an XML response body for a successful request is included, it
MUST be a DAV:options-response XML element.
うまくいっている要求のためのXML応答ボディーが含まれているなら、それはDAVであるに違いありません: オプション応答XML要素。
<!ELEMENT options-response ANY>
ANY value: A sequence of elements with at most one
DAV:version-history-collection-set element.
どんな>も少しも評価する<!ELEMENTオプション応答: 高々1DAVがある要素の系列: バージョン歴史収集セット要素。
<!ELEMENT version-history-collection-set (href*)>
<!ELEMENTバージョン歴史収集セット(href*)>。
If DAV:version-history-collection-set is included in the request
body, the response body for a successful request MUST contain a
DAV:version-history-collection-set element identifying collections
that may contain version histories. An identified collection MAY
be the root collection of a tree of collections, all of which may
contain version histories. Since different servers can control
different parts of the URL namespace, different resources on the
same host MAY have different DAV:version-history-collection-set
values. The identified collections MAY be located on different
hosts from the resource.
DAV: 収集が設定したバージョン歴史が要求本体に含まれているなら、うまくいっている要求のための応答本体はDAVを含まなければなりません: バージョン歴史を含むかもしれない収集を特定するバージョン歴史収集セット要素。 特定された収集は収集の木の根の収集であるかもしれません。そのすべてがバージョン歴史を含むかもしれません。 異なったサーバがURL名前空間の異なった部品を制御できるので、同じホストに関する異なったリソースには、異なったDAVがあるかもしれません: バージョン歴史収集設定値。 特定された収集はリソースからの異なったホストの上に位置するかもしれません。
Clemm, et al. Standards Track [Page 45] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[45ページ]。
5.6 Additional DELETE Semantics
5.6、追加、意味論を削除してください。
Additional Postconditions:
追加Postconditions:
(DAV:delete-version-set): If the request deleted a version
history, the request MUST have deleted all versions in the
DAV:version-set of that version history, and MUST have satisfied
the postconditions for version deletion (see Section 3.13).
(設定していた状態でバージョンを削除しているDAV): 要求がバージョン歴史を削除したなら、要求は、DAV: そのバージョン歴史のバージョンセットですべてのバージョンを削除したに違いなくて、バージョン削除のためにpostconditionsを満たしたに違いありません(セクション3.13を見てください)。
(DAV:version-history-has-root): If the request deleted the root
version of a version history, the request MUST have updated the
DAV:root-version of the version history to refer to another
version that is an ancestor of all other remaining versions in
that version history. A result of this postcondition is that
every version history will have at least one version, and the only
way to delete all versions is to delete the version history
resource.
(DAV: 歴史で根づくバージョン): 要求がバージョン歴史の根のバージョンを削除したなら、要求はDAVをアップデートしたに違いありません: そのバージョン歴史の他のすべての残っているバージョンの先祖である別のバージョンを示すバージョン歴史の根バージョン。 このpostconditionの結果はあらゆるバージョン歴史には少なくとも1つのバージョンがあるということです、そして、すべてのバージョンを削除する唯一の方法はバージョン歴史リソースを削除することです。
5.7 Additional COPY Semantics
5.7 複本意味論
Additional Preconditions:
追加前提条件:
(DAV:cannot-copy-history): If the request-URL identifies a version
history, the request MUST fail. In order to create another
version history whose versions have the same content and dead
properties, the appropriate sequence of VERSION-CONTROL, CHECKOUT,
PUT, PROPPATCH, and CHECKIN requests must be made.
(DAV:、歴史をコピーできない、)、: 要求URLがバージョン歴史を特定するなら、要求は失敗しなければなりません。 バージョンには同じ内容と死んでいる特性がある別のバージョン歴史を引き起こすために、バージョン-CONTROL、CHECKOUT、PUT、PROPPATCH、およびCHECKIN要求の適切な系列を作らなければなりません。
5.8 Additional MOVE Semantics
5.8 追加移動意味論
Additional Preconditions:
追加前提条件:
(DAV:cannot-rename-history): If the request-URL identifies a
version history, the request MUST fail.
(DAV:、歴史を改名できない、)、: 要求URLがバージョン歴史を特定するなら、要求は失敗しなければなりません。
5.9 Additional VERSION-CONTROL Semantics
5.9 追加バージョンコントロール意味論
Additional Postconditions:
追加Postconditions:
(DAV:new-version-history): If the request created a new version
history, the request MUST have allocated a new server-defined URL
for that version history that MUST NOT have previously identified
any other resource, and MUST NOT ever identify a resource other
than this version history.
(DAV: 新しいバージョン歴史): 要求が新しいバージョン歴史を引き起こしたなら、要求は以前にいかなる他のリソースも特定していてはいけなくて、このバージョン歴史以外のリソースは特定してはいけないそのバージョン歴史のために、新しいサーバで定義されたURLを割り当てたに違いありません。
Clemm, et al. Standards Track [Page 46] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[46ページ]。
5.10 Additional CHECKIN Semantics
5.10 追加チェックイン意味論
Additional Postconditions:
追加Postconditions:
(DAV:add-to-history): A URL for the new version resource MUST have
been added to the DAV:version-set of the version history of the
DAV:checked-out version.
(歴史に加えているDAV): 新しいバージョンリソースのためのURLはDAVに加えられたに違いありません: DAV: 調べているバージョンのバージョン歴史のバージョンセット。
6 Workspace Feature
6ワークスペース機能
In order to allow multiple users to work concurrently on adding versions to the same version history, it is necessary to allocate on the server multiple checked-out resources for the same version history. Even if only one user is making changes to a resource, that user will sometimes wish to create a "private" version, and then to expose that version at a later time. One way to provide this functionality depends on the client keeping track of its current set of checked-out resources. This is the working-resource feature defined in Section 8. The other way to provide this functionality avoids the need for persistent state on the client, and instead has the server maintain a human meaningful namespace for related sets of checked-out resources. This is the workspace feature defined in this section.
複数のユーザが同時に同じバージョン歴史にバージョンを追加すると取り組むのを許容するために、サーバに同じバージョン歴史のための複数の調べているリソースを割り当てるのが必要です。 1人のユーザだけがリソースへの変更を行っても、そのユーザは、「個人的な」バージョンを作成して、そして、後で時々そのバージョンを暴露したくなるでしょう。 この機能性を提供する1つの方法が現在のセットの調べているリソースの動向をおさえるクライアントに頼っています。 これはセクション8で定義された働くリソース機能です。 この機能性を提供するもう片方の方法で、クライアントの上で永続的な状態の必要性を避けて、サーバは関連するセットの調べているリソースのために代わりに人間の重要な名前空間を維持します。 これはこのセクションで定義されたワークスペースの特徴です。
The workspace feature introduces a "workspace resource". A workspace resource is a collection whose members are related version-controlled and non-version-controlled resources. Multiple workspaces may be used to expose different versions and configurations of a set of version-controlled resources concurrently. In order to make changes to a version-controlled resource in one workspace visible in another workspace, that version-controlled resource must be checked in, and then the corresponding version-controlled resource in the other workspace can be updated to display the content and dead properties of the new version.
ワークスペースの特徴は「ワークスペースリソース」を導入します。 ワークスペースリソースはメンバーが関連するバージョンで制御されて非バージョンが制御されたリソースである収集です。 複数のワークスペースが、同時に1セットのバージョンで制御されたリソースの異なった見解と構成を暴露するのに使用されるかもしれません。 別のワークスペースで1つのワークスペースのバージョンで制御されたリソースへの変更を目に見えるようにするように、そのバージョンで制御されたリソースを預けなければなりません、そして、次に、新しいバージョンの満足していて死んでいる資産を表示するためにもう片方のワークスペースの対応するバージョンで制御されたリソースをアップデートできます。
In order to ensure unambiguous merging (see Section 11) and baselining (see Section 12) semantics, a workspace may contain at most one version-controlled resource for a given version history. This is required for unambiguous merging because the MERGE method must identify which version-controlled resource is to be the merge target of a given version. This is required for unambiguous baselining because a baseline can only select one version for a given version-controlled resource.
明白な合併(セクション11を見る)とbaselining(セクション12を見る)意味論を確実にするために、ワークスペースは与えられたバージョン歴史のための1つのバージョンで制御されたリソースを高々含むかもしれません。 MERGEメソッドが、どのバージョンで制御されたリソースが与えられたバージョンのマージ目標であるかことであるかを特定しなければならないので、これが明白な合併に必要です。 基線が1つのバージョンしか選択できないので、明白なbaseliningに、これが与えられたバージョンで制御されたリソースに必要です。
Initially, an empty workspace can be created. Non-version-controlled resources can then be added to the workspace with standard WebDAV requests such as PUT and MKCOL. Version-controlled resources can be added to the workspace with VERSION-CONTROL requests. If the
初めは、空のワークスペースを作成できます。 そして、PUTやMKCOLなどの標準のWebDAV要求で非バージョンが制御されたリソースはワークスペースに加えることができます。 バージョン-CONTROL要求でバージョンで制御されたリソースをワークスペースに加えることができます。 the
Clemm, et al. Standards Track [Page 47] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[47ページ]。
baseline feature is supported, collections in the workspace can be placed under baseline control, and then initialized by existing baselines.
基線機能がサポートされて、ワークスペースでの収集を基線コントロールの下で置いて、次に、既存の基線は初期化できます。
6.1 Workspace Properties
6.1 ワークスペースの特性
The workspace feature introduces the following REQUIRED property for a workspace.
ワークスペースの特徴は以下のREQUIRED資産をワークスペースに紹介します。
6.1.1 DAV:workspace-checkout-set (computed)
6.1.1 DAV: ワークスペースチェックアウトセット(計算されます)
This property identifies each checked-out resource whose DAV:workspace property identifies this workspace.
この特性はそれぞれの調べているリソースを特定します。DAV: ワークスペースの特性はこのワークスペースを特定します。
<!ELEMENT workspace-checkout-set (href*)>
<!ELEMENTワークスペースチェックアウトセット(href*)>。
6.2 Additional Resource Properties
6.2 追加リソースの特性
The workspace feature introduces the following REQUIRED property for a WebDAV resource.
ワークスペースの特徴はWebDAVリソースのために以下のREQUIRED資産を紹介します。
6.2.1 DAV:workspace (protected)
6.2.1 DAV: ワークスペース(保護されます)
The DAV:workspace property of a workspace resource MUST identify itself. The DAV:workspace property of any other type of resource MUST be the same as the DAV:workspace of its parent collection.
DAV: ワークスペースリソースのワークスペースの特性はそれ自体を特定しなければなりません。 DAV: いかなる他のタイプに関するリソースのワークスペースの特性もDAVと同じであるに違いありません: 親収集のワークスペース。
<!ELEMENT workspace (href)>
<!ELEMENTワークスペース(href)>。
6.3 MKWORKSPACE Method
6.3 MKWORKSPACEメソッド
A MKWORKSPACE request creates a new workspace resource. A server MAY restrict workspace creation to particular collections, but a client can determine the location of these collections from a DAV:workspace-collection-set OPTIONS request (see Section 6.4).
MKWORKSPACE要求は新しいワークスペースリソースを作成します。 クライアントはDAVからこれらの収集の位置を決定できます: サーバはワークスペース作成を特定の収集に制限するかもしれません、しかし、OPTIONSが要求する(セクション6.4を見ます)ワークスペース収集セット。
If a MKWORKSPACE request fails, the server state preceding the request MUST be restored.
MKWORKSPACE要求が失敗するなら、要求に先行するサーバ州を回復しなければなりません。
Marshalling:
整理します:
If a request body is included, it MUST be a DAV:mkworkspace XML
element.
要求本体が含まれているなら、それはDAVであるに違いありません: mkworkspace XML要素。
<!ELEMENT mkworkspace ANY>
<!ELEMENT mkworkspaceはあらゆる>です。
If a response body for a successful request is included, it MUST
be a DAV:mkworkspace-response XML element.
うまくいっている要求のための応答本体が含まれているなら、それはDAVであるに違いありません: mkworkspace-応答XML要素。
Clemm, et al. Standards Track [Page 48] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[48ページ]。
<!ELEMENT mkworkspace-response ANY>
<!ELEMENT mkworkspace-応答いずれも>。
The response MUST include a Cache-Control:no-cache header.
応答はCache-コントロールを含まなければなりません: キャッシュがないヘッダー。
Preconditions:
前提条件:
(DAV:resource-must-be-null): A resource MUST NOT exist at the
request-URL.
(DAV:、リソースがヌルであるに違いない、)、: リソースは要求URLに存在してはいけません。
(DAV:workspace-location-ok): The request-URL MUST identify a
location where a workspace can be created.
(DAV: ワークスペース位置のOK): 要求URLはワークスペースを作成できる位置を特定しなければなりません。
Postconditions:
Postconditions:
(DAV:initialize-workspace): A new workspace exists at the
request-URL. The DAV:resourcetype of the workspace MUST be
DAV:collection. The DAV:workspace of the workspace MUST identify
the workspace.
(DAV:、ワークスペースを初期化する、)、: 新しいワークスペースは要求URLに存在しています。 DAV: ワークスペースのresourcetypeはDAVであるに違いありません: 収集。 DAV: ワークスペースのワークスペースはワークスペースを特定しなければなりません。
6.3.1 Example - MKWORKSPACE
6.3.1 例--MKWORKSPACE
>>REQUEST
>>要求
MKWORKSPACE /ws/public HTTP/1.1
Host: www.webdav.org
Content-Length: 0
MKWORKSPACE/ws/公共のHTTP/1.1ホスト: www.webdav.org Content-長さ: 0
>>RESPONSE
>>応答
HTTP/1.1 201 Created
Cache-Control: no-cache
HTTP/1.1 201はキャッシュ制御を作成しました: キャッシュがありません。
In this example, a new workspace is created at http://www.webdav.org/ws/public.
この例では、新しいワークスペースは http://www.webdav.org/ws/public に作成されます。
6.4 Additional OPTIONS Semantics
6.4 追加オプション意味論
If a server supports the workspace feature, it MUST include "workspace" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
サーバがワークスペースの特徴をサポートするなら、それはDAV応答ヘッダの分野としてどんなversioningの特性、レポートもサポートするどんなリソースに関するOPTIONS要求、またはメソッドからも「ワークスペース」を含まなければなりません。
If a server supports the workspace feature, it MUST also support the checkout-in-place feature and the version-history feature.
また、サーバがワークスペースの特徴をサポートするなら、それは適所でのチェックアウト機能とバージョンヒストリ機能をサポートしなければなりません。
A DAV:workspace-collection-set element MAY be included in the request body to identify collections that may contain workspace resources.
DAV: ワークスペース収集セット要素は、ワークスペースリソースを含むかもしれない収集を特定するために要求本体に含まれるかもしれません。
Clemm, et al. Standards Track [Page 49] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[49ページ]。
Additional Marshalling:
追加整理:
If an XML request body is included, it MUST be a DAV:options XML
element.
XML要求ボディーが含まれているなら、それはDAVであるに違いありません: オプションXML要素。
<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
DAV:workspace-collection-set element.
いずれも>が少しも評価する<!ELEMENTオプション: 高々1DAVがある要素の系列: ワークスペース収集セット要素。
If an XML response body for a successful request is included, it
MUST be a DAV:options-response XML element.
うまくいっている要求のためのXML応答ボディーが含まれているなら、それはDAVであるに違いありません: オプション応答XML要素。
<!ELEMENT options-response ANY>
ANY value: A sequence of elements with at most one
DAV:workspace-collection-set element.
どんな>も少しも評価する<!ELEMENTオプション応答: 高々1DAVがある要素の系列: ワークスペース収集セット要素。
<!ELEMENT workspace-collection-set (href*)>
<!ELEMENTワークスペース収集セット(href*)>。
If DAV:workspace-collection-set is included in the request body,
the response body for a successful request MUST contain a
DAV:workspace-collection-set element identifying collections that
may contain workspaces. An identified collection MAY be the root
collection of a tree of collections, all of which may contain
workspaces. Since different servers can control different parts
of the URL namespace, different resources on the same host MAY
have different DAV:workspace-collection-set values. The
identified collections MAY be located on different hosts from the
resource.
DAV: 収集が設定したワークスペースが要求本体に含まれているなら、うまくいっている要求のための応答本体はDAVを含まなければなりません: ワークスペースを含むかもしれない収集を特定するワークスペース収集セット要素。 特定された収集は収集の木の根の収集であるかもしれません。そのすべてがワークスペースを含むかもしれません。 異なったサーバがURL名前空間の異なった部品を制御できるので、同じホストに関する異なったリソースには、異なったDAVがあるかもしれません: ワークスペース収集設定値。 特定された収集はリソースからの異なったホストの上に位置するかもしれません。
Clemm, et al. Standards Track [Page 50] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[50ページ]。
6.4.1 Example - OPTIONS
6.4.1 例--オプション
>>REQUEST
>>要求
OPTIONS /doc HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
オプション/doc HTTP/1.1ホスト: www.webdav.orgコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<D:version-history-collection-set/>
<D:workspace-collection-set/>
</D:options>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: オプションxmlns: Dが等しい、「DAV: 「><D: バージョン歴史収集セット/><D: ワークスペース収集セット/></D: オプション>」
>>RESPONSE
>>応答
HTTP/1.1 200 OK
DAV: 1
DAV: version-control,checkout-in-place,version-history,workspace
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200はDAVを承認します: 1DAV: バージョンコントロール、適所でのチェックアウト、バージョン歴史、ワークスペースコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:options-response xmlns:D="DAV:">
<D:version-history-collection-set>
<D:href>http://repo.webdav.org/his</D:href>
</D:version-history-collection-set>
<D:workspace-collection-set>
<D:href>http://www.webdav.org/public/ws</D:href>
<D:href>http://www.webdav.org/private/ws</D:href>
</D:workspace-collection-set>
</D:options-response>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: オプション応答xmlns: Dが等しい、「DAV: 「><D: バージョン歴史収集で設定している><D: ><D: ワークスペース収集に設定された><D: href>http://repo.webdav.org/彼の</D: href></D: バージョン歴史収集セットhref>http://www。」; webdav.org/公衆/ws</D: href><D: href>http://www.webdav.org/個人的な/ws</D: href></D: ワークスペース収集に設定された></D: オプション応答>。
In this example, the server indicates that it provides Class 1 DAV support and basic-server-workspace versioning support. In addition, the server indicates the requested locations of the version history resources and the workspace resources.
この例では、サーバは、サポートをversioningしながらDAVサポートと基本的なサーバワークスペースをClass1に供給するのを示します。 さらに、サーバはバージョン歴史リソースとワークスペースリソースの要求された位置を示します。
6.5 Additional DELETE Semantics
6.5、追加、意味論を削除してください。
Additional Postconditions:
追加Postconditions:
(DAV:delete-workspace-members): If a workspace is deleted, any
resource that identifies that workspace in its DAV:workspace
property MUST be deleted.
(DAV: ワークスペースメンバーを削除してください): ワークスペースが削除されるなら、DAVでそのワークスペースを特定するどんなリソースも: ワークスペースの特性を削除しなければなりません。
Clemm, et al. Standards Track [Page 51] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[51ページ]。
6.6 Additional MOVE Semantics
6.6 追加移動意味論
Additional Postconditions:
追加Postconditions:
(DAV:workspace-member-moved): If the request-URL did not identify
a workspace, the DAV:workspace of the destination MUST have been
updated to have the same value as the DAV:workspace of the parent
collection of the destination.
(DAV: 動かされたワークスペースメンバー): 要求URLがワークスペースを特定しなかったなら、DAVと同じ値を持つためにDAV: 目的地のワークスペースをアップデートしたに違いありません: 目的地の親収集のワークスペース。
(DAV:workspace-moved): If the request-URL identified a workspace,
any reference to that workspace in a DAV:workspace property MUST
have been updated to refer to the new location of that workspace.
(DAV:、ワークスペースで動かれる、)、: 要求URLがワークスペースを特定したなら、そのワークスペースの新しい位置について言及するためにDAVのそのワークスペースのどんな参照: ワークスペースの特性をアップデートしたに違いありません。
6.7 Additional VERSION-CONTROL Semantics
6.7 追加バージョンコントロール意味論
A VERSION-CONTROL request can be used to create a new version- controlled resource for an existing version history. This allows the creation of version-controlled resources for the same version history in multiple workspaces.
既存のバージョン歴史のための新しいバージョン制御リソースを作成するのにバージョン-CONTROL要求を使用できます。 これは複数のワークスペースの同じバージョン歴史のためのバージョンで制御されたリソースの作成を許容します。
Additional Marshalling:
追加整理:
<!ELEMENT version-control ANY>
ANY value: A sequence of elements with at most one DAV:version
element.
どんな>も少しも評価する<!ELEMENTバージョンコントロール: 高々1DAVがある要素の系列: バージョン要素。
<!ELEMENT version (href)>
<!ELEMENTバージョン(href)>。
Additional Preconditions:
追加前提条件:
(DAV:cannot-add-to-existing-history): If the DAV:version-control
request body element contains a DAV:version element, the request-
URL MUST NOT identify a resource.
(既存の歴史に加えるはずがないDAV): DAV: バージョンコントロール要求ボディー要素がDAV: バージョン要素を含んでいるなら、要求URLはリソースを特定してはいけません。
(DAV:must-be-version): The DAV:href of the DAV:version element
MUST identify a version.
(DAV:、バージョンでなければならない、)、: DAV: DAVのhref: バージョン要素はバージョンを特定しなければなりません。
(DAV:one-version-controlled-resource-per-history-per-workspace):
If the DAV:version-control request body specifies a version, and
if the request-URL is a member of a workspace, then there MUST NOT
already be a version-controlled member of that workspace whose
DAV:checked-in or DAV:checked-out property identifies any version
from the version history of the version specified in the request
body.
(DAV: 1ワークスペースあたりの歴史あたり1つのバージョンの制御リソース): DAV: バージョンコントロール要求本体がバージョンを指定して、要求URLがワークスペースのメンバーであるなら、そのワークスペースのDAV: チェックのコネかDAVのバージョンで制御されたメンバーが既にいるはずがありません: 調べている特性は要求本体で指定されたバージョンのバージョン歴史からどんなバージョンも特定します。
Clemm, et al. Standards Track [Page 52] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[52ページ]。
Additional Postconditions:
追加Postconditions:
(DAV:new-version-controlled-resource): If the request-URL did NOT
identify a resource, a new version-controlled resource exists at
the request-URL whose content and dead properties are initialized
by those of the version in the request body, and whose
DAV:checked-in property identifies that version.
(DAV: 新しいバージョン制御リソース): 要求URLがリソースを特定しなかったなら、新しいバージョンで制御されたリソースは満足していて死んでいる特性が要求本体でバージョンのものによって初期化される要求URLに存在しています、そして、DAV: 預けている特性はそのバージョンを特定します。
6.7.1 Example - VERSION-CONTROL (using an existing version history)
6.7.1 バージョン例--コントロール(既存のバージョン歴史を費やします)
>>REQUEST
>>要求
VERSION-CONTROL /ws/public/bar.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
バージョンコントロール/ws/公衆/bar.html HTTP/1.1ホスト: www.webdav.orgコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:version-control xmlns:D="DAV:">
<D:version>
<D:href>http://repo.webdav.org/his/12/ver/V3</D:href>
</D:version>
</D:version-control>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: バージョンコントロールxmlns: Dが等しい、「DAV: 「><D: バージョン><D: href>http://repo.webdav.org/彼の/12/ver/V3</D: href></D: バージョン></D: バージョンコントロール>」
>>RESPONSE
>>応答
HTTP/1.1 201 Created
Cache-Control: no-cache
HTTP/1.1 201はキャッシュ制御を作成しました: キャッシュがありません。
In this example, a new version-controlled resource is created at /ws/public/bar.html. The content and dead properties of the new version-controlled resource are initialized to be the same as those of the version identified by http://repo.webdav.org/his/12/ver/V3.
この例では、新しいバージョンで制御されたリソースは/ws/public/bar.htmlに作成されます。 バージョンのものが http://repo.webdav.org/his/12/ver/V3 で特定したように新しいバージョンで制御されたリソースの満足していて死んでいる特性は、同じになるように初期化されます。
7 UPDATE Feature
7アップデート機能
The update feature provides a mechanism for changing the state of a checked-in version-controlled resource to be that of another version from the version history of that resource.
アップデート機能はメカニズムをそのリソースのバージョン歴史から別のバージョンのものになるように預けているバージョンで制御されたリソースの状態を変えるのに提供します。
7.1 UPDATE Method
7.1 アップデートメソッド
The UPDATE method modifies the content and dead properties of a checked-in version-controlled resource (the "update target") to be those of a specified version (the "update source") from the version history of that version-controlled resource.
UPDATEメソッドは、そのバージョンで制御されたリソースのバージョン歴史からの指定されたバージョン(「アップデートソース」)のものになるように預けているバージョンで制御されたリソース(「アップデート目標」)の満足していて死んでいる特性を変更します。
Clemm, et al. Standards Track [Page 53] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[53ページ]。
The response to an UPDATE request identifies the resources modified by the request, so that a client can efficiently update any cached state it is maintaining. Extensions to the UPDATE method allow multiple resources to be modified from a single UPDATE request (see Section 12.13).
UPDATE要求への応答は要求で変更されたリソースを特定します、クライアントが効率的にそれが維持しているどんなキャッシュされた状態もアップデートできるように。 UPDATEメソッドへの拡大は、複数のリソースがただ一つのUPDATE要求から変更されるのを許容します(セクション12.13を見てください)。
Marshalling:
整理します:
The request body MUST be a DAV:update element.
要求本体はDAVであるに違いありません: 要素をアップデートしてください。
<!ELEMENT update ANY>
ANY value: A sequence of elements with at most one DAV:version
element and at most one DAV:prop element.
<!ELEMENT version (href)>
prop: see RFC 2518, Section 12.11
どんな>も少しも評価する<!ELEMENTアップデート: 高々1DAVがある要素の系列: バージョン要素と高々1DAV: 要素を支えてください。 <!ELEMENTバージョン(href)>支柱: RFC2518、セクション12.11を見てください。
The response for a successful request MUST be a 207 Multi-Status,
where the DAV:multistatus XML element in the response body
identifies all resources that have been modified by the request.
うまくいっている要求のための応答は207Multi-状態であるに違いありません。(そこでは、DAV: 応答本体のmultistatus XML要素が要求で変更されたすべてのリソースを特定します)。
multistatus: see RFC 2518, Section 12.9
「マルチ-状態」: RFC2518、セクション12.9を見てください。
The response MUST include a Cache-Control:no-cache header.
応答はCache-コントロールを含まなければなりません: キャッシュがないヘッダー。
Postconditions:
Postconditions:
(DAV:update-content-and-properties): If the DAV:version element in
the request body identified a version that is in the same version
history as the DAV:checked-in version of a version-controlled
resource identified by the request-URL, then the content and dead
properties of that version-controlled resource MUST be the same as
those of the version specified by the DAV:version element, and the
DAV:checked-in property of the version-controlled resource MUST
identify that version. The request-URL MUST appear in a
DAV:response element in the response body.
(DAV: アップデート内容と特性): DAV: 要求本体のバージョン要素がバージョンを特定したなら、それはDAVと同じバージョン歴史にいます: 要求URLによって特定されたバージョンで制御されたリソースの預けているバージョン、次に、そのバージョンで制御されたリソースの満足していて死んでいる特性はバージョンのものがDAV: バージョン要素、およびDAVで指定したのと同じであるに違いありません: バージョンで制御されたリソースの預けている特性はそのバージョンを特定しなければなりません。 要求URLはDAVに現れなければなりません: 応答本体の応答要素。
(DAV:report-properties): If DAV:prop is specified in the request
body, the properties specified in the DAV:prop element MUST be
reported in the DAV:response elements in the response body.
(DAV: レポート特性): DAV: 支柱が要求本体で指定されるなら、特性はDAVで指定しました: DAVで支柱要素を報告しなければなりません: 応答本体の応答要素。
Clemm, et al. Standards Track [Page 54] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[54ページ]。
7.1.1 Example - UPDATE
7.1.1 例--アップデート
>>REQUEST
>>要求
UPDATE /foo.html HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
アップデート/foo.html HTTP/1.1ホスト: www.webdav.org文書内容: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:update xmlns:D="DAV:">
<D:version>
<D:href>http://repo.webdav.org/his/23/ver/33</D:href>
</D:version>
</D:update>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: アップデートxmlns: Dが等しい、「DAV: 「><D: バージョン><D: 彼の/23/ver/33</D: href>http://repo.webdav.org/href></D: バージョン></D: >をアップデートしてください」
>>RESPONSE
>>応答
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Cache-Control: no-cache
HTTP/1.1 207マルチ状態コンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx Cache-コントロール: キャッシュがありません。
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/foo.html</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D:multistatus xmlns:Dが等しい、「DAV: 「><D: 応答><D: href>http://www.webdav.org/foo.html</D: href><D: 状態>HTTP/1.1 200OK</D: 状態></D: 応答>」
In this example, the content and dead properties of http://repo.webdav.org/his/23/ver/33 are copied to the version- controlled resource /foo.html, and the DAV:checked-in property of /foo.html is updated to refer to http://repo.webdav.org/his/23/ver/33.
この例では、 http://repo.webdav.org/his/23/ver/33 の満足していて死んでいる特性はバージョンの制御リソース/foo.html、およびDAVにコピーされます: http://repo.webdav.org/his/23/ver/33 について言及するために/foo.htmlの預けている特性をアップデートします。
7.2 Additional OPTIONS Semantics
7.2 追加オプション意味論
If the server supports the update feature, it MUST include "update" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
サーバがアップデート機能をサポートするなら、それはDAV応答ヘッダの分野としてどんなversioningの特性、レポートもサポートするどんなリソースに関するOPTIONS要求、またはメソッドからも「アップデート」を含まなければなりません。
Clemm, et al. Standards Track [Page 55] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[55ページ]。
8 Label Feature
8ラベル機能
A version "label" is a string that distinguishes one version in a version history from all other versions in that version history. A label can automatically be assigned by a server, or it can be assigned by a client in order to provide a meaningful name for that version. A given version label can be assigned to at most one version of a given version history, but client assigned labels can be reassigned to another version at any time. Note that although a given label can be applied to at most one version from the same version history, the same label can be applied to versions from different version histories.
「ラベル」というバージョンはそのバージョン歴史の他のすべてのバージョンとバージョン歴史の1つのバージョンを区別するストリングです。 サーバで自動的にラベルを割り当てることができますか、またはクライアントは、重要な名前をそのバージョンに提供するためにそれを割り当てることができます。 高々与えられたバージョン歴史の1つのバージョンしか与えられたバージョンラベルを割り当てることができませんが、いつでも、クライアントの割り当てられたラベルを別のバージョンに再選任できます。 与えられたラベルを同じバージョン歴史から高々1つのバージョンしか適用できませんが、同じラベルを異なった見解歴史からバージョンに適用できることに注意してください。
For certain methods, if the request-URL identifies a version- controlled resource, a label can be specified in a Label request header (see Section 8.3) to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.
あるメソッドとして、要求URLがバージョンの制御リソースを特定するなら、そのラベルによってそのバージョンで制御されたリソースのバージョン歴史から選択されたバージョンに適用されるべきメソッドを引き起こすためにLabel要求ヘッダー(セクション8.3を見る)でラベルを指定できます。
8.1 Additional Version Properties
8.1 追加バージョンの特性
The label feature introduces the following REQUIRED property for a version.
ラベルの特徴はバージョンのために以下のREQUIRED資産を紹介します。
8.1.1 DAV:label-name-set (protected)
8.1.1 DAV: ラベル名前セット(保護されます)
This property contains the labels that currently select this version.
この特性は現在このバージョンを選択するラベルを含んでいます。
<!ELEMENT label-name-set (label-name*)> <!ELEMENT label-name (#PCDATA)> PCDATA value: string
<!ELEMENTラベル名前セット(ラベル名*)><!ELEMENTラベル名(#PCDATA)>PCDATA価値: ストリング
8.2 LABEL Method
8.2 ラベルメソッド
A LABEL request can be applied to a version to modify the labels that select that version. The case of a label name MUST be preserved when it is stored and retrieved. When comparing two label names to decide if they match or not, a server SHOULD use a case-sensitive URL- escaped UTF-8 encoded comparison of the two label names.
そのバージョンを選択するラベルを変更するためにLABEL要求をバージョンに適用できます。 それが保存されて、検索されるとき、ラベル名に関するケースを保存しなければなりません。 比較するとき、2はそれらが合っているかどうか決めるために名前をラベルして、サーバSHOULD使用は2つのラベル名の逃げられたUTF-8がコード化した大文字と小文字を区別するURL比較です。
If a LABEL request is applied to a checked in version-controlled resource, the operation MUST be applied to the DAV:checked-in version of that version-controlled resource.
LABEL要求がバージョンで制御されたリソースでチェックされたaに適用されるなら、操作をDAVに適用しなければなりません: そのバージョンで制御されたリソースのチェックのコネのバージョン。
Clemm, et al. Standards Track [Page 56] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[56ページ]。
Marshalling:
整理します:
The request body MUST be a DAV:label element.
要求本体はDAVであるに違いありません: ラベル要素。
<!ELEMENT label ANY>
ANY value: A sequence of elements with at most one DAV:add,
DAV:set, or DAV:remove element.
ELEMENTが少しもどんな>もラベルする<!は以下を評価します。 DAV: セット、またはDAV:、 高々あるDAVがある要素の系列: 加えてください、そして、要素を取り除いてください。
<!ELEMENT add (label-name)>
<!ELEMENT set (label-name)>
<!ELEMENT remove (label-name)>
<!ELEMENT label-name (#PCDATA)>
PCDATA value: string
<!ELEMENTは、(ラベル名)><!ELEMENTが(ラベル名)><を設定するのを高めます!ELEMENTは(ラベル名)><!ELEMENTラベル名(#PCDATA)>PCDATA価値を取り除きます: ストリング
The request MAY include a Label header.
要求はLabelヘッダーを含むかもしれません。
The request MAY include a Depth header. If no Depth header is
included, Depth:0 is assumed. Standard depth semantics apply, and
the request is applied to the collection identified by the
request-URL and to all members of the collection that satisfy the
Depth value. If a Depth header is included and the request fails
on any resource, the response MUST be a 207 Multi-Status that
identifies all resources for which the request has failed.
The request MAY include a Depth header. If no Depth header is included, Depth:0 is assumed. Standard depth semantics apply, and the request is applied to the collection identified by the request-URL and to all members of the collection that satisfy the Depth value. If a Depth header is included and the request fails on any resource, the response MUST be a 207 Multi-Status that identifies all resources for which the request has failed.
If a response body for a successful request is included, it MUST
be a DAV:label-response XML element.
If a response body for a successful request is included, it MUST be a DAV:label-response XML element.
<!ELEMENT label-response ANY>
<!ELEMENT label-response ANY>
The response MUST include a Cache-Control:no-cache header.
The response MUST include a Cache-Control:no-cache header.
Preconditions:
Preconditions:
(DAV:must-be-checked-in): If the request-URL identifies a
version-controlled resource, the version-controlled resource MUST
be checked in.
(DAV:must-be-checked-in): If the request-URL identifies a version-controlled resource, the version-controlled resource MUST be checked in.
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
(DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.
(DAV:add-must-be-new-label): If DAV:add is specified in the
request body, the specified label MUST NOT appear in the
DAV:label-name-set of any version in the version history of that
version-controlled resource.
(DAV:add-must-be-new-label): If DAV:add is specified in the request body, the specified label MUST NOT appear in the DAV:label-name-set of any version in the version history of that version-controlled resource.
Clemm, et al. Standards Track [Page 57] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 57] RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:label-must-exist): If DAV:remove is specified in the request
body, the specified label MUST appear in the DAV:label-name-set of
that version.
(DAV:label-must-exist): If DAV:remove is specified in the request body, the specified label MUST appear in the DAV:label-name-set of that version.
Postconditions:
Postconditions:
(DAV:add-or-set-label): If DAV:add or DAV:set is specified in the
request body, the specified label MUST appear in the DAV:label-
name-set of the specified version, and MUST NOT appear in the
DAV:label-name-set of any other version in the version history of
that version.
(DAV:add-or-set-label): If DAV:add or DAV:set is specified in the request body, the specified label MUST appear in the DAV:label- name-set of the specified version, and MUST NOT appear in the DAV:label-name-set of any other version in the version history of that version.
(DAV:remove-label): If DAV:remove is specified in the request
body, the specified label MUST NOT appear in the DAV:label-name-
set of any version in the version history of that version.
(DAV:remove-label): If DAV:remove is specified in the request body, the specified label MUST NOT appear in the DAV:label-name- set of any version in the version history of that version.
8.2.1 Example - Setting a label
8.2.1 Example - Setting a label
>>REQUEST
>>REQUEST
LABEL /foo.html HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
LABEL /foo.html HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:label xmlns:D="DAV:">
<D:set>
<D:label-name>default</D:label-name>
</D:set>
</D:label>
<?xml version="1.0" encoding="utf-8" ?> <D:label xmlns:D="DAV:"> <D:set> <D:label-name>default</D:label-name> </D:set> </D:label>
>>RESPONSE
>>RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache
HTTP/1.1 200 OK Cache-Control: no-cache
In this example, the label "default" is applied to the DAV:checked-in version of /foo.html.
In this example, the label "default" is applied to the DAV:checked-in version of /foo.html.
8.3 Label Header
8.3 Label Header
For certain methods (e.g. GET, PROPFIND), if the request-URL identifies a version-controlled resource, a label can be specified in a Label request header to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.
For certain methods (e.g. GET, PROPFIND), if the request-URL identifies a version-controlled resource, a label can be specified in a Label request header to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.
Clemm, et al. Standards Track [Page 58] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 58] RFC 3253 Versioning Extensions to WebDAV March 2002
The value of a label header is the name of a label, encoded using URL-escaped UTF-8. For example, the label "release B.3" is identified by the following header:
The value of a label header is the name of a label, encoded using URL-escaped UTF-8. For example, the label "release B.3" is identified by the following header:
Label: release%20B.3
Label: release%20B.3
A Label header MUST have no effect on a request whose request-URL does not identify a version-controlled resource. In particular, it MUST have no effect on a request whose request-URL identifies a version or a version history.
A Label header MUST have no effect on a request whose request-URL does not identify a version-controlled resource. In particular, it MUST have no effect on a request whose request-URL identifies a version or a version history.
A server MUST return an HTTP-1.1 Vary header containing Label in a successful response to a cacheable request (e.g., GET) that includes a Label header.
A server MUST return an HTTP-1.1 Vary header containing Label in a successful response to a cacheable request (e.g., GET) that includes a Label header.
8.4 Additional OPTIONS Semantics
8.4 Additional OPTIONS Semantics
If the server supports the label feature, it MUST include "label" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
If the server supports the label feature, it MUST include "label" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
8.5 Additional GET Semantics
8.5 Additional GET Semantics
Additional Marshalling:
Additional Marshalling:
The request MAY include a Label header.
The request MAY include a Label header.
Additional Preconditions:
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
(DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.
Additional Postconditions:
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a version-controlled resource and a Label request
header is included, the response MUST contain the content of the
specified version rather than that of the version-controlled
resource.
(DAV:apply-request-to-labeled-version): If the request-URL identifies a version-controlled resource and a Label request header is included, the response MUST contain the content of the specified version rather than that of the version-controlled resource.
8.6 Additional PROPFIND Semantics
8.6 Additional PROPFIND Semantics
Additional Marshalling:
Additional Marshalling:
The request MAY include a Label header.
The request MAY include a Label header.
Clemm, et al. Standards Track [Page 59] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 59] RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions:
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
(DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.
Additional Postconditions:
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a version-controlled resource and a Label request
header is included, the response MUST contain the properties of
the specified version rather than that of the version-controlled
resource.
(DAV:apply-request-to-labeled-version): If the request-URL identifies a version-controlled resource and a Label request header is included, the response MUST contain the properties of the specified version rather than that of the version-controlled resource.
8.7 Additional COPY Semantics
8.7 Additional COPY Semantics
Additional Marshalling:
Additional Marshalling:
The request MAY include a Label header.
The request MAY include a Label header.
Additional Preconditions:
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
(DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.
Additional Postconditions:
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a version-controlled resource and a Label request
header is included, the request MUST have copied the properties
and content of the specified version rather than that of the
version-controlled resource.
(DAV:apply-request-to-labeled-version): If the request-URL identifies a version-controlled resource and a Label request header is included, the request MUST have copied the properties and content of the specified version rather than that of the version-controlled resource.
8.8 Additional CHECKOUT Semantics
8.8 Additional CHECKOUT Semantics
If the server supports the working-resource option, a LABEL header may be included to check out the version selected by the specified label.
If the server supports the working-resource option, a LABEL header may be included to check out the version selected by the specified label.
Additional Marshalling:
Additional Marshalling:
The request MAY include a Label header.
The request MAY include a Label header.
Clemm, et al. Standards Track [Page 60] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 60] RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Preconditions:
Additional Preconditions:
(DAV:must-select-version-in-history): If a Label request header is
included and the request-URL identifies a version-controlled
resource, the specified label MUST select a version in the version
history of the version-controlled resource.
(DAV:must-select-version-in-history): If a Label request header is included and the request-URL identifies a version-controlled resource, the specified label MUST select a version in the version history of the version-controlled resource.
(DAV:must-not-have-label-and-apply-to-version): If a Label request
header is included, the request body MUST NOT contain a
DAV:apply-to-version element.
(DAV:must-not-have-label-and-apply-to-version): If a Label request header is included, the request body MUST NOT contain a DAV:apply-to-version element.
Additional Postconditions:
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If the request-URL
identifies a checked-in version-controlled resource, and a Label
request header is included, the CHECKOUT MUST have been applied to
the version selected by the specified label, and not to the
version-controlled resource itself.
(DAV:apply-request-to-labeled-version): If the request-URL identifies a checked-in version-controlled resource, and a Label request header is included, the CHECKOUT MUST have been applied to the version selected by the specified label, and not to the version-controlled resource itself.
8.9 Additional UPDATE Semantics
8.9 Additional UPDATE Semantics
If the request body of an UPDATE request contains a DAV:label-name element, the update target is the resource identified by the request-URL, and the update source is the version selected by the specified label from the version history of the update target.
If the request body of an UPDATE request contains a DAV:label-name element, the update target is the resource identified by the request-URL, and the update source is the version selected by the specified label from the version history of the update target.
Additional Marshalling:
Additional Marshalling:
<!ELEMENT update ANY>
ANY value: A sequence of elements with at most one DAV:label-name
or DAV:version element (but not both).
<!ELEMENT label-name (#PCDATA)>
PCDATA value: string
<!ELEMENT update ANY> ANY value: A sequence of elements with at most one DAV:label-name or DAV:version element (but not both). <!ELEMENT label-name (#PCDATA)> PCDATA value: string
The request MAY include a Depth header. If no Depth header is
included, Depth:0 is assumed. Standard depth semantics apply, and
the request is applied to the collection identified by the
request-URL and to all members of the collection that satisfy the
Depth value. If a Depth header is included and the request fails
on any resource, the response MUST be a 207 Multi-Status that
identifies all resources for which the request has failed.
The request MAY include a Depth header. If no Depth header is included, Depth:0 is assumed. Standard depth semantics apply, and the request is applied to the collection identified by the request-URL and to all members of the collection that satisfy the Depth value. If a Depth header is included and the request fails on any resource, the response MUST be a 207 Multi-Status that identifies all resources for which the request has failed.
Additional Preconditions:
Additional Preconditions:
(DAV:must-select-version-in-history): If the request includes a
DAV:label-name element in the request body, the label MUST select
a version in the version history of the version-controlled
resource identified by the request-URL.
(DAV:must-select-version-in-history): If the request includes a DAV:label-name element in the request body, the label MUST select a version in the version history of the version-controlled resource identified by the request-URL.
Clemm, et al. Standards Track [Page 61] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 61] RFC 3253 Versioning Extensions to WebDAV March 2002
(DAV:depth-update): If the request includes a Depth header,
standard depth semantics apply, and the request is applied to the
collection identified by the request-URL and to all members of the
collection that satisfy the Depth value. The request MUST be
applied to a collection before being applied to any members of
that collection, since an update of a version-controlled
collection might change the membership of that collection.
(DAV:depth-update): If the request includes a Depth header, standard depth semantics apply, and the request is applied to the collection identified by the request-URL and to all members of the collection that satisfy the Depth value. The request MUST be applied to a collection before being applied to any members of that collection, since an update of a version-controlled collection might change the membership of that collection.
Additional Postconditions:
Additional Postconditions:
(DAV:apply-request-to-labeled-version): If a DAV:label-name
element appears in the request body, the content and dead
properties of the version-controlled resource must have been
updated to be those of the version selected by that label.
(DAV:apply-request-to-labeled-version): If a DAV:label-name element appears in the request body, the content and dead properties of the version-controlled resource must have been updated to be those of the version selected by that label.
9 Working-Resource Feature
9 Working-Resource Feature
The working-resource feature provides an alternative to the workspace feature for supporting parallel development. Unlike the workspace feature, where the desired configuration of versions and checked-out resources is maintained on the server, the working-resource feature maintains the configuration on the client. This simplifies the server implementation, but does not allow a user to access the configuration from clients in different physical locations, such as from another office, from home, or while traveling. Another difference is that the workspace feature isolates clients from a logical change that involves renaming shared resources, until that logical change is complete and tested; with the working resource feature, all clients use a common set of shared version-controlled resources and every client sees the result of a MOVE as soon as it occurs.
The working-resource feature provides an alternative to the workspace feature for supporting parallel development. Unlike the workspace feature, where the desired configuration of versions and checked-out resources is maintained on the server, the working-resource feature maintains the configuration on the client. This simplifies the server implementation, but does not allow a user to access the configuration from clients in different physical locations, such as from another office, from home, or while traveling. Another difference is that the workspace feature isolates clients from a logical change that involves renaming shared resources, until that logical change is complete and tested; with the working resource feature, all clients use a common set of shared version-controlled resources and every client sees the result of a MOVE as soon as it occurs.
If a server supports the working-resource feature but not the checkout-in-place feature, a CHECKOUT request can only be used to create a working resource, and cannot be used to check out a version-controlled resource. If a server supports the checkout-in- place feature, but not the working-resource feature, a CHECKOUT can only be used to change the state of a version-controlled resource from checked-in to checked-out.
If a server supports the working-resource feature but not the checkout-in-place feature, a CHECKOUT request can only be used to create a working resource, and cannot be used to check out a version-controlled resource. If a server supports the checkout-in- place feature, but not the working-resource feature, a CHECKOUT can only be used to change the state of a version-controlled resource from checked-in to checked-out.
9.1 Additional Version Properties
9.1 Additional Version Properties
The working-resource feature introduces the following REQUIRED properties for a version.
The working-resource feature introduces the following REQUIRED properties for a version.
9.1.1 DAV:checkout-fork
9.1.1 DAV:checkout-fork
This property is defined in Section 4.1.1.
This property is defined in Section 4.1.1.
Clemm, et al. Standards Track [Page 62] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 62] RFC 3253 Versioning Extensions to WebDAV March 2002
9.1.2 DAV:checkin-fork
9.1.2 DAV:checkin-fork
This property is defined in Section 4.1.2.
This property is defined in Section 4.1.2.
9.2 Working Resource Properties
9.2 Working Resource Properties
The working-resource feature introduces the following REQUIRED properties for a working resource. Since a working resource is a checked-out resource, it also has any property defined in this document for a checked-out resource.
The working-resource feature introduces the following REQUIRED properties for a working resource. Since a working resource is a checked-out resource, it also has any property defined in this document for a checked-out resource.
9.2.1 DAV:auto-update (protected)
9.2.1 DAV:auto-update (protected)
This property identifies the version-controlled resource that will be updated when the working resource is checked in.
This property identifies the version-controlled resource that will be updated when the working resource is checked in.
<!ELEMENT auto-update (href)>
<!ELEMENT auto-update (href)>
9.2.2 DAV:checkout-fork
9.2.2 DAV:checkout-fork
This property is defined in Section 4.2.1.
This property is defined in Section 4.2.1.
9.2.3 DAV:checkin-fork
9.2.3 DAV:checkin-fork
This property is defined in Section 4.2.2.
This property is defined in Section 4.2.2.
9.3 CHECKOUT Method (applied to a version)
9.3 CHECKOUT Method (applied to a version)
A CHECKOUT request can be applied to a version to create a new working resource. The content and dead properties of the working resource are a copy of the version that was checked out.
A CHECKOUT request can be applied to a version to create a new working resource. The content and dead properties of the working resource are a copy of the version that was checked out.
Marshalling:
Marshalling:
If a request body is included, it MUST be a DAV:checkout XML
element.
If a request body is included, it MUST be a DAV:checkout XML element.
<!ELEMENT checkout ANY>
<!ELEMENT checkout ANY>
ANY value: A sequence of elements with at most one DAV:apply-to-
version and at most one DAV:fork-ok element.
ANY value: A sequence of elements with at most one DAV:apply-to- version and at most one DAV:fork-ok element.
<!ELEMENT apply-to-version EMPTY>
<!ELEMENT fork-ok EMPTY>
<!ELEMENT apply-to-version EMPTY> <!ELEMENT fork-ok EMPTY>
If a response body for a successful request is included,
it MUST be a DAV:checkout-response XML element.
If a response body for a successful request is included, it MUST be a DAV:checkout-response XML element.
Clemm, et al. Standards Track [Page 63] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 63] RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT checkout-response ANY>
<!ELEMENT checkout-response ANY>
The response MUST include a Location header.
The response MUST include a Location header.
The response MUST include a Cache-Control:no-cache header.
The response MUST include a Cache-Control:no-cache header.
Preconditions:
Preconditions:
(DAV:checkout-of-version-with-descendant-is-forbidden): See
Section 4.3.
(DAV:checkout-of-version-with-descendant-is-forbidden): See Section 4.3.
(DAV:checkout-of-version-with-descendant-is-discouraged): See
Section 4.3.
(DAV:checkout-of-version-with-descendant-is-discouraged): See Section 4.3.
(DAV:checkout-of-checked-out-version-is-forbidden): See Section
4.3.
(DAV:checkout-of-checked-out-version-is-forbidden): See Section 4.3.
(DAV:checkout-of-checked-out-version-is-discouraged): See Section
4.3.
(DAV:checkout-of-checked-out-version-is-discouraged): See Section 4.3.
Postconditions:
Postconditions:
(DAV:create-working-resource): If the request-URL identified a
version, the Location response header MUST contain the URL of a
new working resource. The DAV:checked-out property of the new
working resource MUST identify the version that was checked out.
The content and dead properties of the working resource MUST be
copies of the content and dead properties of the DAV:checked-out
version. The DAV:predecessor-set property of the working resource
MUST be initialized to be the version identified by the request-
URL. The DAV:auto-update property of the working resource MUST
NOT exist.
(DAV:create-working-resource): If the request-URL identified a version, the Location response header MUST contain the URL of a new working resource. The DAV:checked-out property of the new working resource MUST identify the version that was checked out. The content and dead properties of the working resource MUST be copies of the content and dead properties of the DAV:checked-out version. The DAV:predecessor-set property of the working resource MUST be initialized to be the version identified by the request- URL. The DAV:auto-update property of the working resource MUST NOT exist.
(DAV:create-working-resource-from-checked-in-version): If the
request-URL identified a version-controlled resource, and
DAV:apply-to-version is specified in the request body, the
CHECKOUT is applied to the DAV:checked-in version of the version-
controlled resource, and not the version-controlled resource
itself. A new working resource is created and the version-
controlled resource remains checked-in. The DAV:auto-update
property of the working resource MUST identify the version-
controlled resource.
(DAV:create-working-resource-from-checked-in-version): If the request-URL identified a version-controlled resource, and DAV:apply-to-version is specified in the request body, the CHECKOUT is applied to the DAV:checked-in version of the version- controlled resource, and not the version-controlled resource itself. A new working resource is created and the version- controlled resource remains checked-in. The DAV:auto-update property of the working resource MUST identify the version- controlled resource.
Clemm, et al. Standards Track [Page 64] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 64] RFC 3253 Versioning Extensions to WebDAV March 2002
9.3.1 Example - CHECKOUT of a version
9.3.1 Example - CHECKOUT of a version
>>REQUEST
>>REQUEST
CHECKOUT /his/12/ver/V3 HTTP/1.1
Host: repo.webdav.org
Content-Length: 0
CHECKOUT /his/12/ver/V3 HTTP/1.1 Host: repo.webdav.org Content-Length: 0
>>RESPONSE
>>RESPONSE
HTTP/1.1 201 Created
Location: http://repo.webdav.org/wr/157
Cache-Control: no-cache
HTTP/1.1 201 Created Location: http://repo.webdav.org/wr/157 Cache-Control: no-cache
In this example, the version identified by http://repo.webdav.org/his/12/ver/V3 is checked out, and the new working resource is located at http://repo.webdav.org/wr/157.
In this example, the version identified by http://repo.webdav.org/his/12/ver/V3 is checked out, and the new working resource is located at http://repo.webdav.org/wr/157.
9.4 CHECKIN Method (applied to a working resource)
9.4 CHECKIN Method (applied to a working resource)
A CHECKIN request can be applied to a working resource to produce a new version whose content and dead properties are a copy of those of the working resource. If the DAV:auto-update property of the working resource was set because the working resource was created by applying a CHECKOUT with the DAV:apply-to-version flag to a version-controlled resource, the CHECKIN request will also update the content and dead properties of that version-controlled resource to be those of the new version.
A CHECKIN request can be applied to a working resource to produce a new version whose content and dead properties are a copy of those of the working resource. If the DAV:auto-update property of the working resource was set because the working resource was created by applying a CHECKOUT with the DAV:apply-to-version flag to a version-controlled resource, the CHECKIN request will also update the content and dead properties of that version-controlled resource to be those of the new version.
Marshalling:
Marshalling:
If a request body is included, it MUST be a DAV:checkin XML
element.
If a request body is included, it MUST be a DAV:checkin XML element.
<!ELEMENT checkin ANY>
ANY value: A sequence of elements with at most one DAV:fork-ok
element.
<!ELEMENT checkin ANY> ANY value: A sequence of elements with at most one DAV:fork-ok element.
<!ELEMENT fork-ok EMPTY>
<!ELEMENT fork-ok EMPTY>
If a response body for a successful request is included, it MUST
be a DAV:checkin-response XML element.
If a response body for a successful request is included, it MUST be a DAV:checkin-response XML element.
<!ELEMENT checkin-response ANY>
<!ELEMENT checkin-response ANY>
The response MUST include a Cache-Control:no-cache header.
The response MUST include a Cache-Control:no-cache header.
Clemm, et al. Standards Track [Page 65] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 65] RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions:
Preconditions:
(DAV:must-be-checked-out): See Section 4.4.
(DAV:must-be-checked-out): See Section 4.4.
(DAV:version-history-is-tree) See Section 4.4.
(DAV:version-history-is-tree) See Section 4.4.
(DAV:checkin-fork-forbidden): See Section 4.4.
(DAV:checkin-fork-forbidden): See Section 4.4.
(DAV:checkin-fork-discouraged): See Section 4.4.
(DAV:checkin-fork-discouraged): See Section 4.4.
(DAV:no-overwrite-by-auto-update): If the DAV:auto-update property
for the checked-out resource identifies a version-controlled
resource, at least one of the versions identified by the
DAV:predecessor-set property of the checked-out resource MUST
identify a version that is either the same as or a descendant of
the version identified by the DAV:checked-in property of that
version-controlled resource.
(DAV:no-overwrite-by-auto-update): If the DAV:auto-update property for the checked-out resource identifies a version-controlled resource, at least one of the versions identified by the DAV:predecessor-set property of the checked-out resource MUST identify a version that is either the same as or a descendant of the version identified by the DAV:checked-in property of that version-controlled resource.
Postconditions:
Postconditions:
(DAV:create-version): See Section 4.4.
(DAV:create-version): See Section 4.4.
(DAV:initialize-version-content-and-properties): See Section 4.4.
(DAV:initialize-version-content-and-properties): See Section 4.4.
(DAV:auto-update): If the DAV:auto-update property of the
checked-out resource identified a version-controlled resource, an
UPDATE request with the new version MUST have been applied to that
version-controlled resource.
(DAV:auto-update): If the DAV:auto-update property of the checked-out resource identified a version-controlled resource, an UPDATE request with the new version MUST have been applied to that version-controlled resource.
(DAV:delete-working-resource): If the request-URL identifies a
working resource and if DAV:keep-checked-out is not specified in
the request body, the working resource is deleted.
(DAV:delete-working-resource): If the request-URL identifies a working resource and if DAV:keep-checked-out is not specified in the request body, the working resource is deleted.
9.4.1 Example - CHECKIN of a working resource
9.4.1 Example - CHECKIN of a working resource
>>REQUEST
>>REQUEST
CHECKIN /wr/157 HTTP/1.1
Host: repo.webdav.org
Content-Length: 0
CHECKIN /wr/157 HTTP/1.1 Host: repo.webdav.org Content-Length: 0
>>RESPONSE
>>RESPONSE
HTTP/1.1 201 Created
Location: http://repo.webdav.org/his/23/ver/15
Cache-Control: no-cache
HTTP/1.1 201 Created Location: http://repo.webdav.org/his/23/ver/15 Cache-Control: no-cache
Clemm, et al. Standards Track [Page 66] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 66] RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the working resource /wr/157 checked in, and a new version is created at http://repo.webdav.org/his/23/ver/15.
In this example, the working resource /wr/157 checked in, and a new version is created at http://repo.webdav.org/his/23/ver/15.
9.5 Additional OPTIONS Semantics
9.5 Additional OPTIONS Semantics
If the server supports the working-resource feature, it MUST include "working-resource" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
If the server supports the working-resource feature, it MUST include "working-resource" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
9.6 Additional COPY Semantics
9.6 Additional COPY Semantics
Additional Postconditions:
Additional Postconditions:
(DAV:copy-creates-new-resource): The result of copying a working
resource is a new non-version-controlled resource at the
destination of the COPY. The new resource MAY automatically be
put under version control, but the resulting version-controlled
resource MUST be associated with a new version history created for
that new version-controlled resource.
(DAV:copy-creates-new-resource): The result of copying a working resource is a new non-version-controlled resource at the destination of the COPY. The new resource MAY automatically be put under version control, but the resulting version-controlled resource MUST be associated with a new version history created for that new version-controlled resource.
9.7 Additional MOVE Semantics
9.7 Additional MOVE Semantics
Additional Preconditions:
Additional Preconditions:
(DAV:cannot-rename-working-resource): If the request-URL
identifies a working resource, the request MUST fail.
(DAV:cannot-rename-working-resource): If the request-URL identifies a working resource, the request MUST fail.
Additional Postconditions:
Additional Postconditions:
(DAV:update-auto-update): If the request-URL identified a
version-controlled resource, any DAV:auto-update properties that
identified that version-controlled resource MUST have been updated
to contain the new location of that version-controlled resource.
(DAV:update-auto-update): If the request-URL identified a version-controlled resource, any DAV:auto-update properties that identified that version-controlled resource MUST have been updated to contain the new location of that version-controlled resource.
10 Advanced Versioning Features
10 Advanced Versioning Features
Advanced versioning addresses the problems of parallel development and configuration management of multiple sets of interrelated resources. Traditionally, artifacts of software development, including requirements, design documents, code, and test cases, have been a focus of configuration management. Web sites, comprising multiple inter-linked resources (HTML, graphics, sound, CGI, and others), are another class of complex information artifacts that benefit from the application of configuration management. The advanced versioning capabilities for coordinating concurrent change provide the infrastructure for efficient and controlled management of large evolving web sites.
Advanced versioning addresses the problems of parallel development and configuration management of multiple sets of interrelated resources. Traditionally, artifacts of software development, including requirements, design documents, code, and test cases, have been a focus of configuration management. Web sites, comprising multiple inter-linked resources (HTML, graphics, sound, CGI, and others), are another class of complex information artifacts that benefit from the application of configuration management. The advanced versioning capabilities for coordinating concurrent change provide the infrastructure for efficient and controlled management of large evolving web sites.
Clemm, et al. Standards Track [Page 67] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 67] RFC 3253 Versioning Extensions to WebDAV March 2002
10.1 Advanced Versioning Packages
10.1 Advanced Versioning Packages
Although a server MAY support any combination of advanced versioning features, in order to minimize the complexity of a WebDAV advanced versioning client, a WebDAV advanced versioning server SHOULD support one of the following packages:
Although a server MAY support any combination of advanced versioning features, in order to minimize the complexity of a WebDAV advanced versioning client, a WebDAV advanced versioning server SHOULD support one of the following packages:
Advanced-Server-Workspace Package: basic-server-workspace package plus all advanced features
Advanced-Server-Workspace Package: basic-server-workspace package plus all advanced features
Advanced-Client-Workspace Package: basic-client-workspace package plus all advanced features
Advanced-Client-Workspace Package: basic-client-workspace package plus all advanced features
The advanced-server-workspace package supports advanced versioning capabilities for a client with no persistent state. The advanced- client-workspace package supports advanced versioning capabilities for a client that maintains configuration state on the client. A server that supports both advanced workspace packages will interoperate with all versioning clients.
The advanced-server-workspace package supports advanced versioning capabilities for a client with no persistent state. The advanced- client-workspace package supports advanced versioning capabilities for a client that maintains configuration state on the client. A server that supports both advanced workspace packages will interoperate with all versioning clients.
10.2 Advanced Versioning Terms
10.2 Advanced Versioning Terms
The following additional terms are used by the advanced versioning features.
The following additional terms are used by the advanced versioning features.
Collection
Collection
A "collection" is a resource whose state consists of not only
content and properties, but also a set of named "bindings", where
a binding identifies what RFC 2518 calls an "internal member" of
the collection. Note that a binding is not a resource, but rather
is a part of the state of a collection that defines a mapping from
a binding name (a URL segment) to a resource (an internal member
of the collection).
A "collection" is a resource whose state consists of not only content and properties, but also a set of named "bindings", where a binding identifies what RFC 2518 calls an "internal member" of the collection. Note that a binding is not a resource, but rather is a part of the state of a collection that defines a mapping from a binding name (a URL segment) to a resource (an internal member of the collection).
Collection Version Resource
Collection Version Resource
A "collection version resource", or simply "collection version",
captures the dead properties of a version-controlled collection,
as well as the names of its version-controlled bindings (see
Section 14). A version-controlled binding is a binding to a
version-controlled resource. If the checkout-in-place feature is
supported, a collection version can be created by checking out and
then checking in a version-controlled collection. If the
working-resource feature is supported, a collection version can be
created by checking out a collection version (to create a "working
collection") and then checking in the working collection.
A "collection version resource", or simply "collection version", captures the dead properties of a version-controlled collection, as well as the names of its version-controlled bindings (see Section 14). A version-controlled binding is a binding to a version-controlled resource. If the checkout-in-place feature is supported, a collection version can be created by checking out and then checking in a version-controlled collection. If the working-resource feature is supported, a collection version can be created by checking out a collection version (to create a "working collection") and then checking in the working collection.
Clemm, et al. Standards Track [Page 68] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 68] RFC 3253 Versioning Extensions to WebDAV March 2002
Configuration
Configuration
A "configuration" is a set of resources that consists of a root
collection and all members (not just internal members) of that
root collection that are not members of another configuration.
The root collection is called the "configuration root", and the
members of this set are called the "members of the configuration".
Note that a collection (which is a single resource) is very
different from a configuration (which is a set of resources).
A "configuration" is a set of resources that consists of a root collection and all members (not just internal members) of that root collection that are not members of another configuration. The root collection is called the "configuration root", and the members of this set are called the "members of the configuration". Note that a collection (which is a single resource) is very different from a configuration (which is a set of resources).
Baseline Resource
Baseline Resource
A "baseline resource", or simply "baseline", of a collection is a
version of the configuration that is rooted at that collection
(see Section 12). In particular, a baseline captures the
DAV:checked-in version of every version-controlled member of that
configuration. Note that a collection version (which captures the
state of a single resource) is very different from a collection
baseline (which captures the state of a set of resources).
A "baseline resource", or simply "baseline", of a collection is a version of the configuration that is rooted at that collection (see Section 12). In particular, a baseline captures the DAV:checked-in version of every version-controlled member of that configuration. Note that a collection version (which captures the state of a single resource) is very different from a collection baseline (which captures the state of a set of resources).
Baseline-Controlled Collection
Baseline-Controlled Collection
A "baseline-controlled collection" is a collection from which
baselines can be created (see Section 12).
A "baseline-controlled collection" is a collection from which baselines can be created (see Section 12).
Version-Controlled Configuration Resource
Version-Controlled Configuration Resource
A "version-controlled configuration resource", or simply
"version-controlled configuration", is a special kind of version-
controlled resource that is associated with a baseline-controlled
collection, and is used to create and access baselines of that
collection (see Section 12). When a collection is both version-
controlled and baseline-controlled, a client can create a new
version of the collection by checking out and checking in that
collection, and it can create a new baseline of that collection by
checking out and checking in the version-controlled configuration
of that collection.
A "version-controlled configuration resource", or simply "version-controlled configuration", is a special kind of version- controlled resource that is associated with a baseline-controlled collection, and is used to create and access baselines of that collection (see Section 12). When a collection is both version- controlled and baseline-controlled, a client can create a new version of the collection by checking out and checking in that collection, and it can create a new baseline of that collection by checking out and checking in the version-controlled configuration of that collection.
Activity Resource
Activity Resource
An "activity resource", or simply "activity", is a resource that
selects a set of versions that correspond to a single logical
change, where the versions selected from a given version history
form a single line of descent through that version history (see
Section 13).
An "activity resource", or simply "activity", is a resource that selects a set of versions that correspond to a single logical change, where the versions selected from a given version history form a single line of descent through that version history (see Section 13).
Clemm, et al. Standards Track [Page 69] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 69] RFC 3253 Versioning Extensions to WebDAV March 2002
11 Merge Feature
11 Merge Feature
When a user wants to accept the changes (new versions) created by someone else, it is important not just to update the version- controlled resources in the user's workspace with those new versions, since this could result in "backing out" changes the user has made to those version-controlled resources. Instead, the versions created in another workspace should be "merged" into the user's version- controlled resources.
When a user wants to accept the changes (new versions) created by someone else, it is important not just to update the version- controlled resources in the user's workspace with those new versions, since this could result in "backing out" changes the user has made to those version-controlled resources. Instead, the versions created in another workspace should be "merged" into the user's version- controlled resources.
The version history of a version-controlled resource provides the information needed to determine the result of the merge. In particular, the merge should select whichever version is later in the line of descent from the root version. In case the versions to be merged are on different lines of descent (neither version is a descendant of the other), neither version should be selected, but instead, a new version should be created that contains the logical merge of the content and dead properties of those versions. The MERGE request can be used to check out each version-controlled resource that requires such a merge, and set the DAV:merge-set property of each checked-out resource to identify the version to be merged. The user is responsible for modifying the content and dead properties of the checked-out resource so that it represents the logical merge of that version, and then adding that version to the DAV:predecessor-set of the checked-out resource.
The version history of a version-controlled resource provides the information needed to determine the result of the merge. In particular, the merge should select whichever version is later in the line of descent from the root version. In case the versions to be merged are on different lines of descent (neither version is a descendant of the other), neither version should be selected, but instead, a new version should be created that contains the logical merge of the content and dead properties of those versions. The MERGE request can be used to check out each version-controlled resource that requires such a merge, and set the DAV:merge-set property of each checked-out resource to identify the version to be merged. The user is responsible for modifying the content and dead properties of the checked-out resource so that it represents the logical merge of that version, and then adding that version to the DAV:predecessor-set of the checked-out resource.
If the server is capable of automatically performing the merge, it MAY update the content, dead properties, and DAV:predecessor-set of the checked-out resource itself. Before checking in the automatically merged resource, the user is responsible for verifying that the automatic merge is correct.
If the server is capable of automatically performing the merge, it MAY update the content, dead properties, and DAV:predecessor-set of the checked-out resource itself. Before checking in the automatically merged resource, the user is responsible for verifying that the automatic merge is correct.
11.1 Additional Checked-Out Resource Properties
11.1 Additional Checked-Out Resource Properties
The merge feature introduces the following REQUIRED properties for a checked-out resource.
The merge feature introduces the following REQUIRED properties for a checked-out resource.
11.1.1 DAV:merge-set
11.1.1 DAV:merge-set
This property identifies each version that is to be merged into this checked-out resource.
This property identifies each version that is to be merged into this checked-out resource.
<!ELEMENT merge-set (href*)>
<!ELEMENT merge-set (href*)>
Clemm, et al. Standards Track [Page 70] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 70] RFC 3253 Versioning Extensions to WebDAV March 2002
11.1.2 DAV:auto-merge-set
11.1.2 DAV:auto-merge-set
This property identifies each version that the server has merged into this checked-out resource. The client should confirm that the merge has been performed correctly before moving a URL from the DAV:auto- merge-set to the DAV:predecessor-set of a checked-out resource.
This property identifies each version that the server has merged into this checked-out resource. The client should confirm that the merge has been performed correctly before moving a URL from the DAV:auto- merge-set to the DAV:predecessor-set of a checked-out resource.
<!ELEMENT auto-merge-set (href*)>
<!ELEMENT auto-merge-set (href*)>
11.2 MERGE Method
11.2 MERGE Method
The MERGE method performs the logical merge of a specified version (the "merge source") into a specified version-controlled resource (the "merge target"). If the merge source is neither an ancestor nor a descendant of the DAV:checked-in or DAV:checked-out version of the merge target, the MERGE checks out the merge target (if it is not already checked out) and adds the URL of the merge source to the DAV:merge-set of the merge target. It is then the client's responsibility to update the content and dead properties of the checked-out merge target so that it reflects the logical merge of the merge source into the current state of the merge target. The client indicates that it has completed the update of the merge target, by deleting the merge source URL from the DAV:merge-set of the checked- out merge target, and adding it to the DAV:predecessor-set. As an error check for a client forgetting to complete a merge, the server MUST fail an attempt to CHECKIN a version-controlled resource with a non-empty DAV:merge-set.
The MERGE method performs the logical merge of a specified version (the "merge source") into a specified version-controlled resource (the "merge target"). If the merge source is neither an ancestor nor a descendant of the DAV:checked-in or DAV:checked-out version of the merge target, the MERGE checks out the merge target (if it is not already checked out) and adds the URL of the merge source to the DAV:merge-set of the merge target. It is then the client's responsibility to update the content and dead properties of the checked-out merge target so that it reflects the logical merge of the merge source into the current state of the merge target. The client indicates that it has completed the update of the merge target, by deleting the merge source URL from the DAV:merge-set of the checked- out merge target, and adding it to the DAV:predecessor-set. As an error check for a client forgetting to complete a merge, the server MUST fail an attempt to CHECKIN a version-controlled resource with a non-empty DAV:merge-set.
When a server has the ability to automatically update the content and dead properties of the merge target to reflect the logical merge of the merge source, it may do so unless DAV:no-auto-merge is specified in the MERGE request body. In order to notify the client that a merge source has been automatically merged, the MERGE request MUST add the URL of the auto-merged source to the DAV:auto-merge-set property of the merge target, and not to the DAV:merge-set property. The client indicates that it has verified that the auto-merge is valid, by deleting the merge source URL from the DAV:auto-merge-set, and adding it to the DAV:predecessor-set.
When a server has the ability to automatically update the content and dead properties of the merge target to reflect the logical merge of the merge source, it may do so unless DAV:no-auto-merge is specified in the MERGE request body. In order to notify the client that a merge source has been automatically merged, the MERGE request MUST add the URL of the auto-merged source to the DAV:auto-merge-set property of the merge target, and not to the DAV:merge-set property. The client indicates that it has verified that the auto-merge is valid, by deleting the merge source URL from the DAV:auto-merge-set, and adding it to the DAV:predecessor-set.
Multiple merge sources can be specified in a single MERGE request. The set of merge sources for a MERGE request is determined from the DAV:source element of the MERGE request body as follows:
Multiple merge sources can be specified in a single MERGE request. The set of merge sources for a MERGE request is determined from the DAV:source element of the MERGE request body as follows:
- If DAV:source identifies a version, that version is a merge
source.
- If DAV:source identifies a version-controlled resource, the
DAV:checked-in version of that version-controlled resource is a
merge source.
- If DAV:source identifies a version, that version is a merge source. - If DAV:source identifies a version-controlled resource, the DAV:checked-in version of that version-controlled resource is a merge source.
Clemm, et al. Standards Track [Page 71] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 71] RFC 3253 Versioning Extensions to WebDAV March 2002
- If DAV:source identifies a collection, the DAV:checked-in version
of each version-controlled resource that is a member of that
collection is a merge source.
- If DAV:source identifies a collection, the DAV:checked-in version of each version-controlled resource that is a member of that collection is a merge source.
The request-URL identifies the set of possible merge targets. If the request-URL identifies a collection, any member of the configuration rooted at the request-URL is a possible merge target. The merge target of a particular merge source is the version-controlled or checked-out resource whose DAV:checked-in or DAV:checked-out version is from the same version history as the merge source. If a merge source has no merge target, that merge source is ignored.
The request-URL identifies the set of possible merge targets. If the request-URL identifies a collection, any member of the configuration rooted at the request-URL is a possible merge target. The merge target of a particular merge source is the version-controlled or checked-out resource whose DAV:checked-in or DAV:checked-out version is from the same version history as the merge source. If a merge source has no merge target, that merge source is ignored.
The MERGE response identifies the resources that a client must modify to complete the merge. It also identifies the resources modified by the request, so that a client can efficiently update any cached state it is maintaining.
The MERGE response identifies the resources that a client must modify to complete the merge. It also identifies the resources modified by the request, so that a client can efficiently update any cached state it is maintaining.
Marshalling:
Marshalling:
The request body MUST be a DAV:merge element.
The request body MUST be a DAV:merge element.
The set of merge sources is determined by the DAV:source element
in the request body.
The set of merge sources is determined by the DAV:source element in the request body.
<!ELEMENT merge ANY>
ANY value: A sequence of elements with one DAV:source element, at
most one DAV:no-auto-merge element, at most one DAV:no-checkout
element, at most one DAV:prop element, and any legal set of
elements that can occur in a DAV:checkout element.
<!ELEMENT source (href+)>
<!ELEMENT no-auto-merge EMPTY>
<!ELEMENT no-checkout EMPTY>
prop: see RFC 2518, Section 12.11
<!ELEMENT merge ANY> ANY value: A sequence of elements with one DAV:source element, at most one DAV:no-auto-merge element, at most one DAV:no-checkout element, at most one DAV:prop element, and any legal set of elements that can occur in a DAV:checkout element. <!ELEMENT source (href+)> <!ELEMENT no-auto-merge EMPTY> <!ELEMENT no-checkout EMPTY> prop: see RFC 2518, Section 12.11
The response for a successful request MUST be a 207 Multi-Status,
where the DAV:multistatus XML element in the response body
identifies all resources that have been modified by the request.
The response for a successful request MUST be a 207 Multi-Status, where the DAV:multistatus XML element in the response body identifies all resources that have been modified by the request.
multistatus: see RFC 2518, Section 12.9
multistatus: see RFC 2518, Section 12.9
The response to a successful request MUST include a Location
header containing the URL for the new version created by the
checkin.
The response to a successful request MUST include a Location header containing the URL for the new version created by the checkin.
The response MUST include a Cache-Control:no-cache header.
The response MUST include a Cache-Control:no-cache header.
Clemm, et al. Standards Track [Page 72] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 72] RFC 3253 Versioning Extensions to WebDAV March 2002
Preconditions:
Preconditions:
(DAV:cannot-merge-checked-out-resource): The DAV:source element
MUST NOT identify a checked-out resource. If the DAV:source
element identifies a collection, the collection MUST NOT have a
member that is a checked-out resource.
(DAV:cannot-merge-checked-out-resource): The DAV:source element MUST NOT identify a checked-out resource. If the DAV:source element identifies a collection, the collection MUST NOT have a member that is a checked-out resource.
(DAV:checkout-not-allowed): If DAV:no-checkout is specified in the
request body, it MUST be possible to perform the merge without
checking out any of the merge targets.
(DAV:checkout-not-allowed): If DAV:no-checkout is specified in the request body, it MUST be possible to perform the merge without checking out any of the merge targets.
All preconditions of the CHECKOUT operation apply to the checkouts
performed by the request.
All preconditions of the CHECKOUT operation apply to the checkouts performed by the request.
Postconditions:
Postconditions:
(DAV:ancestor-version): If a merge target is a version-controlled
or checked-out resource whose DAV:checked-in version or
DAV:checked-out version is the merge source or is a descendant of
the merge source, the merge target MUST NOT have been modified by
the MERGE.
(DAV:ancestor-version): If a merge target is a version-controlled or checked-out resource whose DAV:checked-in version or DAV:checked-out version is the merge source or is a descendant of the merge source, the merge target MUST NOT have been modified by the MERGE.
(DAV:descendant-version): If the merge target was a checked-in
version-controlled resource whose DAV:checked-in version was an
ancestor of the merge source, an UPDATE operation MUST have been
applied to the merge target to set its content and dead properties
to be those of the merge source. If the UPDATE method is not
supported, the merge target MUST have been checked out, the
content and dead properties of the merge target MUST have been set
to those of the merge source, and the merge source MUST have been
added to the DAV:auto-merge-set of the merge target. The merge
target MUST appear in a DAV:response XML element in the response
body.
(DAV:descendant-version): If the merge target was a checked-in version-controlled resource whose DAV:checked-in version was an ancestor of the merge source, an UPDATE operation MUST have been applied to the merge target to set its content and dead properties to be those of the merge source. If the UPDATE method is not supported, the merge target MUST have been checked out, the content and dead properties of the merge target MUST have been set to those of the merge source, and the merge source MUST have been added to the DAV:auto-merge-set of the merge target. The merge target MUST appear in a DAV:response XML element in the response body.
(DAV:checked-out-for-merge): If the merge target was a checked-in
version-controlled resource whose DAV:checked-in version was
neither a descendant nor an ancestor of the merge source, a
CHECKOUT MUST have been applied to the merge target. All XML
elements in the DAV:merge XML element that could appear in a
DAV:checkout XML element MUST have been used as arguments to the
CHECKOUT request. The merge target MUST appear in a DAV:response
XML element in the response body.
(DAV:checked-out-for-merge): If the merge target was a checked-in version-controlled resource whose DAV:checked-in version was neither a descendant nor an ancestor of the merge source, a CHECKOUT MUST have been applied to the merge target. All XML elements in the DAV:merge XML element that could appear in a DAV:checkout XML element MUST have been used as arguments to the CHECKOUT request. The merge target MUST appear in a DAV:response XML element in the response body.
(DAV:update-merge-set): If the DAV:checked-out version of the
merge target is neither equal to nor a descendant of the merge
source, the merge source MUST be added to either the DAV:merge-set
or the DAV:auto-merge-set of the merge target. The merge target
MUST appear in a DAV:response XML element in the response body.
(DAV:update-merge-set): If the DAV:checked-out version of the merge target is neither equal to nor a descendant of the merge source, the merge source MUST be added to either the DAV:merge-set or the DAV:auto-merge-set of the merge target. The merge target MUST appear in a DAV:response XML element in the response body.
Clemm, et al. Standards Track [Page 73] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 73] RFC 3253 Versioning Extensions to WebDAV March 2002
If a merge source has been added to the DAV:auto-merge-set, the
content and dead properties of the merge target MUST have been
modified by the server to reflect the result of a logical merge of
the merge source and the merge target. If a merge source has been
added to the DAV:merge-set, the content and dead properties of the
merge target MUST NOT have been modified by the server. If
DAV:no-auto-merge is specified in the request body, the merge
source MUST NOT have been added to the DAV:auto-merge-set.
If a merge source has been added to the DAV:auto-merge-set, the content and dead properties of the merge target MUST have been modified by the server to reflect the result of a logical merge of the merge source and the merge target. If a merge source has been added to the DAV:merge-set, the content and dead properties of the merge target MUST NOT have been modified by the server. If DAV:no-auto-merge is specified in the request body, the merge source MUST NOT have been added to the DAV:auto-merge-set.
(DAV:report-properties): If DAV:prop is specified in the request
body, the properties specified in the DAV:prop element MUST be
reported in the DAV:response elements in the response body.
(DAV:report-properties): If DAV:prop is specified in the request body, the properties specified in the DAV:prop element MUST be reported in the DAV:response elements in the response body.
11.2.1 Example - MERGE
11.2.1 Example - MERGE
>>REQUEST
>>REQUEST
MERGE /ws/public HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
MERGE /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:merge xmlns:D="DAV:">
<D:source>
<D:href>http://www.webdav.org/ws/dev/sally</D:href>
</D:source>
</D:merge>
<?xml version="1.0" encoding="utf-8" ?> <D:merge xmlns:D="DAV:"> <D:source> <D:href>http://www.webdav.org/ws/dev/sally</D:href> </D:source> </D:merge>
>>RESPONSE
>>RESPONSE
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
Cache-Control: no-cache
HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Cache-Control: no-cache
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.webdav.org/ws/public/src/parse.c</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.webdav.org/ws/public/doc/parse.html</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
<?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>http://www.webdav.org/ws/public/src/parse.c</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> <D:response> <D:href>http://www.webdav.org/ws/public/doc/parse.html</D:href> <D:status>HTTP/1.1 200 OK</D:status> </D:response> </D:multistatus>
Clemm, et al. Standards Track [Page 74] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 74] RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the DAV:checked-in versions from the workspace http://www.webdav.org/ws/dev/sally are merged into the version- controlled resources in the workspace http://www.webdav.org/ws/public. The resources /ws/public/src/parse.c and /ws/public/doc/parse.html were modified by the request.
In this example, the DAV:checked-in versions from the workspace http://www.webdav.org/ws/dev/sally are merged into the version- controlled resources in the workspace http://www.webdav.org/ws/public. The resources /ws/public/src/parse.c and /ws/public/doc/parse.html were modified by the request.
11.3 DAV:merge-preview Report
11.3 DAV:merge-preview Report
A merge preview describes the changes that would result if the versions specified by the DAV:source element in the request body were to be merged into the resource identified by the request-URL (commonly, a collection).
A merge preview describes the changes that would result if the versions specified by the DAV:source element in the request body were to be merged into the resource identified by the request-URL (commonly, a collection).
Marshalling:
Marshalling:
The request body MUST be a DAV:merge-preview XML element.
The request body MUST be a DAV:merge-preview XML element.
<!ELEMENT merge-preview (source)>
<!ELEMENT source (href)>
<!ELEMENT merge-preview (source)> <!ELEMENT source (href)>
The response body for a successful request MUST be a
DAV:merge-preview-report XML element.
The response body for a successful request MUST be a DAV:merge-preview-report XML element.
<!ELEMENT merge-preview-report
(update-preview | conflict-preview | ignore-preview)*>
<!ELEMENT merge-preview-report (update-preview | conflict-preview | ignore-preview)*>
A DAV:update-preview element identifies a merge target whose
DAV:checked-in property would change as a result of the MERGE, and
identifies the merge source for that merge target.
A DAV:update-preview element identifies a merge target whose DAV:checked-in property would change as a result of the MERGE, and identifies the merge source for that merge target.
<!ELEMENT update-preview (target, version)>
<!ELEMENT target (href)>
<!ELEMENT version (href)>
<!ELEMENT update-preview (target, version)> <!ELEMENT target (href)> <!ELEMENT version (href)>
A DAV:conflict-preview element identifies a merge target that
requires a merge.
A DAV:conflict-preview element identifies a merge target that requires a merge.
<!ELEMENT conflict-preview (target, common-ancestor, version)>
<!ELEMENT conflict-preview (target, common-ancestor, version)>
A DAV:common-ancestor element identifies the version that is a
common ancestor of both the merge source and the DAV:checked-in or
DAV:checked-out version of the merge target.
A DAV:common-ancestor element identifies the version that is a common ancestor of both the merge source and the DAV:checked-in or DAV:checked-out version of the merge target.
<!ELEMENT common-ancestor (href)>
<!ELEMENT common-ancestor (href)>
A DAV:ignore-preview element identifies a version that has no
merge target and therefore would be ignored by the merge.
A DAV:ignore-preview element identifies a version that has no merge target and therefore would be ignored by the merge.
Clemm, et al. Standards Track [Page 75] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 75] RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT ignore-preview (version)>
<!ELEMENT ignore-preview (version)>
11.3.1 Example - DAV:merge-preview Report
11.3.1 Example - DAV:merge-preview Report
>>REQUEST
>>REQUEST
REPORT /ws/public HTTP/1.1
Host: www.webdav.org
Content-type: text/xml; charset="utf-8"
Content-Length: xxxx
REPORT /ws/public HTTP/1.1 Host: www.webdav.org Content-type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:merge-preview xmlns:D="DAV:">
<D:source>
<D:href>http://www.webdav.org/ws/dev/fred</D:href>
</D:source>
</D:merge-preview>
<?xml version="1.0" encoding="utf-8" ?> <D:merge-preview xmlns:D="DAV:"> <D:source> <D:href>http://www.webdav.org/ws/dev/fred</D:href> </D:source> </D:merge-preview>
>>RESPONSE
>>RESPONSE
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:merge-preview-report xmlns:D="DAV:">
<D:conflict-preview>
<D:target>
<D:href>http://www.webdav.org/ws/public/foo.html</D:href>
</D:target>
<D:common-ancestor>
<D:href>http://repo.webdav.org/his/23/ver/18</D:href>
</D:common-ancestor>
<D:version>
<D:href>http://repo.webdav.org/his/23/ver/42</D:href>
</D:version>
</D:conflict-preview>
<D:update-preview>
<D:target>
<D:href>http://www.webdav.org/ws/public/bar.html</D:href>
</D:target>
<D:version>
<D:href>http://www.repo/his/42/ver/3</D:href>
</D:version>
</D:update-preview>
</D:merge-preview-report>
<?xml version="1.0" encoding="utf-8" ?> <D:merge-preview-report xmlns:D="DAV:"> <D:conflict-preview> <D:target> <D:href>http://www.webdav.org/ws/public/foo.html</D:href> </D:target> <D:common-ancestor> <D:href>http://repo.webdav.org/his/23/ver/18</D:href> </D:common-ancestor> <D:version> <D:href>http://repo.webdav.org/his/23/ver/42</D:href> </D:version> </D:conflict-preview> <D:update-preview> <D:target> <D:href>http://www.webdav.org/ws/public/bar.html</D:href> </D:target> <D:version> <D:href>http://www.repo/his/42/ver/3</D:href> </D:version> </D:update-preview> </D:merge-preview-report>
Clemm, et al. Standards Track [Page 76] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 76] RFC 3253 Versioning Extensions to WebDAV March 2002
In this example, the merge preview report indicates that version /his/23/ver/42 would be merged in /ws/public/foo.html, and version /his/42/ver/3 would update /ws/public/bar.html if the workspace http://www.webdav.org/ws/dev/fred was merged into the workspace http://www.webdav.org/ws/public.
In this example, the merge preview report indicates that version /his/23/ver/42 would be merged in /ws/public/foo.html, and version /his/42/ver/3 would update /ws/public/bar.html if the workspace http://www.webdav.org/ws/dev/fred was merged into the workspace http://www.webdav.org/ws/public.
11.4 Additional OPTIONS Semantics
11.4 Additional OPTIONS Semantics
If the server supports the merge feature, it MUST include "merge" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
If the server supports the merge feature, it MUST include "merge" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
11.5 Additional DELETE Semantics
11.5 Additional DELETE Semantics
Additional Postconditions:
Additional Postconditions:
(DAV:delete-version-reference): If a version is deleted, any
reference to that version in a DAV:merge-set or DAV:auto-merge-set
property MUST be removed.
(DAV:delete-version-reference): If a version is deleted, any reference to that version in a DAV:merge-set or DAV:auto-merge-set property MUST be removed.
11.6 Additional CHECKIN Semantics
11.6 Additional CHECKIN Semantics
Additional Preconditions:
Additional Preconditions:
(DAV:merge-must-be-complete): The DAV:merge-set and DAV:auto-
merge-set of the checked-out resource MUST be empty or not exist.
(DAV:merge-must-be-complete): The DAV:merge-set and DAV:auto- merge-set of the checked-out resource MUST be empty or not exist.
12 Baseline Feature
12 Baseline Feature
A configuration is a set of resources that consists of a root collection and all members of that root collection except those resources that are members of another configuration. A configuration that contains a large number of resources can consume a large amount of space on a server. This can make it prohibitively expensive to remember the state of an existing configuration by creating a Depth:infinity copy of its root collection.
A configuration is a set of resources that consists of a root collection and all members of that root collection except those resources that are members of another configuration. A configuration that contains a large number of resources can consume a large amount of space on a server. This can make it prohibitively expensive to remember the state of an existing configuration by creating a Depth:infinity copy of its root collection.
A baseline is a version resource that captures the state of each version-controlled member of a configuration. A baseline history is a version history whose versions are baselines. New baselines are created by checking out and then checking in a special kind of version-controlled resource called a version-controlled configuration.
A baseline is a version resource that captures the state of each version-controlled member of a configuration. A baseline history is a version history whose versions are baselines. New baselines are created by checking out and then checking in a special kind of version-controlled resource called a version-controlled configuration.
A collection that is under baseline control is called a baseline- controlled collection. In order to allow efficient baseline implementation, the state of a baseline of a collection is limited to
A collection that is under baseline control is called a baseline- controlled collection. In order to allow efficient baseline implementation, the state of a baseline of a collection is limited to
Clemm, et al. Standards Track [Page 77] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 77] RFC 3253 Versioning Extensions to WebDAV March 2002
be a set of versions and their names relative to the collection, and the operations on a baseline are limited to the creation of a baseline from a collection, and restoring or merging the baseline back into a collection. A server MAY automatically put a collection under baseline control when it is created, or a client can use the BASELINE-CONTROL method to put a specified collection under baseline control.
be a set of versions and their names relative to the collection, and the operations on a baseline are limited to the creation of a baseline from a collection, and restoring or merging the baseline back into a collection. A server MAY automatically put a collection under baseline control when it is created, or a client can use the BASELINE-CONTROL method to put a specified collection under baseline control.
As a configuration gets large, it is often useful to break it up into a set of smaller configurations that form the logical "components" of that configuration. In order to capture the fact that a baseline of a configuration is logically extended by a component configuration baseline, the component configuration baseline is captured as a "subbaseline" of the baseline.
As a configuration gets large, it is often useful to break it up into a set of smaller configurations that form the logical "components" of that configuration. In order to capture the fact that a baseline of a configuration is logically extended by a component configuration baseline, the component configuration baseline is captured as a "subbaseline" of the baseline.
The root collection of a configuration is unconstrained with respect to its relationship to the root collection of any of its components. In particular, the root collection of a configuration can have a member that is the root collection of one of its components (e.g., configuration /sys/x can have a component /sys/x/foo), can be a member of the root collection of one of its components (e.g., configuration /sys/y/z can have a component /sys/y), or neither (e.g., configuration /sys/x can have a component /comp/bar).
The root collection of a configuration is unconstrained with respect to its relationship to the root collection of any of its components. In particular, the root collection of a configuration can have a member that is the root collection of one of its components (e.g., configuration /sys/x can have a component /sys/x/foo), can be a member of the root collection of one of its components (e.g., configuration /sys/y/z can have a component /sys/y), or neither (e.g., configuration /sys/x can have a component /comp/bar).
12.1 Version-Controlled Configuration Properties
12.1 Version-Controlled Configuration Properties
Since a version-controlled configuration is a version-controlled resource, it has all the properties of a version-controlled resource. In addition, the baseline feature introduces the following REQUIRED property for a version-controlled configuration.
Since a version-controlled configuration is a version-controlled resource, it has all the properties of a version-controlled resource. In addition, the baseline feature introduces the following REQUIRED property for a version-controlled configuration.
12.1.1 DAV:baseline-controlled-collection (protected)
12.1.1 DAV:baseline-controlled-collection (protected)
This property identifies the collection that contains the version- controlled resources whose DAV:checked-in versions are being tracked by this version-controlled configuration. The DAV:version- controlled-configuration of the DAV:baseline-controlled-collection of a version-controlled configuration MUST identify that version- controlled configuration.
This property identifies the collection that contains the version- controlled resources whose DAV:checked-in versions are being tracked by this version-controlled configuration. The DAV:version- controlled-configuration of the DAV:baseline-controlled-collection of a version-controlled configuration MUST identify that version- controlled configuration.
<!ELEMENT baseline-controlled-collection (href)>
<!ELEMENT baseline-controlled-collection (href)>
12.2 Checked-Out Configuration Properties
12.2 Checked-Out Configuration Properties
Since a checked-out configuration is a checked-out resource, it has all the properties of a checked-out resource. In addition, the baseline feature introduces the following REQUIRED property for a checked-out configuration.
Since a checked-out configuration is a checked-out resource, it has all the properties of a checked-out resource. In addition, the baseline feature introduces the following REQUIRED property for a checked-out configuration.
Clemm, et al. Standards Track [Page 78] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 78] RFC 3253 Versioning Extensions to WebDAV March 2002
12.2.1 DAV:subbaseline-set
12.2.1 DAV:subbaseline-set
This property determines the DAV:subbaseline-set property of the baseline that results from checking in this resource.
This property determines the DAV:subbaseline-set property of the baseline that results from checking in this resource.
A server MAY reject attempts to modify the DAV:subbaseline-set of a checked-out configuration.
A server MAY reject attempts to modify the DAV:subbaseline-set of a checked-out configuration.
<!ELEMENT subbaseline-set (href*)>
<!ELEMENT subbaseline-set (href*)>
12.3 Baseline Properties
12.3 Baseline Properties
The DAV:resourcetype of a baseline MUST be DAV:baseline. Since a baseline is a version resource, it has all the properties of a version resource. In addition, the baseline feature introduces the following REQUIRED properties for a baseline.
The DAV:resourcetype of a baseline MUST be DAV:baseline. Since a baseline is a version resource, it has all the properties of a version resource. In addition, the baseline feature introduces the following REQUIRED properties for a baseline.
12.3.1 DAV:baseline-collection (protected)
12.3.1 DAV:baseline-collection (protected)
This property contains a server-defined URL for a collection, where each member of this collection MUST either be a version-controlled resource with the same DAV:checked-in version and relative name as a version-controlled member of the baseline-controlled collection at the time the baseline was created, or be a collection needed to provide the relative name for a version-controlled resource.
This property contains a server-defined URL for a collection, where each member of this collection MUST either be a version-controlled resource with the same DAV:checked-in version and relative name as a version-controlled member of the baseline-controlled collection at the time the baseline was created, or be a collection needed to provide the relative name for a version-controlled resource.
<!ELEMENT baseline-collection (href)>
<!ELEMENT baseline-collection (href)>
12.3.2 DAV:subbaseline-set (protected)
12.3.2 DAV:subbaseline-set (protected)
The URLs in the DAV:subbaseline-set property MUST identify a set of other baselines. The subbaselines of a baseline are the baselines identified by its DAV:subbaseline-set and all subbaselines of the baselines identified by its DAV:subbaseline-set.
The URLs in the DAV:subbaseline-set property MUST identify a set of other baselines. The subbaselines of a baseline are the baselines identified by its DAV:subbaseline-set and all subbaselines of the baselines identified by its DAV:subbaseline-set.
<!ELEMENT subbaseline-set (href*)>
<!ELEMENT subbaseline-set (href*)>
12.4 Additional Resource Properties
12.4 Additional Resource Properties
The baseline feature introduces the following REQUIRED property for a resource.
The baseline feature introduces the following REQUIRED property for a resource.
12.4.1 DAV:version-controlled-configuration (computed)
12.4.1 DAV:version-controlled-configuration (computed)
If the resource is a member of a version-controlled configuration (i.e. the resource is a collection under baseline control or is a member of a collection under baseline control), this property identifies that version-controlled configuration.
If the resource is a member of a version-controlled configuration (i.e. the resource is a collection under baseline control or is a member of a collection under baseline control), this property identifies that version-controlled configuration.
Clemm, et al. Standards Track [Page 79] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 79] RFC 3253 Versioning Extensions to WebDAV March 2002
<!ELEMENT version-controlled-configuration (href)>
<!ELEMENT version-controlled-configuration (href)>
12.5 Additional Workspace Properties
12.5 Additional Workspace Properties
The baseline feature introduces the following REQUIRED property for a workspace.
The baseline feature introduces the following REQUIRED property for a workspace.
12.5.1 DAV:baseline-controlled-collection-set (computed)
12.5.1 DAV:baseline-controlled-collection-set (computed)
This property identifies each member of the workspace that is a collection under baseline control (as well as the workspace itself, if it is under baseline control).
This property identifies each member of the workspace that is a collection under baseline control (as well as the workspace itself, if it is under baseline control).
<!ELEMENT baseline-controlled-collection-set (href*)>
<!ELEMENT baseline-controlled-collection-set (href*)>
12.6 BASELINE-CONTROL Method
12.6 BASELINE-CONTROL Method
A collection can be placed under baseline control with a BASELINE-CONTROL request. When a collection is placed under baseline control, the DAV:version-controlled-configuration property of the collection is set to identify a new version-controlled configuration. This version-controlled configuration can be checked out and then checked in to create a new baseline for that collection.
A collection can be placed under baseline control with a BASELINE-CONTROL request. When a collection is placed under baseline control, the DAV:version-controlled-configuration property of the collection is set to identify a new version-controlled configuration. This version-controlled configuration can be checked out and then checked in to create a new baseline for that collection.
If a baseline is specified in the request body, the DAV:checked-in version of the new version-controlled configuration will be that baseline, and the collection is initialized to contain version- controlled members whose DAV:checked-in versions and relative names are determined by the specified baseline.
If a baseline is specified in the request body, the DAV:checked-in version of the new version-controlled configuration will be that baseline, and the collection is initialized to contain version- controlled members whose DAV:checked-in versions and relative names are determined by the specified baseline.
If no baseline is specified, a new baseline history is created containing a baseline that captures the state of the version- controlled members of the collection, and the DAV:checked-in version of the version-controlled configuration will be that baseline.
基線が全く指定されないなら、収集のバージョンの制御メンバーの状態、およびDAVを得る基線を含んでいて、新しい基線歴史は引き起こされます: バージョンで制御された構成の預けているバージョンはその基線になるでしょう。
Marshalling:
整理します:
If a request body is included, it MUST be a DAV:baseline-control
XML element.
要求本体が含まれているなら、それはDAVであるに違いありません: 基線コントロールXML要素。
<!ELEMENT baseline-control ANY>
ANY value: A sequence of elements with at most one DAV:baseline
element.
どんな>も少しも評価する<!ELEMENT基線コントロール: 高々1DAVがある要素の系列: 基線要素。
<!ELEMENT baseline (href)>
<!ELEMENT基線(href)>。
If a response body for a successful request is included, it MUST
be a DAV:baseline-control-response XML element.
うまくいっている要求のための応答本体が含まれているなら、それはDAVであるに違いありません: 基線操舵応答XML要素。
Clemm, et al. Standards Track [Page 80] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[80ページ]。
<!ELEMENT baseline-control-response ANY>
基線応答を制御している<!ELEMENTいずれも>。
The response MUST include a Cache-Control:no-cache header.
応答はCache-コントロールを含まなければなりません: キャッシュがないヘッダー。
Preconditions:
前提条件:
(DAV:version-controlled-configuration-must-not-exist): The
DAV:version-controlled-configuration property of the collection
identified by the request-URL MUST not exist.
(DAV:、バージョンの制御構成が存在してはいけない、)、: DAV: 要求URLによって特定された収集のバージョンの制御構成の特性は存在してはいけません。
(DAV:must-be-baseline): The DAV:href of the DAV:baseline element
in the request body MUST identify a baseline.
(DAV:、基線でなければならない、)、: DAV: DAVのhref: 要求本体の基線要素は基線を特定しなければなりません。
(DAV:must-have-no-version-controlled-members): If a DAV:baseline
element is specified in the request body, the collection
identified by the request-URL MUST have no version-controlled
members.
(DAV:、絶対に必要なもの、どんなバージョンもメンバーを監督しなかった、)、: DAV: 基線要素が要求本体で指定されるなら、要求URLによって特定された収集がバージョンで制御されたメンバーが全くいてはいけません。
(DAV:one-baseline-controlled-collection-per-history-per-
workspace): If the request-URL identifies a workspace or a member
of a workspace, and if a baseline is specified in a DAV:baseline
element in the request body, then there MUST NOT be another
collection in that workspace whose DAV:version-controlled-
configuration property identifies a version-controlled
configuration for the baseline history of that baseline.
(DAV:、1歴史あたりの1基線で制御された収集、1ワークスペースあたり)、: 要求URLがワークスペースかワークスペースのメンバーを特定して、基線がDAV: 要求本体の基線要素で指定されるなら、そのワークスペースでの別の収集がDAVであったならそこのその時は指定されてはいけません: バージョンで制御された構成している特性はその基線の基線歴史のためのバージョンで制御された構成を特定します。
Postconditions:
Postconditions:
(DAV:create-version-controlled-configuration): A new version-
controlled configuration is created, whose DAV:baseline-
controlled-collection property identifies the collection.
(DAV: バージョンの制御構成を作成してください): DAV、新しいバージョン制御構成は作成されます: 基線制御収集の特性は収集を特定します。
(DAV:reference-version-controlled-configuration): The
DAV:version-controlled-configuration of the collection identifies
the new version-controlled configuration.
(DAV: 参照のバージョンの制御構成): DAV: 収集のバージョンの制御構成は新しいバージョンで制御された構成を特定します。
(DAV:select-existing-baseline): If the request body specifies a
baseline, the DAV:checked-in property of the new version-
controlled configuration MUST have been set to identify this
baseline. A version-controlled member of the collection will be
created for each version in the baseline, where the version-
controlled member will have the content and dead properties of
that version, and will have the same name relative to the
collection as the corresponding version-controlled resource had
when the baseline was created. Any nested collections that are
needed to provide the appropriate name for a version-controlled
member will be created.
(DAV: 選んだ既存の基線): 要求本体が基線を指定するなら、DAV: 新しいバージョン制御構成の預けている特性がこの基線を特定するように設定されたに違いありません。 収集のバージョンで制御されたメンバーは、バージョンの制御メンバーがそのバージョンの満足していて死んでいる特性を持つ基線の各バージョンのために作成されて、基線が作成されたとき、対応するバージョンで制御されたリソースが持っていたように収集に比例して同じ名前を持つでしょう。 バージョンで制御されたメンバーに適切な名前を提供するのに必要であるどんな入れ子にされた収集も作成されるでしょう。
Clemm, et al. Standards Track [Page 81] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[81ページ]。
(DAV:create-new-baseline): If no baseline is specified in the
request body, the request MUST have created a new baseline history
at a server-defined URL, and MUST have created a new baseline in
that baseline history. The DAV:baseline-collection of the new
baseline MUST identify a collection whose members have the same
relative name and DAV:checked-in version as the version-controlled
members of the request collection. The DAV:checked-in property of
the new version-controlled configuration MUST identify the new
baseline.
(基線を新しく作成しているDAV): 基線が全く要求本体で指定されないなら、要求は、サーバで定義されたURLで新しい基線歴史を引き起こしたに違いなくて、その基線歴史で新しい基線を作成したに違いありません。 DAV: 新しい基線の基線収集はメンバーが同じ相対的な名前とDAVを持っている収集を特定しなければなりません: 要求収集のバージョンで制御されたメンバーとしてバージョンを預けます。 DAV: 新しいバージョンで制御された構成の預けている特性は新しい基線を特定しなければなりません。
12.6.1 Example - BASELINE-CONTROL
12.6.1 基線例--コントロール
>>REQUEST
>>要求
BASELINE-CONTROL /src HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
基線コントロール/src HTTP/1.1ホスト: www.webdav.orgコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:baseline-control xmlns:D="DAV:">
<D:href>http://www.webdav.org/repo/blh/13/ver/8</D:href>
</D:baseline-control>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 基線コントロールxmlns: Dが等しい、「DAV: 「><D: href>http://www.webdav.org/repo/blh/13/ver/8</D: href></D: 基線コントロール>」
>>RESPONSE
>>応答
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 0
HTTP/1.1 200はキャッシュ制御を承認します: Content-長さをキャッシュしないでください: 0
Clemm, et al. Standards Track [Page 82] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[82ページ]。
In this example, the collection /src is placed under baseline control, and is populated with members from an existing baseline. A new version-controlled configuration (/repo/vcc/128) is created and associated with /src, and /src is initialized with version-controlled members whose DAV:checked-in versions are those selected by the DAV:baseline-collection (/repo/bc/15) of the specified baseline (/repo/blh/13/ver/8). The following diagram illustrates the resulting state on the server.
この例では、収集/srcは基線コントロールの下で置かれて、メンバーと共に既存の基線から居住されます。 新しいバージョンで制御された構成(/repo/vcc/128)は、/srcに作成されて、関連づけられます、そして、/srcによるバージョンで制御されたメンバーと共に初期化されて、DAV: 預けているバージョンはDAVによって選択されたものです: 指定された基線(/repo/blh/13/ver/8)の基線収集(/repo/bc/15)ということです。 以下のダイヤグラムはサーバの結果として起こる状態を例証します。
+-------------------------------------+
|Baseline-Controlled Collection |<------+
|/src | |
|-------------------------------------| |
|DAV:version-controlled-configuration +---+ |
+-------------------------------------+ | |
| |
| |
+-------------------------------------+ | |
|Version-Controlled Configuration |<--+ |
|/repo/vcc/128 | |
|-------------------------------------| |
|DAV:baseline-controlled-collection +-------+
|-------------------------------------|
|DAV:checked-in +-------+
+-------------------------------------+ |
|DAV:version-history +---+ |
+-------------------------------------+ | |
| |
| |
+------------------------+ | |
|Baseline History |<---------------+ |
|/repo/blh/13 | |
|------------------------+ |
|DAV:version-set +----------------+ |
+------------------------+ | | | | |
v | v v |
| |
+------------------------+ | |
|Baseline |<-------+-----------+
|/repo/blh/13/ver/8 |
|------------------------+ +--------------+
|DAV:baseline-collection +---->|Collection |
+------------------------+ |/repo/bc/15 |
+--------------+
+-------------------------------------+ |基線で制御された収集| <、-、-、-、-、--+ |/src| | |-------------------------------------| | |DAV: バージョンの制御構成+---+ | +-------------------------------------+ | | | | | | +-------------------------------------+ | | |バージョンで制御された構成| <--+ | |/repo/vcc/128| | |-------------------------------------| | |DAV: 基線の制御収集+-------+ |-------------------------------------| |DAV: チェックのコネ+-------+ +-------------------------------------+ | |DAV: バージョン歴史+---+ | +-------------------------------------+ | | | | | | +------------------------+ | | |基線歴史| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | |/repo/blh/13| | |------------------------+ | |DAV: バージョンセット+----------------+ | +------------------------+ | | | | | v| vに対して| | | +------------------------+ | | |基線| <、-、-、-、-、-、--+-----------+ |/repo/blh/13/ver/8| |------------------------+ +--------------+ |DAV: 基線収集+---->|収集| +------------------------+ |/repo/bc/15| +--------------+
Clemm, et al. Standards Track [Page 83] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[83ページ]。
In order to create new baselines of /src, /repo/vcc/128 can be checked out, new versions can be created or selected by the version- controlled members of /src, and then /repo/vcc/128 can be checked in to capture the current state of those version-controlled members.
/srcの新しい基線を作成するために、/repo/vcc/128を調べることができます、そして、/srcのバージョンの制御メンバーは、新しいバージョンを作成するか、または選択できます、そして、次に、それらのバージョンで制御されたメンバーの現状を得るために/repo/vcc/128を預けることができます。
12.7 DAV:compare-baseline Report
12.7DAV: 基線を比較しているレポート
A DAV:compare-baseline report contains the differences between the baseline identified by the request-URL (the "request baseline") and the baseline specified in the request body (the "compare baseline").
DAV: 基線を比較しているレポートが要求URL(「要求基線」)によって特定された基線と要求本体で指定された基線の違いを含んでいる、(「基線を比較してください」)
Marshalling:
整理します:
The request body MUST be a DAV:compare-baseline XML element.
要求本体はDAVであるに違いありません: 基線を比較しているXML要素。
<!ELEMENT compare-baseline (href)>
<!ELEMENT、基線を比較します。(href)>。
The response body for a successful request MUST be a DAV:compare-
baseline-report XML element.
うまくいっている要求のための応答本体はDAVであるに違いありません: 基線レポートXML要素を比較してください。
<!ELEMENT compare-baseline-report
(added-version | deleted-version | changed-version)*>
基線レポートを比較している(加えられたバージョン| 削除されたバージョン| 変えられたバージョン)<!ELEMENT*>。
A DAV:added-version element identifies a version that is the
DAV:checked-in version of a member of the DAV:baseline-collection
of the compare baseline, but no version in the version history of
that version is the DAV:checked-in version of a member of the
DAV:baseline-collection of the request baseline.
DAV: 加えられたバージョン要素がDAVであるバージョン: DAV: 基線収集のメンバーのチェックのコネのバージョンを特定する、そのバージョンのバージョン歴史でどんなバージョンもDAVではありません: 基線を比較しなさい、ただし、DAV: 要求基線の基線収集のメンバーのチェックのコネのバージョン。
<!ELEMENT added-version (href)>
<!のELEMENTの加えられたバージョン(href)>。
A DAV:deleted-version element identifies a version that is the
DAV:checked-in version of a member of the DAV:baseline-collection
of the request baseline, but no version in the version history of
that version is the DAV:checked-in version of a member of the
DAV:baseline-collection of the compare baseline.
DAV: 削除されたバージョン要素がDAV: DAV: そのバージョンのバージョン歴史における、要求基線にもかかわらず、バージョンがない基線収集のメンバーのチェックのコネのバージョンはDAVです: DAV: 基線収集のメンバーのバージョンを預けるということであるバージョンを特定する、基線を比較してください。
<!ELEMENT deleted-version (href)>
<!のELEMENTの削除されたバージョン(href)>。
A DAV:changed-version element identifies two different versions
from the same version history that are the DAV:checked-in version
of the DAV:baseline-collection of the request baseline and the
compare baseline, respectively.
そして、DAV: 変えられたバージョン要素は同じバージョン歴史からのDAVである2つの異なった見解を特定します: DAV: 要求基線の基線収集のバージョンを預ける、それぞれ基線を比較してください。
<!ELEMENT changed-version (href, href)>
<!のELEMENTの変えられたバージョン(href、href)>。
Clemm, et al. Standards Track [Page 84] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[84ページ]。
Preconditions:
前提条件:
(DAV:must-be-baseline): The DAV:href in the request body MUST
identify a baseline.
(DAV:、基線でなければならない、)、: DAV: 要求本体のhrefは基線を特定しなければなりません。
(DAV:baselines-from-same-history): A server MAY require that the
baselines being compared be from the same baseline history.
(DAV: 同じ歴史からの基線): サーバは、比較される基線が同じ基線歴史からのそうであることを必要とするかもしれません。
12.7.1 Example - DAV:compare-baseline Report
12.7.1 例--DAV: 基線を比較しているレポート
>>REQUEST
>>要求
REPORT /bl-his/12/bl/14 HTTP/1.1
Host: repo.webdav.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
彼のものをレポート/blしている/12/bl/14HTTP/1.1ホスト: repo.webdav.comコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:compare-baseline xmlns:D="DAV:">
<D:href>http://repo.webdav.org/bl-his/12/bl/15</D:href>
</D:compare-baseline>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 基線を比較しているxmlns: Dが等しい、「DAV:、「><D: href>http://、repo.webdav.org/bl、-、彼、/12/bl/15</D: href></D: 基線を比較している>、」
>>RESPONSE
>>応答
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200はコンテントタイプを承認します: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:compare-baseline-report xmlns:D="DAV:">
<D:added-version>
<D:href>http://repo.webdav.org/his/23/ver/8</D:href>
</D:added-version>
<D:changed-version>
<D:href>http://repo.webdav.org/his/29/ver/12</D:href>
<D:href>http://repo.webdav.org/his/29/ver/19</D:href>
</D:changed-version>
<D:deleted-version>
<D:href>http://repo.webdav.org/his/12/ver/4</D:href>
</D:deleted-version>
</D:compare-baseline-report>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: 基線レポートを比較しているxmlns: Dが等しい、「DAV: 「><D: 加えられたバージョンの><D: : href>http://repo.webdav.org/彼の/23/ver/8</D: href></D: 加えられたバージョンの><D: 変えられたバージョンの><D href>http://repo.webdav。」; 彼の/29/ver/12</D: href><D: 彼の/29/ver/19</D: href></D: 変えられたバージョンの><D: 削除されたバージョンの><D: 彼の/12/ver/4</D: href></D: 削除されたバージョンの></D: 基線レポートを比較しているorg/href>http://repo.webdav.org/href>http://repo.webdav.org/>。
In this example, the differences between baseline 14 and baseline 15 of http://repo.webdav.org/bl-his/12 are identified.
この例では、 http://repo.webdav.org/bl-his/12 の基線14と基線15の違いは特定されます。
Clemm, et al. Standards Track [Page 85] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[85ページ]。
12.8 Additional OPTIONS Semantics
12.8 追加オプション意味論
If a server supports the baseline feature, it MUST include "baseline" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
サーバが基線機能を支持するなら、それはDAV応答ヘッダの分野としてどんなversioningの特性、レポートも支持するどんなリソースに関するOPTIONS要求、または方法からも「基線」を含まなければなりません。
12.9 Additional MKCOL Semantics
12.9 追加MKCOL意味論
Additional Postconditions:
追加Postconditions:
If a server automatically puts a newly created collection under
baseline control, all postconditions for BASELINE-CONTROL apply to
the MKCOL.
サーバが自動的に新たに作成された収集を基線コントロールの下に置くなら、BASELINE-CONTROLのためのすべてのpostconditionsがMKCOLに適用されます。
12.10 Additional COPY Semantics
12.10 複本意味論
Additional Postconditions:
追加Postconditions:
If the request creates a new collection at the Destination, and a
server automatically puts a newly created collection under
baseline control, all postconditions for BASELINE-CONTROL apply to
the COPY.
要求が新しい収集をDestinationに作成して、サーバが自動的に新たに作成された収集を基線コントロールの下に置くなら、BASELINE-CONTROLのためのすべてのpostconditionsがCOPYに適用されます。
12.11 Additional CHECKOUT Semantics
12.11 追加チェックアウト意味論
Additional Preconditions:
追加前提条件:
(DAV:must-not-update-baseline-collection): If the request-URL
identifies a member of the configuration rooted at the
DAV:baseline-collection of a baseline, the request MUST fail.
(DAV:、基線収集をアップデートしているはずがない、)、: 要求URLがDAV: 基線の基線収集で根づいている構成のメンバーを特定するなら、要求は失敗しなければなりません。
12.12 Additional CHECKIN Semantics
12.12 追加チェックイン意味論
Additional Preconditions:
追加前提条件:
(DAV:no-checked-out-baseline-controlled-collection-members): If
the request-URL identifies a version-controlled configuration, all
version-controlled members of the DAV:baseline-controlled-
collection of the version-controlled configuration MUST be
checked-in.
(DAV: チェックの出かけている基線制御収集メンバーがありません): 要求URLがバージョンで制御された構成を特定するなら、DAVのすべてのバージョンで制御されたメンバー: バージョンで制御された構成の基線で制御された収集を預けなければなりません。
(DAV:one-version-per-history-per-baseline): If the request-URL
identifies a version-controlled configuration, the set of versions
selected by that version-controlled configuration MUST contain at
most one version from any version history, where a version is
selected by a version-controlled configuration if the version is
identified by the DAV:checked-in property of any member of the
(DAV: 1基線あたりの歴史あたり1つのバージョン): 要求URLはバージョンで制御された構成、バージョンで制御された構成がバージョンがDAV: どんなメンバーの預けている特性によっても特定されるならバージョンがバージョンで制御された構成によって選択されるどんなバージョン歴史からの大部分の1つのバージョンにも含まなければならない選択されたバージョンのセットを特定します。
Clemm, et al. Standards Track [Page 86] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[86ページ]。
configuration rooted at the DAV:baseline-controlled collection of
that version-controlled configuration, or is identified by the
DAV:checked-in property of any member of the configuration rooted
at the DAV:baseline-collection of any subbaseline of that
version-controlled configuration.
構成は、DAV: そのバージョンで制御された構成の基線で制御された収集に根づくか、またはDAVによって特定されます: 構成のどんなメンバーの預けている特性もDAVで捜しました: そのバージョンで制御された構成のどんな「副-基線」の基線収集。
(DAV:cannot-modify-version-controlled-configuration): If the
request-URL identifies a version-controlled member of a baseline-
controlled collection whose version-controlled configuration is
checked-in, the request MUST fail unless the DAV:auto-version
property of the version-controlled configuration will
automatically check out that version-controlled configuration when
it is modified.
(DAV:、バージョンの制御構成を変更できない、)、: 要求URLがバージョンで制御された構成が預けられる基線の制御収集のバージョンで制御されたメンバーを特定して、それが変更されているときDAV: バージョンで制御された構成の自動バージョンの特性が自動的にそのバージョンで制御された構成を調べないなら、要求は失敗しなければなりません。
Additional Postconditions:
追加Postconditions:
(DAV:create-baseline-collection): If the request-URL identifies a
version-controlled configuration, the DAV:baseline-collection of
the new baseline identifies a collection whose members have the
same relative name and DAV:checked-in version as the members of
the DAV:baseline-controlled-collection of the version-controlled
configuration at the time of the request.
(DAV: 基線収集を作成してください): 要求URLがバージョンで制御された構成を特定するなら、DAV: 新しい基線の基線収集はメンバーが同じ相対的な名前とDAVを持っている収集を特定します: 要求時点で、DAV: バージョンで制御された構成の基線の制御収集のメンバーとしてバージョンを預けます。
(DAV:modify-configuration): If the request-URL identifies a
version-controlled member of a baseline-controlled collection,
this is a modification to the version-controlled configuration of
that baseline-controlled collection, and standard auto-versioning
semantics apply.
(DAV:、構成を変更する、)、: 要求URLが基線で制御された収集のバージョンで制御されたメンバーを特定するなら、これはその基線で制御された収集のバージョンで制御された構成への変更です、そして、標準の自動versioning意味論は適用されます。
12.13 Additional UPDATE Semantics
12.13 追加アップデート意味論
Additional Preconditions:
追加前提条件:
(DAV:baseline-controlled-members-must-be-checked-in): If the
request-URL identifies a version-controlled configuration, then
all version-controlled members of the DAV:baseline-controlled-
collection of that version-controlled configuration MUST be
checked-in.
(DAV: 制御メンバーをチェックしなければならない基線): 要求URLがバージョンで制御された構成を特定するなら、DAVのすべてのバージョンで制御されたメンバー: そのバージョンで制御された構成の基線で制御された収集を預けなければなりません。
(DAV:must-not-update-baseline-collection): If the request-URL
identifies a member of the configuration rooted at the
DAV:baseline-collection of a baseline, the request MUST fail.
(DAV:、基線収集をアップデートしているはずがない、)、: 要求URLがDAV: 基線の基線収集で根づいている構成のメンバーを特定するなら、要求は失敗しなければなりません。
(DAV:cannot-modify-version-controlled-configuration): If the
request updates the DAV:checked-in property of any version-
controlled member of a baseline-controlled collection whose
version-controlled configuration is checked-in, the request MUST
(DAV:、バージョンの制御構成を変更できない、)、: 要求がDAV: 預けている特性をアップデートするなら、基線で制御された収集のどんなバージョンの制御メンバーでも、バージョンで制御された構成がだれのものであるかはチェックインされて、要求はそうしなければなりません。
Clemm, et al. Standards Track [Page 87] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[87ページ]。
fail unless the DAV:auto-version property of the version-
controlled configuration will automatically check out that
version-controlled configuration when it is modified.
それが変更されているとき、DAV: バージョンの制御構成の自動バージョンの特性が自動的にそのバージョンで制御された構成を調べないなら、失敗してください。
Additional Postconditions:
追加Postconditions:
(DAV:set-baseline-controlled-collection-members): If the request
updated the DAV:checked-in property of a version-controlled
configuration, then the version-controlled members of the
DAV:baseline-controlled-collection of that version-controlled
configuration MUST have been updated so that they have the same
relative name, content, and dead properties as the members of the
DAV:baseline-collection of the baseline. In particular:
(DAV: セットの基線の制御収集メンバー): 彼らには、同じ相対的な名前が要求がDAV: バージョンで制御された構成の預けている特性をアップデートしたならDAVのバージョンで制御されたメンバー: そのバージョンで制御された構成の基線の制御収集をアップデートしたに違いないので、あります、DAVのメンバーとしての満足していて、死んでいる特性: 基線の基線収集。 特に:
- A version-controlled member for a given version history MUST
have been deleted if there is no version-controlled member for
that version history in the DAV:baseline-collection of the
baseline.
- A version-controlled member for a given version history MUST
have been renamed if its name relative to the baseline-
controlled collection is different from that of the version-
controlled member for that version history in the
DAV:baseline-collection of the baseline.
- A new version-controlled member MUST have been created for each
member of the DAV:baseline-collection of the baseline for which
there is no corresponding version-controlled member in the
baseline-controlled collection.
- An UPDATE request MUST have been applied to each version-
controlled member for a given version history whose
DAV:checked-in version is not the same as that of the version-
controlled member for that version history in the
DAV:baseline-collection of the baseline.
- DAVのそのバージョン歴史のためのバージョンで制御されたメンバーが全くいなければ、与えられたバージョン歴史のためのバージョンで制御されたメンバーは削除されたに違いありません: 基線の基線収集。 - DAVのそのバージョン歴史において、基線の制御収集に比例した名前がバージョンの制御メンバーのものと異なるなら、与えられたバージョン歴史のためのバージョンで制御されたメンバーは改名されたに違いありません: 基線の基線収集。 - 新しいバージョンで制御されたメンバーはDAVの各メンバーのために創造されたに違いありません: 基線で制御された収集にはどんな対応するバージョンで制御されたメンバーもいない基線の基線収集。 - UPDATE要求はDAV: 預けているバージョンが同じでないDAVのそのバージョン歴史のためにバージョンについてメンバーを監督した与えられたバージョン歴史のためにそれぞれのバージョンの制御メンバーに適用されたに違いありません: 基線の基線収集。
(DAV:update-subbaselines): If the request updated a version-
controlled configuration whose DAV:baseline-controlled-collection
contains a baseline-controlled member for one of the subbaselines
of the request baseline, then the DAV:checked-in property of the
version-controlled configuration of that baseline-controlled
member MUST have been updated to be that subbaseline. If the
request updated a version-controlled configuration whose
DAV:baseline-controlled-collection is a member of a workspace that
contains a baseline-controlled member for one of the subbaselines
of the request baseline, then the DAV:checked-in property of the
version-controlled configuration of that baseline-controlled
member MUST have been updated to be that subbaseline.
(DAV: アップデート-「副-基線」): 要求がバージョンの制御構成をアップデートしたなら、DAV: 基線の制御収集は要求基線の「副-基線」の1つの基線で制御されたメンバーを含んで、次に、その「副-基線」になるようにDAV: その基線で制御されたメンバーのバージョンで制御された構成の預けている特性をアップデートしたに違いありません。 要求がバージョンで制御された構成をアップデートしたならDAV: 基線の制御収集が要求基線の「副-基線」の1つの基線で制御されたメンバーを含むワークスペースのメンバーである、そして、その「副-基線」になるようにDAV: その基線で制御されたメンバーのバージョンで制御された構成の預けている特性をアップデートしたに違いありません。
Clemm, et al. Standards Track [Page 88] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[88ページ]。
(DAV:modify-configuration): If the request updated the
DAV:checked-in property of any version-controlled member of a
baseline-controlled collection, and if this DAV:checked-in
property differs from the DAV:checked-in property of the
corresponding version-controlled member of the DAV:baseline-
collection of the DAV:checked-in baseline of the DAV:version-
controlled-configuration of the baseline-controlled collection,
then this is a modification to that version-controlled
configuration, and standard auto-versioning semantics apply.
(DAV:、構成を変更する、)、: 要求はDAVをアップデートしました: -中では、このDAV: 預けている特性はDAVと異なっています: 何か基線で制御された収集のバージョンで制御されたメンバーの特性とDAVの対応するバージョンで制御されたメンバー: DAV: 自動versioningしているそのバージョンで制御された構成、および規格に意味論が当てはまるDAV: 基線で制御された収集、その時のバージョンの制御構成a変更のチェックのコネの基線の基線収集の預けている特性チェックします。
12.14 Additional MERGE Semantics
12.14 追加マージ意味論
If the merge source is a baseline, the merge target is a version- controlled configuration for the baseline history of that baseline, where the baseline-controlled collection of that version-controlled configuration is a member of the collection identified by the request-URL.
マージソースが基線であるなら、マージ目標はその基線の基線歴史のためのバージョンの制御構成です。(そこでは、そのバージョンで制御された構成の基線で制御された収集が要求URLによって特定された収集のメンバーです)。
Additional Preconditions:
追加前提条件:
(DAV:must-not-update-baseline-collection): Same semantics as
UPDATE (see Section 12.13).
(DAV:、基線収集をアップデートしているはずがない、)、: UPDATE(セクション12.13を見る)と同じ意味論。
(DAV:cannot-modify-version-controlled-configuration): Same
semantics as UPDATE (see Section 12.13).
(DAV:、バージョンの制御構成を変更できない、)、: UPDATE(セクション12.13を見る)と同じ意味論。
Additional Postconditions:
追加Postconditions:
(DAV:merge-baseline): If the merge target is a version-controlled
configuration whose DAV:checked-out baseline is not a descendant
of the merge baseline, then the merge baseline MUST have been
added to the DAV:auto-merge-set of a version-controlled
configuration. The DAV:checked-in version of each member of the
DAV:baseline-collection of that baseline MUST have been merged
into the DAV:baseline-controlled-collection of that version-
controlled configuration.
(DAV: マージ基線): 次に、マージ基線はDAVに加えられたに違いありません: マージ目標がバージョンで制御された構成であるならDAV: 調べている基線がマージ基線の子孫でない、バージョンで制御された構成の自動マージのセット。 DAV: DAVのそれぞれのメンバーの預けているバージョン: その基線の基線収集はDAVに合併されたに違いありません: そのバージョンの制御構成の基線の制御収集。
(DAV:merge-subbaselines): If the merge target is a version-
controlled configuration whose DAV:baseline-controlled-collection
contains a baseline-controlled member for one of the subbaselines
of the merge baseline, then that subbaseline MUST have been merged
into the version-controlled configuration of that baseline-
controlled member. If the merge target is a version-controlled
configuration whose DAV:baseline-controlled-collection is a member
of a workspace that contains a baseline-controlled member for one
of the subbaselines of the merge baseline, then that subbaseline
MUST have been merged into the version-controlled configuration of
that baseline-controlled member.
(DAV: マージ-「副-基線」): マージ目標がバージョンの制御構成であるなら、DAV: 基線の制御収集はマージ基線の「副-基線」の1つの基線で制御されたメンバーを含んで、次に、その「副-基線」はその基線の制御メンバーのバージョンで制御された構成に合併されたに違いありません。 マージ目標がバージョンで制御された構成であるならDAV: 基線の制御収集がマージ基線の「副-基線」の1つの基線で制御されたメンバーを含むワークスペースのメンバーである、そして、その「副-基線」はその基線で制御されたメンバーのバージョンで制御された構成に合併されたに違いありません。
Clemm, et al. Standards Track [Page 89] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[89ページ]。
(DAV:set-baseline-controlled-collection-members): Same semantics
as UPDATE (see Section 12.13).
(DAV: セットの基線の制御収集メンバー): UPDATE(セクション12.13を見る)と同じ意味論。
(DAV:modify-configuration): Same semantics as UPDATE (see Section
12.13).
(DAV:、構成を変更する、)、: UPDATE(セクション12.13を見る)と同じ意味論。
13 Activity Feature
13活動機能
An activity is a resource that selects a set of versions that are on a single "line of descent", where a line of descent is a sequence of versions connected by successor relationships. If an activity selects versions from multiple version histories, the versions selected in each version history must be on a single line of descent.
活動は家系の線が後継者関係によって接続されたバージョンの系列である単一の「家系の線」にある1セットのバージョンを選択するリソースです。 活動が複数のバージョン歴史からバージョンを選択するなら、家系の単線の上にそれぞれのバージョン歴史で選択されたバージョンがあるに違いありません。
A common problem that motivates the use of activities is that it is often desirable to perform several different logical changes in a single workspace, and then selectively merge a subset of those logical changes to other workspaces. An activity can be used to represent a single logical change, where an activity tracks all the resources that were modified to effect that single logical change. When a version-controlled resource is checked out, the user specifies which activity should be associated with a new version that will be created when that version-controlled resource is checked in. It is then possible to select a particular logical change for merging into another workspace, by specifying the appropriate activity in a MERGE request.
活動の使用を動機づける共有する問題は単一のワークスペースの数回の異なった論理的な変化を実行して、次に、選択的に他のワークスペースへのそれらの論理的な変化の部分集合を合併するのがしばしば望ましいということです。 単一の論理的な変化を表すのに活動を使用できます、活動がその単一の論理的な変化に作用するように変更されたすべてのリソースを追跡するところで。 バージョンで制御されたリソースが調べられるとき、ユーザは、どの活動がそのバージョンで制御されたリソースが預けられるとき作成される新しいバージョンに関連しているべきであるかを指定します。 次に、別のワークスペースに溶け込むために特定の論理的な変化を選択するのは可能です、MERGE要求における適切な活動を指定することによって。
Another common problem is that although a version-controlled resource may need to have multiple lines of descent, all work done by members of a given team must be on a single line of descent (to avoid merging between team members). An activity resource provides the mechanism for addressing this problem. When a version-controlled resource is checked out, a client can request that an existing activity be used or that a new activity be created. Activity semantics then ensure that all versions in a given version history that are associated with an activity are on a single line of descent. If all members of a team share a common activity (or sub-activities of a common activity), then all changes made by members of that team will be on a single line of descent.
別の共有する問題はバージョンで制御されたリソースが家系の複数の線を必要とするかもしれませんが、家系(チームメンバーの間で合併するのを避ける)の単線の上に与えられたチームのメンバーによって行われたすべての仕事があるに違いないということです。 活動リソースはこのその問題を訴えるのにメカニズムを提供します。 バージョンで制御されたリソースが調べられるとき、クライアントは、既存の活動が使用されるか、または新しい活動が作成されるよう要求できます。 そして、活動意味論は、家系の単線の上に与えられたバージョン歴史の活動に関連しているすべてのバージョンがあるのを確実にします。 チームのすべてのメンバーが一般的な活動(または、一般的な活動のサブ活動)を共有すると、家系の単線の上にそのチームのメンバーによって行われたすべての変更があるでしょう。
Clemm, et al. Standards Track [Page 90] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[90ページ]。
The following diagram illustrates activities. Version V5 is the latest version of foo.html selected by activity Act-2, and version V8 is the latest version of bar.html selected by activity Act-2.
以下のダイヤグラムは活動を例証します。 バージョンV5は活動条例-2によって選択されたfoo.htmlの最新版です、そして、バージョンV8は活動条例-2によって選択されたbar.htmlの最新版です。
foo.html History bar.html History
foo.html歴史bar.html歴史
+---+ +---+
Act-1| |V1 Act-1| |V6
+---+ +---+
| |
| |
+---+ +---+
Act-1| |V2 Act-2| |V7
+---+ +---+
/ \ |
/ \ |
+---+ +---+ +---+
Act-1| |V3 Act-2| |V4 Act-2| |V8
+---+ +---+ +---+
| |
| |
+---+ +---+
Act-2| |V5 Act-3| |V9
+---+ +---+
+---+ +---+ 条例-1| |V1条例-1| |V6+---+ +---+ | | | | +---+ +---+ 条例-1| |V2条例-2| |V7+---+ +---+ / \ | / \ | +---+ +---+ +---+ 条例-1| |V3条例-2| |V4条例-2| |V8+---+ +---+ +---+ | | | | +---+ +---+ 条例-2| |V5条例-3| |V9+---+ +---+
Activities appear under a variety of names in existing versioning systems. When an activity is used to capture a logical change, it is commonly called a "change set". When an activity is used to capture a line of descent, it is commonly called a "branch". When a system supports both branches and change sets, it is often useful to require that a particular change set occur on a particular branch. This relationship can be captured by making the change set activity be a "subactivity" of the branch activity.
活動はシステムをversioningしながら存在する際にさまざまな名前の下で見えます。活動が論理的な変化をキャプチャするのに使用されるとき、それは一般的に「変化セット」と呼ばれます。 活動が家系の系列を得るのに使用されるとき、それは一般的に「ブランチ」と呼ばれます。 システムがブランチと変化セットの両方を支えるとき、特定の変化セットが特定の支店に現れるのが必要であるのはしばしば役に立ちます。 変化セット活動がブランチ活動の"「副-活動」"であると作ることによって、この関係を得ることができます。
13.1 Activity Properties
13.1 活動の特性
The DAV:resourcetype of an activity MUST be DAV:activity.
DAV: 活動のresourcetypeはDAVであるに違いありません: 活動。
The activity feature introduces the following REQUIRED properties for an activity.
活動機能は活動のために以下のREQUIRED資産を紹介します。
13.1.1 DAV:activity-version-set (computed)
13.1.1 DAV: 活動バージョンセット(計算されます)
This property identifies each version whose DAV:activity-set property identifies this activity. Multiple versions of a single version history can be selected by an activity's DAV:activity-version-set
この特性は各バージョンを特定します。DAV: 活動セット所有地はこの活動を特定します。 活動のDAVはただ一つのバージョン歴史の複数のバージョンを選択できます: 活動バージョンはセットしました。
Clemm, et al. Standards Track [Page 91] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[91ページ]。
property, but all DAV:activity-version-set versions from a given version history must be on a single line of descent from the root version of that version history.
しかし、特性、すべてのDAV: そのバージョン歴史の根のバージョンからの家系の単線の上に与えられたバージョン歴史からの活動バージョンセットバージョンがあるに違いありません。
<!ELEMENT activity-version-set (href*)>
<!ELEMENT活動バージョンセット(href*)>。
13.1.2 DAV:activity-checkout-set (computed)
13.1.2 DAV: 活動チェックアウトセット(計算されます)
This property identifies each checked-out resource whose DAV:activity-set identifies this activity.
この特性はそれぞれの調べているリソースを特定します。DAV: 活動セットはこの活動を特定します。
<!ELEMENT activity-checkout-set (href*)>
<!ELEMENT活動チェックアウトセット(href*)>。
13.1.3 DAV:subactivity-set
13.1.3 DAV: 「副-活動」-セット
This property identifies each activity that forms a part of the logical change being captured by this activity. An activity behaves as if its DAV:activity-version-set is extended by the DAV:activity- version-set of each activity identified in the DAV:subactivity-set. In particular, the versions in this extended set MUST be on a single line of descent, and when an activity selects a version for merging, the latest version in this extended set is the one that will be merged.
この特性はこの活動でキャプチャされる論理的な変化の一部を形成する各活動を特定します。 まるでDAV: 活動バージョンセットがDAVによって広げられるかのように活動は振る舞います: DAV: 「副-活動」-セットで特定されたそれぞれの活動の活動バージョンセット。 家系の単線の上に特に、この拡張セットにおけるバージョンがあるに違いありません、そして、活動が合併するためのバージョンを選択するとき、この拡張セットにおける最新版は合併されるものです。
A server MAY reject attempts to modify the DAV:subactivity-set of an activity.
サーバはDAVを変更する試みを拒絶するかもしれません: 活動の「副-活動」-セット。
<!ELEMENT subactivity-set (href*)>
<!ELEMENT subactivity-セット(href*)>。
13.1.4 DAV:current-workspace-set (computed)
13.1.4 DAV: 現在のワークスペースセット(計算されます)
This property identifies each workspace whose DAV:current-activity- set identifies this activity.
この特性は各ワークスペースを特定します。DAV: 現在の活動セットはこの活動を特定します。
<!ELEMENT current-workspace-set (href*)>
<!のELEMENTの現在のワークスペースセット(href*)>。
13.2 Additional Version Properties
13.2 追加バージョンの特性
The activity feature introduces the following REQUIRED property for a version.
活動機能はバージョンのために以下のREQUIRED資産を紹介します。
Clemm, et al. Standards Track [Page 92] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[92ページ]。
13.2.1 DAV:activity-set
13.2.1 DAV: 活動セット
This property identifies the activities that determine to which logical changes this version contributes, and on which lines of descent this version appears. A server MAY restrict the DAV:activity-set to identify a single activity. A server MAY refuse to allow the value of the DAV:activity-set property of a version to be modified.
この特性はこのバージョンがどの論理的な変化に貢献するか、そして、このバージョンが家系のどの系列で現れるかを決定する活動を特定します。 サーバはDAVを制限するかもしれません: ただ一つの活動を特定する活動セット。 サーバは、DAVの値: バージョンの活動セット所有地が変更されるのを許容するのを拒否するかもしれません。
<!ELEMENT activity-set (href*)>
ELEMENTが活動で設定する<!(href*)>。
13.3 Additional Checked-Out Resource Properties
13.3 調べている追加リソースの特性
The activity feature introduces the following REQUIRED properties for a checked-out resource.
活動機能は調べているリソースのために以下のREQUIRED資産を紹介します。
13.3.1 DAV:unreserved
13.3.1 DAV:、無遠慮
This property of a checked-out resource indicates whether the DAV:activity-set of another checked-out resource associated with the version history of this version-controlled resource can have an activity that is in the DAV:activity-set property of this checked-out resource.
調べているリソースのこの特性は、DAV: このバージョンで制御されたリソースのバージョン歴史に関連している別の調べているリソースの活動セットはDAVにある活動を持つことができます: この調べているリソースの活動セット所有地を示します。
A result of the requirement that an activity must form a single line of descent through a given version history is that if multiple checked-out resources for a given version history are checked out unreserved into a single activity, only the first CHECKIN will succeed. Before another of these checked-out resources can be checked in, the user will first have to merge into that checked-out resource the latest version selected by that activity from that version history, and then modify the DAV:predecessor-set of that checked-out resource to identify that version.
活動が与えられたバージョン歴史で家系の単線を形成しなければならないという要件の結果は与えられたバージョン歴史のための複数の調べているリソースがただ一つの活動に無遠慮な状態で調べられると、最初のCHECKINだけが成功するということです。 これらの調べているリソースの別のものを預けることができる前に、ユーザは、最初に、最新版がそのバージョン歴史からその活動で選択したその調べているリソースに溶け込んで、次に、そのバージョンを特定するようにDAV: その調べているリソースの前任者セットを変更しなければならないでしょう。
<!ELEMENT unreserved (#PCDATA)> PCDATA value: boolean
<!のELEMENTの無遠慮な(#PCDATA)>PCDATA価値: 論理演算子
13.3.2 DAV:activity-set
13.3.2 DAV: 活動セット
This property of a checked-out resource determines the DAV:activity- set property of the version that results from checking in this resource.
調べているリソースのこの特性はDAVを決定します: 活動は、このリソースを預けるので、結果として生じるバージョンの特性を設定しました。
13.4 Additional Workspace Properties
13.4 追加ワークスペースの特性
The activity feature introduces the following REQUIRED property for a workspace.
活動機能は以下のREQUIRED資産をワークスペースに紹介します。
Clemm, et al. Standards Track [Page 93] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[93ページ]。
13.4.1 DAV:current-activity-set
13.4.1 DAV: 現在の活動セット
This property identifies the activities that currently are being performed in this workspace. When a member of this workspace is checked out, if no activity is specified in the checkout request, the DAV:current-activity-set will be used. This allows an activity- unaware client to update a workspace in which activity tracking is required. The DAV:current-activity-set MAY be restricted to identify at most one activity.
この特性は現在このワークスペースで実行されている活動を特定します。 活動が全くチェックアウト要求で指定されないならこのワークスペースのメンバーが調べられるとき、DAV: 現在の活動セットは使用されるでしょう。 これで、活動の気づかないクライアントは活動追跡が必要であるワークスペースをアップデートできます。 DAV: 現在の活動セットは、最も1つで活動を特定するために制限されるかもしれません。
<!ELEMENT current-activity-set (href*)>
<!のELEMENTの現在の活動セット(href*)>。
13.5 MKACTIVITY Method
13.5 MKACTIVITYメソッド
A MKACTIVITY request creates a new activity resource. A server MAY restrict activity creation to particular collections, but a client can determine the location of these collections from a DAV:activity- collection-set OPTIONS request.
MKACTIVITY要求は新しい活動リソースを作成します。 クライアントはDAVからこれらの収集の位置を決定できます: サーバは活動作成を特定の収集に制限するかもしれません、しかし、収集セットOPTIONSが要求する活動。
Marshalling:
整理します:
If a request body is included, it MUST be a DAV:mkactivity XML
element.
要求本体が含まれているなら、それはDAVであるに違いありません: mkactivity XML要素。
<!ELEMENT mkactivity ANY>
<!ELEMENT mkactivityはあらゆる>です。
If a response body for a successful request is included, it MUST
be a DAV:mkactivity-response XML element.
うまくいっている要求のための応答本体が含まれているなら、それはDAVであるに違いありません: mkactivity-応答XML要素。
<!ELEMENT mkactivity-response ANY>
<!ELEMENT mkactivity-応答いずれも>。
The response MUST include a Cache-Control:no-cache header.
応答はCache-コントロールを含まなければなりません: キャッシュがないヘッダー。
Preconditions:
前提条件:
(DAV:resource-must-be-null): A resource MUST NOT exist at the
request-URL.
(DAV:、リソースがヌルであるに違いない、)、: リソースは要求URLに存在してはいけません。
(DAV:activity-location-ok): The request-URL MUST identify a
location where an activity can be created.
(DAV: 活動位置のOK): 要求URLは活動を作成できる位置を特定しなければなりません。
Postconditions:
Postconditions:
(DAV:initialize-activity): A new activity exists at the request-
URL. The DAV:resourcetype of the activity MUST be DAV:activity.
(DAV:、活動を初期化する、)、: 新しい活動は要求URLに存在しています。 DAV: 活動のresourcetypeはDAVであるに違いありません: 活動。
Clemm, et al. Standards Track [Page 94] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[94ページ]。
13.5.1 Example - MKACTIVITY
13.5.1 例--MKACTIVITY
>>REQUEST
>>要求
MKACTIVITY /act/test-23 HTTP/1.1
Host: repo.webdav.org
Content-Length: 0
MKACTIVITY/行為/test-23HTTP/1.1ホスト: repo.webdav.org Content-長さ: 0
>>RESPONSE
>>応答
HTTP/1.1 201 Created
Cache-Control: no-cache
HTTP/1.1 201はキャッシュ制御を作成しました: キャッシュがありません。
In this example, a new activity is created at http://repo.webdav.org/act/test-23.
この例では、新しい活動は http://repo.webdav.org/act/test-23 に作成されます。
13.6 DAV:latest-activity-version Report
13.6DAV: 最新の活動バージョンレポート
The DAV:latest-activity-version report can be applied to a version history to identify the latest version that is selected from that version history by a given activity.
DAV: そのバージョン歴史から与えられた活動で選択される最新版を特定するために最新の活動バージョンレポートをバージョン歴史に適用できます。
Marshalling:
整理します:
The request body MUST be a DAV:latest-activity-version XML
element.
要求本体はDAVであるに違いありません: 最新の活動バージョンXML要素。
<!ELEMENT latest-activity-version (href)>
<!のELEMENTの最新の活動バージョン(href)>。
The response body for a successful request MUST be a DAV:latest-
activity-version-report XML element.
うまくいっている要求のための応答本体はDAVであるに違いありません: 最新の活動バージョンレポートXML要素。
<!ELEMENT latest-activity-version-report (href)>
<!のELEMENTの最新の活動バージョンレポート(href)>。
The DAV:href of the response body MUST identify the version of the
given version history that is a member of the DAV:activity-
version-set of the given activity and has no descendant that is a
member of the DAV:activity-version-set of that activity.
DAV: 応答本体のhrefには、DAVのメンバーである与えられたバージョン歴史のバージョン: 与えられた活動の活動バージョンセットを特定しなければならなくて、DAVのメンバーである子孫が全くいません: その活動の活動バージョンセット。
Preconditions:
前提条件:
(DAV:must-be-activity): The DAV:href in the request body MUST
identify an activity.
(DAV:、活動でなければならない、)、: DAV: 要求本体のhrefは活動を特定しなければなりません。
Clemm, et al. Standards Track [Page 95] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[95ページ]。
13.7 Additional OPTIONS Semantics
13.7 追加オプション意味論
If the server supports the activity feature, it MUST include "activity" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
サーバが活動機能をサポートするなら、それはDAV応答ヘッダの分野としてどんなversioningの特性、レポートもサポートするどんなリソースに関するOPTIONS要求、またはメソッドからも「活動」を含まなければなりません。
A DAV:activity-collection-set element MAY be included in the request body to identify collections that may contain activity resources.
DAV: 活動収集セット要素は、活動リソースを含むかもしれない収集を特定するために要求本体に含まれるかもしれません。
Additional Marshalling:
追加整理:
If an XML request body is included, it MUST be a DAV:options XML
element.
XML要求ボディーが含まれているなら、それはDAVであるに違いありません: オプションXML要素。
<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
DAV:activity-collection-set element.
いずれも>が少しも評価する<!ELEMENTオプション: 高々1DAVがある要素の系列: 活動収集セット要素。
If an XML response body for a successful request is included, it
MUST be a DAV:options-response XML element.
うまくいっている要求のためのXML応答ボディーが含まれているなら、それはDAVであるに違いありません: オプション応答XML要素。
<!ELEMENT options-response ANY>
ANY value: A sequence of elements with at most one
DAV:activity-collection-set element.
どんな>も少しも評価する<!ELEMENTオプション応答: 高々1DAVがある要素の系列: 活動収集セット要素。
<!ELEMENT activity-collection-set (href*)>
<!ELEMENT活動収集セット(href*)>。
If DAV:activity-collection-set is included in the request body,
the response body for a successful request MUST contain a
DAV:activity-collection-set element identifying collections that
may contain activities. An identified collection MAY be the root
collection of a tree of collections, all of which may contain
activities. Since different servers can control different parts
of the URL namespace, different resources on the same host MAY
have different DAV:activity-collection-set values. The identified
collections MAY be located on different hosts from the resource.
DAV: 収集が設定した活動が要求本体に含まれているなら、うまくいっている要求のための応答本体はDAVを含まなければなりません: 活動を含むかもしれない収集を特定する活動収集セット要素。 特定された収集は収集の木の根の収集であるかもしれません。そのすべてが活動を含むかもしれません。 異なったサーバがURL名前空間の異なった部品を制御できるので、同じホストに関する異なったリソースには、異なったDAVがあるかもしれません: 活動収集設定値。 特定された収集はリソースからの異なったホストの上に位置するかもしれません。
13.8 Additional DELETE Semantics
13.8、追加、意味論を削除してください。
Additional Postconditions:
追加Postconditions:
(DAV:delete-activity-reference): If an activity is deleted, any
reference to that activity in a DAV:activity-set,
DAV:subactivity-set, or DAV:current-activity-set MUST be removed.
(DAV: 活動参照を削除してください): 活動が削除されるなら、a DAVのその活動のどんな参照: 活動セット、DAV: 「副-活動」-セット、またはDAV: 現在の活動セットを取り外さなければなりません。
Clemm, et al. Standards Track [Page 96] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[96ページ]。
13.9 Additional MOVE Semantics
13.9 追加移動意味論
Additional Postconditions:
追加Postconditions:
(DAV:update-checked-out-reference): If a checked-out resource is
moved, any reference to that resource in a DAV:activity-checkout-
set property MUST be updated to refer to the new location of that
resource.
(DAV: 参照からチェックされたアップデート): 調べているリソースを動かすなら、そのリソースの新しい位置について言及するためにDAVのそのリソースのどんな参照: 活動チェックアウトに設定された特性をアップデートしなければなりません。
(DAV:update-activity-reference): If the request-URL identifies an
activity, any reference to that activity in a DAV:activity-set,
DAV:subactivity-set, or DAV:current-activity-set MUST be updated
to refer to the new location of that activity.
(DAV: アップデート活動参照): 要求URLが活動を特定するなら、DAV: 活動セット、DAV: 「副-活動」-セット、またはDAVの: 現在の活動セットをアップデートしなければならないその活動のどんな参照もその活動の新しい位置について言及します。
(DAV:update-workspace-reference): If the request-URL identifies a
workspace, any reference to that workspace in a DAV:current-
workspace-set property MUST be updated to refer to the new
location of that workspace.
(DAV: アップデートワークスペース参照): 要求URLがワークスペースを特定するなら、そのワークスペースの新しい位置について言及するためにDAVのそのワークスペースのどんな参照: 現在のワークスペースセット所有地をアップデートしなければなりません。
13.10 Additional CHECKOUT Semantics
13.10 追加チェックアウト意味論
A CHECKOUT request MAY specify the DAV:activity-set for the checked- out resource.
CHECKOUT要求はDAVを指定するかもしれません: チェックの出ているリソースのために活動に設定されています。
Additional Marshalling:
追加整理:
<!ELEMENT checkout ANY> ANY value: A sequence of elements with at
most one DAV:activity-set and at most one DAV:unreserved.
どんな>も少しも評価する<!ELEMENTチェックアウト: 高々1DAVがある要素の系列: 活動セットと高々1DAV: 無遠慮です。
<!ELEMENT activity-set (href+ | new)>
<!ELEMENT new EMPTY>
<!ELEMENT unreserved EMPTY>
<!ELEMENT活動セット、(href+| 新しい)、新しい>の><!ELEMENT予約していないEMPTY<!ELEMENT EMPTY>。
Additional Preconditions:
追加前提条件:
(DAV:one-checkout-per-activity-per-history): If there is a request
activity set, unless DAV:unreserved is specified, another checkout
from a version of that version history MUST NOT select an activity
in that activity set.
(DAV: 1歴史あたりの活動あたり1つのチェックアウト): 要求があれば活動がセットした、DAV: 無遠慮であるのは、指定されていて、そのバージョン歴史のバージョンからの別のチェックアウトが中の活動が設定した活動を選択してはいけないということです。
(DAV:linear-activity): If there is a request activity set, unless
DAV:unreserved is specified, the selected version MUST be a
descendant of all other versions of that version history that
select that activity.
(DAV: 直線的な活動): 要求があれば活動がセットした、DAV: 無遠慮であるのは、指定されていて、選択されたバージョンがその活動を選択するそのバージョン歴史の他のすべてのバージョンの子孫であるに違いないということです。
Clemm, et al. Standards Track [Page 97] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[97ページ]。
Additional Postconditions:
追加Postconditions:
(DAV:initialize-activity-set): The DAV:activity-set of the
checked-out resource is set as follows:
(設定していた状態で活動を初期化しているDAV): DAV: 調べているリソースの活動セットは以下の通り設定されます:
- If DAV:new is specified as the DAV:activity-set in the request
body, then a new activity created by the server is used.
- Otherwise, if activities are specified in the request body,
then those activities are used.
- Otherwise, if the version-controlled resource is a member of a
workspace and the DAV:current-activity-set of the workspace is
set, then those activities are used.
- Otherwise, the DAV:activity-set of the DAV:checked-out version
is used.
- DAV: 新しいのは、DAV: 活動セットとして要求本体で指定されていて、次に、サーバによって作成された新しい活動が使用されているということです。 - さもなければ、活動が要求本体で指定されるなら、それらの活動は使用されています。 - さもなければ、バージョンで制御されたリソースはワークスペースのメンバーであるかどうか、そして、DAV: ワークスペースの現在の活動セットは設定されて、次に、それらの活動は使用されています。 - さもなければ、DAV: DAVの活動セット: 調べているバージョンは使用されています。
(DAV:initialize-unreserved): If DAV:unreserved was specified in
the request body, then the DAV:unreserved property of the
checked-out resource MUST be "true".
(DAV:、初期化、-、無遠慮である、)、: DAV: 無遠慮であるのが、要求が具体化させる指定されたコネであり、次に、DAV: 調べているリソースの予約していない特性は「本当でなければなりません」。
13.10.1 Example - CHECKOUT with an activity
13.10.1 例--活動があるCHECKOUT
>>REQUEST
>>要求
CHECKOUT /ws/public/foo.html HTTP/1.1
Host: www.webdav.org
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
チェックアウト/ws/public/foo.html HTTP/1.1ホスト: www.webdav.orgコンテントタイプ: テキスト/xml。 charsetが等しい、「utf-8インチのContent-長さ:」 xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:checkout xmlns:D="DAV:">
<D:activity-set>
<D:href>http://repo.webdav.org/act/fix-bug-23</D:href>
</D:activity-set>
</D:checkout>
<?xmlバージョンが等しい、「=をコード化する1インチ、「utf-8インチ?><D: チェックアウトxmlns: Dが等しい、「DAV: 「><D: 活動に設定された><D: href>http://repo.webdav.org/行為/フィックスバグ-23</D: href></D: 活動に設定された></D: チェックアウト>」
>>RESPONSE
>>応答
HTTP/1.1 200 OK
Cache-Control: no-cache
HTTP/1.1 200はキャッシュ制御を承認します: キャッシュがありません。
In this example, the CHECKOUT is being performed in the http://repo.webdav.org/act/fix-bug-23 activity.
この例では、CHECKOUTは http://repo.webdav.org/act/fix-bug-23 活動で実行されています。
Clemm, et al. Standards Track [Page 98] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[98ページ]。
13.11 Additional CHECKIN Semantics
13.11 追加チェックイン意味論
Additional Preconditions:
追加前提条件:
(DAV:linear-activity): Any version which is in the version history
of the checked-out resource and whose DAV:activity-set identifies
an activity from the DAV:activity-set of the checked-out resource
MUST be an ancestor of the checked-out resource.
(DAV: 直線的な活動): DAVからの活動: 調べているリソースの活動セットが調べているリソースとDAV: 活動セットがだれのものを特定するかに関するバージョン歴史では、調べているリソースの先祖であるに違いないということであるどんなバージョン。
(DAV:atomic-activity-checkin): If the request-URL identifies an
activity, the server MAY fail the request if any of the checked-
out resources in the DAV:activity-checkout-set of either that
activity or any subactivity of that activity cannot be checked in.
(DAV: 原子活動チェックイン): 要求URLが活動を特定するなら、サーバはもしあればDAVでのチェックの出ているリソースの要求に失敗するかもしれません: その活動のその活動かどんな「副-活動」のどちらかの活動チェックアウトセットも預けることができません。
Additional Postconditions:
追加Postconditions:
(DAV:initialize-activity-set): The DAV:activity-set of the new
version MUST have been initialized to be the same as the
DAV:activity-set of the checked-out resource.
(設定していた状態で活動を初期化しているDAV): DAV: 新しいバージョンの活動セットはDAVと同じになるように初期化されたに違いありません: 調べているリソースの活動セット。
(DAV:activity-checkin): If the request-URL identified an activity,
the server MUST have successfully applied the CHECKIN request to
each checked-out resource in the DAV:activity-checkout-set of both
that activity and any subactivity of that activity.
(DAV: 活動チェックイン): 要求URLが活動を特定したなら、サーバは首尾よくDAVのそれぞれの調べているリソースにCHECKIN要求を適用したに違いありません: その活動とその活動のどんな「副-活動」の両方の活動チェックアウトセット。
13.12 Additional MERGE Semantics
13.12 追加マージ意味論
If the DAV:source element of the request body identifies an activity, then for each version history containing a version selected by that activity, the latest version selected by that activity is a merge source. Note that the versions selected by an activity are the versions in its DAV:activity-version-set unioned with the versions selected by the activities in its DAV:subactivity-set.
DAV: 要求本体のソース要素が活動を特定するなら、その活動で選択されたバージョンを含むそれぞれのバージョン歴史に関してその活動で選択された最新版はマージソースです。 活動で選択されたバージョンがDAVのバージョンであることに注意してください: バージョンがDAVで活動で選択されている状態で、活動バージョンセットはunionedされました: 「副-活動」-セット。
Additional Marshalling:
追加整理:
<!ELEMENT checkin-activity EMPTY>
<!ELEMENTチェックイン活動EMPTY>。
Additional Postconditions:
追加Postconditions:
(DAV:checkin-activity): If DAV:checkin-activity is specified in
the request body, and if the DAV:source element in the request
body identifies an activity, a CHECKIN request MUST have been
successfully applied to that activity before the merge sources
were determined.
(DAV: チェックイン活動): DAV: チェックイン活動が要求本体で指定されて、DAV: 要求本体のソース要素が活動を特定するなら、マージソースが決定している前にCHECKIN要求は首尾よくその活動に適用されたに違いありません。
Clemm, et al. Standards Track [Page 99] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[99ページ]。
14 Version-Controlled-Collection Feature
14バージョンの制御収集機能
As with any versionable resource, when a collection is put under version control, a version history resource is created to contain versions for that version-controlled collection. In order to preserve standard versioning semantics (a version of a collection should not be modifiable), a collection version only records information about the version-controlled bindings of that collection.
収集がバージョンコントロールの下で置かれるとき、どんな「バージョン-可能」リソースのようにも、バージョン歴史リソースは、そのバージョンで制御された収集のためのバージョンを含むように作成されます。 標準のversioning意味論(収集のバージョンは修正できるべきでない)を保存するために、収集バージョンはその収集のバージョンで制御された製本の情報を記録するだけです。
In order to cleanly separate a modification to the namespace from a modification to content or dead properties, a version of a collection has no members, but instead records in its DAV:version-controlled- binding-set property the binding name and version history resource of each version-controlled internal member of that collection. If, instead, a collection version contained bindings to other versions, creating a new version of a resource would require creating a new version of all the collection versions that contain that resource, which would cause activities to become entangled. For example, suppose a "feature-12" activity created a new version of /x/y/a.html. If a collection version contained bindings to versions of its members, a new version of /x/y would have to be created to contain the new version of /x/y/a.html, and a new version of /x would have to be created to contain the new version of /x/y. Now suppose a "bugfix-47" activity created a new version of /x/z/b.html. Again, a new version of /x/z and a new version of /x would have to be created to contain the new version of /x/y/b.html. But now it is impossible to merge just "bugfix-47" into another workspace without "feature- 12", because the version of /x that contains the desired version of /x/z/b.html also contains version of /x/y/a.html created for "feature-12". If, instead, a collection version just records the binding name and version history resource of each version-controlled internal member, changing the version selected by a member of that collection would not require a new version of the collection. The new version is still in the same version history so no new collection version is required, and "feature-12" and "bugfix-47" would not become entangled.
満足しているか死んでいる特性への変更と名前空間への変更を清潔に切り離すために、収集のバージョンは、メンバーが全くいませんが、代わりにその収集のそれぞれのバージョンで制御された内部のメンバーの拘束力がある名前とバージョン歴史リソースをDAV: バージョンで制御された拘束力があるセット所有地に記録します。 収集バージョンが代わりに他のバージョンに結合を含んでいるなら、リソースの新しいバージョンを作成すると、活動がもつれるようになるだろうそのリソースによって含むすべての収集バージョンが新しいバージョンを作成するのが要求されるでしょうに。 例えば「特徴の12インチの活動は/x/y/a.htmlについて新しいバージョンを作成した」なら。 収集バージョンがメンバーのバージョンに結合を含んでいるなら、/x/yの新しいバージョンは/x/y/a.htmlの新しいバージョンを含むように作成されなければならないでしょうに、そして、/xの新しいバージョンは、/x/yの新しいバージョンを含むように作成されなければならないでしょう。 現在、「bugfix-47インチの活動は/x/z/b.htmlについて新しいバージョンを作成したこと」が思います。 一方、/x/zの新しいバージョンと/xの新しいバージョンは、/x/y/b.htmlの新しいバージョンを含むように作成されなければならないでしょう。 しかし、現在合併するのが不可能である、まさしく、「47インチをbugfixする、別のワークスペース、「12インチを特集してください、また、/x/z/b.の必要なバージョンを含む/xのバージョンがhtmlに「特徴12インチ」作成された/x/y/a.htmlのバージョンを含んでいるので。 収集バージョンが代わりにただそれぞれのバージョンで制御された内部のメンバーの拘束力がある名前とバージョン歴史リソースを記録するなら、その収集のメンバーによって選択されたバージョンを変えるのは収集の新しいバージョンを必要としないでしょう。 bugfix-47インチはそうするでしょう。そして、そして、新しいバージョンがまだ同じバージョン歴史にあるのでどんな新しい収集バージョンも必要でない、「-何12インチも特集、「もつれるようにならない、」
In the following example, there are three version histories, named VH14, VH19, and VH24, where VH14 contains versions of a collection. The version-controlled collection /x has version V2 of version history VH14 as its DAV:checked-in version. Since V2 has recorded two version controlled bindings, one with binding name "a" to version history VH19, and the other with binding name "b" to version history VH24, /x MUST have two version-controlled bindings, one named "a" to a version-controlled resource for history VH19, and the other named "b" to a version-controlled resource for history VH24. The version-
以下の例には、VH14が収集のバージョンを含むVH14、VH19、およびVH24という3つのバージョン歴史があります。 バージョンで制御された収集/xには、DAVとしてバージョン歴史VH14のバージョンV2があります: バージョンを預けます。 V2が2つのバージョンの制御結合、バージョン歴史VH19への拘束力がある名前“a"がある1つ、およびバージョン歴史VH24への拘束力がある名前「b」があるもう片方を記録したので、/xには、2つのバージョンで制御された結合がなければなりません、そして、あるものは歴史のためのバージョンで制御されたリソースへの“a"をVH19と命名しました、そして、もう片方が歴史のためのバージョンで制御されたリソースへの「b」をVH24と命名しました。 バージョン
Clemm, et al. Standards Track [Page 100] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[100ページ]。
controlled resource /x/a currently has V4 of VH19 as its DAV:checked-in version, while /x/b has V8 of VH24 as its DAV:checked-in version.
制御リソース/x/aには、現在、DAVとしてVH19のV4があります: バージョンを預けます、/x/bにDAVとしてVH24のV8がありますが: 預けているバージョン。
VH19
+---------+
| +---+ |
| | |V4 |
| +---+ |
| | |
| | |
| +---+ |
| | |V5 |
VH14 | +---+ |
+---------+ | | |
| +---+ | | | |
a +---+ | | |V1 | | +---+ |
---->| |checked-in=V4 | +---+ | a | | |V6 |
/ +---+ | | ------>| +---+ |
/ | | / | +---------+
+---+ | +---+ |
/x | |checked-in=V2 | | |V2 |
+---+ | +---+ | VH24
\ | | \ | b +---------+
\ b +---+ | | ------>| +---+ |
---->| |checked-in=V8 | +---+ | | | |V7 |
+---+ | | |V3 | | +---+ |
| +---+ | | | |
+---------+ | | |
| +---+ |
| | |V8 |
| +---+ |
| | |
| | |
| +---+ |
| | |V9 |
| +---+ |
+---------+
VH19+---------+ | +---+ | | | |V4| | +---+ | | | | | | | | +---+ | | | |V5| VH14| +---+ | +---------+ | | | | +---+ | | | | +---+ | | |V1| | +---+ | ---->| |預けている=V4| +---+ | a| | |V6| / +---+ | | ------>| +---+ | / | | / | +---------+ +---+ | +---+ | /x| |預けている=V2| | |V2| +---+ | +---+ | VH24\| | \ | b+---------+ \b+---+ | | ------>| +---+ | ---->| |預けている=V8| +---+ | | | |V7| +---+ | | |V3| | +---+ | | +---+ | | | | +---------+ | | | | +---+ | | | |V8| | +---+ | | | | | | | | +---+ | | | |V9| | +---+ | +---------+
For any request (e.g., DELETE, MOVE, COPY) that modifies a version- controlled binding of a checked-in version-controlled collection, the request MUST fail unless the version-controlled collection has a DAV:auto-version property that will automatically check out the version-controlled collection when it is modified.
預けているバージョンで制御された収集のバージョンの制御製本を変更するどんな要求(例えば、DELETE、MOVE、COPY)のためにも、要求はバージョンで制御された収集には、DAVがあります: それが変更されているとき自動的にバージョンで制御された収集を調べる自動バージョンの特性でないなら失敗しなければなりません。
Although a collection version only records the version-controlled bindings of a collection, a version-controlled collection MAY contain both version-controlled and non-version-controlled bindings. Non-
収集バージョンは収集のバージョンで制御された製本を記録するだけですが、バージョンで制御された収集はバージョンで制御されて、かつ非バージョンが制御された結合を含むかもしれません。 非
Clemm, et al. Standards Track [Page 101] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[101ページ]。
version-controlled bindings are not under version control, and therefore can be added or deleted without checking out the version- controlled collection.
バージョンの制御収集を調べないで、したがって、バージョンで制御された結合は、バージョンコントロールの下になくて、加えるか、または削除できます。
Note that a collection version captures only a defined subset of the state of a collection. In particular, a version of a collection captures its dead properties and its bindings to version-controlled resources, but not its live properties or bindings to non-version- controlled resources.
収集バージョンが収集の状態の定義された部分集合だけを得ることに注意してください。 特に、a収集のバージョンがその精力の特性か結合ではなく、バージョンで制御されたリソースとの死んでいる特性とその結合を得る、非、-、バージョンで制御されたリソース。
When a server supports the working-resource feature, a client can check out a collection version to create a working collection. Unlike a version-controlled collection, which contains bindings to version-controlled resources and non-version-controlled resources, a working collection contains bindings to version history resources and non-version-controlled resources. In particular, a working collection is initialized to contain bindings to the version history resources specified by the DAV:version-controlled-binding-set of the checked out collection version. The members of a working collection can then be deleted or moved to another working collection. Non- version-controlled resources can be added to a working collection with methods such as PUT, COPY, and MKCOL. When a working collection is checked in, a VERSION-CONTROL request is automatically applied to every non-version-controlled member of the working collection, and each non-version-controlled member is replaced by its newly created version history. The DAV:version-controlled-binding-set of the new version resulting from checking in a working collection contains the binding name and version history URL for each member of the working collection.
サーバが働くリソース機能をサポートすると、クライアントは、働く収集を作成するために収集バージョンを調べることができます。 バージョンで制御された収集と異なって、働く収集はバージョン歴史リソースと非バージョンが制御されたリソースに結合を含んでいます。それは、バージョンで制御されたリソースと非バージョンが制御されたリソースに結合を含みます。 特に、働く収集はDAVによって指定されたバージョン歴史リソースに結合を含むように初期化されます: チェックの出ている収集バージョンのバージョンの制御拘束力があるセット。 そして、働く収集のメンバーを別の働く収集に削除するか、または動かすことができます。 PUTや、COPYや、MKCOLなどのメソッドでバージョンで非制御されたリソースを働く収集に追加できます。 働く収集を預けるとき、自動的に働く収集のすべての非バージョンが制御されたメンバーにバージョン-CONTROL要求を適用します、そして、それぞれの非バージョンが制御されたメンバーを新たに作成されたバージョン歴史に取り替えます。 DAV: 働く収集を預けるのからの新しいバージョンが結果として生じるバージョンの制御拘束力があるセットは働く収集の各メンバーのための拘束力がある名前とバージョン歴史URLを含んでいます。
14.1 Version-Controlled Collection Properties
14.1 バージョンで制御された収集の特性
A version-controlled collection has all the properties of a collection and of a version-controlled resource. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a version-controlled collection.
バージョンで制御された収集には、収集とバージョンで制御されたリソースのすべての特性があります。 さらに、バージョンの制御収集機能はバージョンで制御された収集のために以下のREQUIRED資産を紹介します。
14.1.1 DAV:eclipsed-set (computed)
14.1.1 DAV: おおい隠されたセット(計算されます)
This property identifies the non-version-controlled internal members of the collection that currently are eclipsing a version-controlled internal member of the collection.
この特性は現在収集のバージョンで制御された内部のメンバーをおおい隠している収集の非バージョンが制御された内部のメンバーを特定します。
!ELEMENT eclipsed-set (binding-name*)> <!ELEMENT binding-name (#PCDATA)> PCDATA value: URL segment
ELEMENTのおおい隠されたセット(拘束力がある名前*)の>の<!のELEMENTの拘束力がある名(#PCDATA)の>PCDATA価値: URLセグメント
Clemm, et al. Standards Track [Page 102] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[102ページ]。
An UPDATE or MERGE request can give a version-controlled collection a version-controlled internal member that has the same name as an existing non-version-controlled internal member. In this case, the non-version-controlled internal member takes precedence and is said to "eclipse" the new versioned-controlled internal member. If the non-version-controlled internal member is removed (e.g., by a DELETE or MOVE), the version-controlled internal member is exposed.
UPDATEかMERGE要求が既存の非バージョンが制御された内部のメンバーとして同じ名前を持っているバージョンで制御された内部のメンバーをバージョンで制御された収集に与えることができます。 この場合、非バージョンが制御された内部のメンバーは、優先して、新しいversionedされて制御された内部のメンバーを「おおい隠す」と言われます。 非バージョンが制御された内部のメンバーを免職するなら(例えば、DELETEかMOVE)、バージョンで制御された内部のメンバーをさらします。
14.2 Collection Version Properties
14.2 収集バージョンの特性
A collection version has all the properties of a version. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a collection version.
A collection version has all the properties of a version. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a collection version.
14.2.1 DAV:version-controlled-binding-set (protected)
14.2.1 DAV:version-controlled-binding-set (protected)
This property captures the name and version-history of each version- controlled internal member of a collection.
This property captures the name and version-history of each version- controlled internal member of a collection.
<!ELEMENT version-controlled-binding-set
(version-controlled-binding*)>
<!ELEMENT version-controlled-binding
(binding-name, version-history)>
<!ELEMENT binding-name (#PCDATA)>
PCDATA value: URL segment
<!ELEMENT version-history (href)>
<!ELEMENT version-controlled-binding-set (version-controlled-binding*)> <!ELEMENT version-controlled-binding (binding-name, version-history)> <!ELEMENT binding-name (#PCDATA)> PCDATA value: URL segment <!ELEMENT version-history (href)>
14.3 Additional OPTIONS Semantics
14.3 Additional OPTIONS Semantics
If the server supports the version-controlled-collection feature, it MUST include "version-controlled-collection" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
If the server supports the version-controlled-collection feature, it MUST include "version-controlled-collection" as a field in the DAV response header from an OPTIONS request on any resource that supports any versioning properties, reports, or methods.
14.4 Additional DELETE Semantics
14.4 Additional DELETE Semantics
Additional Preconditions:
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the request-URL
identifies a version-controlled resource, the DELETE MUST fail
when the collection containing the version-controlled resource is
a checked-in version-controlled collection, unless DAV:auto-
version semantics will automatically check out the version-
controlled collection.
(DAV:cannot-modify-checked-in-parent): If the request-URL identifies a version-controlled resource, the DELETE MUST fail when the collection containing the version-controlled resource is a checked-in version-controlled collection, unless DAV:auto- version semantics will automatically check out the version- controlled collection.
Clemm, et al. Standards Track [Page 103] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 103] RFC 3253 Versioning Extensions to WebDAV March 2002
14.5 Additional MKCOL Semantics
14.5 Additional MKCOL Semantics
Additional Preconditions:
Additional Preconditions:
If the request creates a new resource that is automatically placed
under version control, all preconditions for VERSION-CONTROL apply
to the request.
If the request creates a new resource that is automatically placed under version control, all preconditions for VERSION-CONTROL apply to the request.
Additional Postconditions:
Additional Postconditions:
If the new collection is automatically put under version control,
all postconditions for VERSION-CONTROL apply to the request.
If the new collection is automatically put under version control, all postconditions for VERSION-CONTROL apply to the request.
14.6 Additional COPY Semantics
14.6 Additional COPY Semantics
Additional Preconditions:
Additional Preconditions:
(DAV:cannot-copy-collection-version): If the source of the request
is a collection version, the request MUST fail.
(DAV:cannot-copy-collection-version): If the source of the request is a collection version, the request MUST fail.
14.7 Additional MOVE Semantics
14.7 Additional MOVE Semantics
Additional Preconditions:
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the source of the
request is a version-controlled resource, the request MUST fail
when the collection containing the source is a checked-in
version-controlled collection, unless DAV:auto-version semantics
will automatically check out that version-controlled collection.
(DAV:cannot-modify-checked-in-parent): If the source of the request is a version-controlled resource, the request MUST fail when the collection containing the source is a checked-in version-controlled collection, unless DAV:auto-version semantics will automatically check out that version-controlled collection.
(DAV:cannot-modify-destination-checked-in-parent): If the source
of the request is a version-controlled resource, the request MUST
fail when the collection containing the destination is a checked-
in version-controlled collection, unless DAV:auto-version
semantics will automatically check out that version-controlled
collection.
(DAV:cannot-modify-destination-checked-in-parent): If the source of the request is a version-controlled resource, the request MUST fail when the collection containing the destination is a checked- in version-controlled collection, unless DAV:auto-version semantics will automatically check out that version-controlled collection.
14.8 Additional VERSION-CONTROL Semantics
14.8 Additional VERSION-CONTROL Semantics
Additional Preconditions:
Additional Preconditions:
(DAV:cannot-modify-checked-in-parent): If the parent of the
request-URL is a checked-in version-controlled collection, the
request MUST fail unless DAV:auto-version semantics will
automatically check out that version-controlled collection.
(DAV:cannot-modify-checked-in-parent): If the parent of the request-URL is a checked-in version-controlled collection, the request MUST fail unless DAV:auto-version semantics will automatically check out that version-controlled collection.
Clemm, et al. Standards Track [Page 104] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 104] RFC 3253 Versioning Extensions to WebDAV March 2002
Additional Postconditions:
Additional Postconditions:
(DAV:new-version-controlled-collection): If the request body
identified a collection version, the collection at the request-URL
MUST contain a version-controlled internal member for each
DAV:version-controlled-binding specified in the DAV:version-
controlled-binding-set of the collection version, where the name
and DAV:version-history of the internal member MUST be the
DAV:binding-name and the DAV:version-history specified by the
DAV:version-controlled-binding. If the internal member is a
member of a workspace, and there is another member of the
workspace for the same version history, those two members MUST
identify the same version-controlled resource; otherwise, a
VERSION-CONTROL request with a server selected version of the
version history MUST have been applied to the URL for that
internal member.
(DAV:new-version-controlled-collection): If the request body identified a collection version, the collection at the request-URL MUST contain a version-controlled internal member for each DAV:version-controlled-binding specified in the DAV:version- controlled-binding-set of the collection version, where the name and DAV:version-history of the internal member MUST be the DAV:binding-name and the DAV:version-history specified by the DAV:version-controlled-binding. If the internal member is a member of a workspace, and there is another member of the workspace for the same version history, those two members MUST identify the same version-controlled resource; otherwise, a VERSION-CONTROL request with a server selected version of the version history MUST have been applied to the URL for that internal member.
14.9 Additional CHECKOUT Semantics
14.9 Additional CHECKOUT Semantics
Additional Postconditions:
Additional Postconditions:
(DAV:initialize-version-history-bindings): If the request has been
applied to a collection version, the new working collection MUST
be initialized to contain a binding to each of the history
resources identified in the DAV:version-controlled-binding-set of
that collection version.
(DAV:initialize-version-history-bindings): If the request has been applied to a collection version, the new working collection MUST be initialized to contain a binding to each of the history resources identified in the DAV:version-controlled-binding-set of that collection version.
14.10 Additional CHECKIN Semantics
14.10 Additional CHECKIN Semantics
Additional Postconditions:
Additional Postconditions:
(DAV:initialize-version-controlled-bindings): If the request-URL
identified a version-controlled collection, then the DAV:version-
controlled-binding-set of the new collection version MUST contain
a DAV:version-controlled-binding that identifies the binding name
and version history for each version-controlled binding of the
version- controlled collection.
(DAV:initialize-version-controlled-bindings): If the request-URL identified a version-controlled collection, then the DAV:version- controlled-binding-set of the new collection version MUST contain a DAV:version-controlled-binding that identifies the binding name and version history for each version-controlled binding of the version- controlled collection.
(DAV:version-control-working-collection-members): If the request-
URL identified a working collection, a VERSION-CONTROL request
MUST have been automatically applied to every non-version-
controlled member of the working collection, and each non-
version-controlled member MUST have been replaced by its newly
created version history. If a working collection member was a
non-version-controlled collection, every member of the non-
version-controlled collection MUST have been placed under version
(DAV:version-control-working-collection-members): If the request- URL identified a working collection, a VERSION-CONTROL request MUST have been automatically applied to every non-version- controlled member of the working collection, and each non- version-controlled member MUST have been replaced by its newly created version history. If a working collection member was a non-version-controlled collection, every member of the non- version-controlled collection MUST have been placed under version
Clemm, et al. Standards Track [Page 105] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 105] RFC 3253 Versioning Extensions to WebDAV March 2002
control before the non-version-controlled collection was placed
under version control. The DAV:version-controlled-binding-set of
the new collection version MUST contain a DAV:version-controlled-
binding that identifies the binding name and the version history
URL for each member of the working collection.
control before the non-version-controlled collection was placed under version control. The DAV:version-controlled-binding-set of the new collection version MUST contain a DAV:version-controlled- binding that identifies the binding name and the version history URL for each member of the working collection.
14.11 Additional UPDATE and MERGE Semantics
14.11 Additional UPDATE and MERGE Semantics
Additional Postconditions:
Additional Postconditions:
(DAV:update-version-controlled-collection-members): If the request
modified the DAV:checked-in version of a version-controlled
collection, then the version-controlled members of that version-
controlled collection MUST have been updated. In particular:
(DAV:update-version-controlled-collection-members): If the request modified the DAV:checked-in version of a version-controlled collection, then the version-controlled members of that version- controlled collection MUST have been updated. In particular:
- A version-controlled internal member MUST have been deleted if
its version history is not identified by the DAV:version-
controlled-binding-set of the new DAV:checked-in version.
- A version-controlled internal member for a given version
history MUST have been renamed if its binding name differs from
the DAV:binding-name for that version history in the
DAV:version-controlled-binding-set of the new DAV:checked-in
version.
- A new version-controlled internal member MUST have been created
when a version history is identified by the DAV:version-
controlled-binding-set of the DAV:checked-in version, but there
was no member of the version-controlled collection for that
version history. If a new version-controlled member is in a
workspace that already has a version-controlled resource for
that version history, then the new version-controlled member
MUST be just a binding (i.e., another name for) that existing
version-controlled resource. Otherwise, the content and dead
properties of the new version-controlled member MUST have been
initialized to be those of the version specified for that
version history by the request. If no version is specified for
that version history by the request, the version selected is
server defined.
- A version-controlled internal member MUST have been deleted if its version history is not identified by the DAV:version- controlled-binding-set of the new DAV:checked-in version. - A version-controlled internal member for a given version history MUST have been renamed if its binding name differs from the DAV:binding-name for that version history in the DAV:version-controlled-binding-set of the new DAV:checked-in version. - A new version-controlled internal member MUST have been created when a version history is identified by the DAV:version- controlled-binding-set of the DAV:checked-in version, but there was no member of the version-controlled collection for that version history. If a new version-controlled member is in a workspace that already has a version-controlled resource for that version history, then the new version-controlled member MUST be just a binding (i.e., another name for) that existing version-controlled resource. Otherwise, the content and dead properties of the new version-controlled member MUST have been initialized to be those of the version specified for that version history by the request. If no version is specified for that version history by the request, the version selected is server defined.
15 Internationalization Considerations
15 Internationalization Considerations
This specification has been designed to be compliant with the IETF Policy on Character Sets and Languages [RFC2277]. Specifically, where human-readable strings exist in the protocol, either their charset is explicitly stated, or XML mechanisms are used to specify the charset used. Additionally, these human-readable strings all have the ability to express the natural language of the string.
This specification has been designed to be compliant with the IETF Policy on Character Sets and Languages [RFC2277]. Specifically, where human-readable strings exist in the protocol, either their charset is explicitly stated, or XML mechanisms are used to specify the charset used. Additionally, these human-readable strings all have the ability to express the natural language of the string.
Clemm, et al. Standards Track [Page 106] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 106] RFC 3253 Versioning Extensions to WebDAV March 2002
Most of the human-readable strings in this protocol appear in properties, such as DAV:creator-displayname. As defined by RFC 2518, properties have their values marshaled as XML. XML has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC2279] encoding of the ISO 10646 multilingual plane. The charset parameter of the Content-Type header, together with the XML "encoding" attribute, provide charset identification information for MIME and XML processors. Proper use of the charset header with XML is described in RFC 3023. XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. XML uses either IANA registered language tags (see RFC 3066) or ISO 639 language tags in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.
Most of the human-readable strings in this protocol appear in properties, such as DAV:creator-displayname. As defined by RFC 2518, properties have their values marshaled as XML. XML has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [RFC2279] encoding of the ISO 10646 multilingual plane. The charset parameter of the Content-Type header, together with the XML "encoding" attribute, provide charset identification information for MIME and XML processors. Proper use of the charset header with XML is described in RFC 3023. XML also provides a language tagging capability for specifying the language of the contents of a particular XML element. XML uses either IANA registered language tags (see RFC 3066) or ISO 639 language tags in the "xml:lang" attribute of an XML element to identify the language of its content and attributes.
DeltaV applications, since they build upon WebDAV, are subject to the internationalization requirements specified in RFC 2518, Section 16. In brief, these requirements mandate the use of XML character set tagging, character set encoding, and language tagging capabilities. Additionally, they strongly recommend reading RFC 3023 for instruction on the use of MIME media types for XML transport and the use of the charset header.
DeltaV applications, since they build upon WebDAV, are subject to the internationalization requirements specified in RFC 2518, Section 16. In brief, these requirements mandate the use of XML character set tagging, character set encoding, and language tagging capabilities. Additionally, they strongly recommend reading RFC 3023 for instruction on the use of MIME media types for XML transport and the use of the charset header.
Within this specification, a label is a human-readable string that is marshaled in the Label header and as XML in request entity bodies. When used in the Label header, the value of the label is URL-escaped and encoded using UTF-8.
Within this specification, a label is a human-readable string that is marshaled in the Label header and as XML in request entity bodies. When used in the Label header, the value of the label is URL-escaped and encoded using UTF-8.
16 Security Considerations
16 Security Considerations
All of the security considerations of WebDAV discussed in RFC 2518, Section 17 also apply to WebDAV versioning. Some aspects of the versioning protocol help address security risks introduced by WebDAV, but other aspects can increase these security risks. These issues are detailed below.
All of the security considerations of WebDAV discussed in RFC 2518, Section 17 also apply to WebDAV versioning. Some aspects of the versioning protocol help address security risks introduced by WebDAV, but other aspects can increase these security risks. These issues are detailed below.
16.1 Auditing and Traceability
16.1 Auditing and Traceability
WebDAV increases the ease with which a remote client can modify resources on a web site, but this also increases the risk of important information being overwritten and lost, either through user error or user maliciousness. The use of WebDAV versioning can help address this problem by guaranteeing that previous information is saved in the form of immutable versions, and therefore is easily available for retrieval or restoration. In addition, the version history provides a log of when changes were made, and by whom. When requests are appropriately authenticated, the history mechanism
WebDAV increases the ease with which a remote client can modify resources on a web site, but this also increases the risk of important information being overwritten and lost, either through user error or user maliciousness. The use of WebDAV versioning can help address this problem by guaranteeing that previous information is saved in the form of immutable versions, and therefore is easily available for retrieval or restoration. In addition, the version history provides a log of when changes were made, and by whom. When requests are appropriately authenticated, the history mechanism
Clemm, et al. Standards Track [Page 107] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 107] RFC 3253 Versioning Extensions to WebDAV March 2002
provides a clear audit trail for changes to web resources. This can often significantly improve the ability to identify the source of the security problem, and thereby help guard against it in the future.
provides a clear audit trail for changes to web resources. This can often significantly improve the ability to identify the source of the security problem, and thereby help guard against it in the future.
16.2 Increased Need for Access Control
16.2 Increased Need for Access Control
WebDAV versioning provides a variety of links between related pieces of information. This can increase the risk that authentication or authorization errors allow a client to locate sensitive information. For example, if version history is not appropriately protected by access control, a client can use the version history of a public resource to identify later versions of that resource that the user intended to keep private. This increases the need for reliable authentication and accurate authorization.
WebDAV versioning provides a variety of links between related pieces of information. This can increase the risk that authentication or authorization errors allow a client to locate sensitive information. For example, if version history is not appropriately protected by access control, a client can use the version history of a public resource to identify later versions of that resource that the user intended to keep private. This increases the need for reliable authentication and accurate authorization.
A WebDAV versioning client should be designed to handle a mixture of 200 (OK) and 403 (Forbidden) responses on attempts to access the properties and reports that are supported by a resource. For example, a particular user may be authorized to access the content and dead properties of a version-controlled resource, but not be authorized to access the DAV:checked-in, DAV:checked-out, or DAV:version-history properties of that resource.
A WebDAV versioning client should be designed to handle a mixture of 200 (OK) and 403 (Forbidden) responses on attempts to access the properties and reports that are supported by a resource. For example, a particular user may be authorized to access the content and dead properties of a version-controlled resource, but not be authorized to access the DAV:checked-in, DAV:checked-out, or DAV:version-history properties of that resource.
16.3 Security Through Obscurity
16.3 Security Through Obscurity
While it is acknowledged that "obscurity" is not an effective means of security, it is often a good technique to keep honest people honest. Within this protocol, version URLs, version history URLs, and working resource URLs are generated by the server and can be properly obfuscated so as not to draw attention to them. For example, a version of "http://foobar.com/reviews/salaries.html" might be assigned a URL such as "http://foobar.com/repo/4934943".
While it is acknowledged that "obscurity" is not an effective means of security, it is often a good technique to keep honest people honest. Within this protocol, version URLs, version history URLs, and working resource URLs are generated by the server and can be properly obfuscated so as not to draw attention to them. For example, a version of "http://foobar.com/reviews/salaries.html" might be assigned a URL such as "http://foobar.com/repo/4934943".
16.4 Denial of Service
16.4 Denial of Service
The auto-versioning mechanism provided by WebDAV can result in a large number of resources being created on the server, since each update to a resource could potentially result in the creation of a new version resource. This increases the risk of a denial of service attack that exhausts the storage capability of a server. This risk is especially significant because it can be an unintentional result of something like an aggressive auto-save feature provided by an editing client. A server can decrease this risk by using delta storage techniques to minimize the cost of additional versions, and by limiting auto-versioning to a locking client, and thereby decreasing the number of inadvertent version creations.
The auto-versioning mechanism provided by WebDAV can result in a large number of resources being created on the server, since each update to a resource could potentially result in the creation of a new version resource. This increases the risk of a denial of service attack that exhausts the storage capability of a server. This risk is especially significant because it can be an unintentional result of something like an aggressive auto-save feature provided by an editing client. A server can decrease this risk by using delta storage techniques to minimize the cost of additional versions, and by limiting auto-versioning to a locking client, and thereby decreasing the number of inadvertent version creations.
Clemm, et al. Standards Track [Page 108] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 108] RFC 3253 Versioning Extensions to WebDAV March 2002
17 IANA Considerations
17 IANA Considerations
This document uses the namespace defined by RFC 2518 for XML elements. All other IANA considerations from RFC 2518 are also applicable to WebDAV Versioning.
This document uses the namespace defined by RFC 2518 for XML elements. All other IANA considerations from RFC 2518 are also applicable to WebDAV Versioning.
18 Intellectual Property
18 Intellectual Property
The following notice is copied from RFC 2026, Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.
The following notice is copied from RFC 2026, Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the procedures of the IETF with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the procedures of the IETF with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
19 Acknowledgements
19 Acknowledgements
This protocol is the collaborative product of the authors and the rest of the DeltaV design team: Boris Bokowski, Bruce Cragun (Novell), Jim Doubek (Macromedia), David Durand (INSO), Lisa Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark Hale (Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI), Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi), Eric Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John Vasta (Rational). We would like to acknowledge the foundation laid for us by the authors of the WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV and DeltaV working groups.
This protocol is the collaborative product of the authors and the rest of the DeltaV design team: Boris Bokowski, Bruce Cragun (Novell), Jim Doubek (Macromedia), David Durand (INSO), Lisa Dusseault (Xythos), Chuck Fay (FileNet), Yaron Goland, Mark Hale (Interwoven), Henry Harbury (Merant), James Hunt, Jeff McAffer (OTI), Peter Raymond (Merant), Juergen Reuter, Edgar Schwarz (Marconi), Eric Sedlar (Oracle), Bradley Sergeant, Greg Stein, and John Vasta (Rational). We would like to acknowledge the foundation laid for us by the authors of the WebDAV and HTTP protocols upon which this protocol is layered, and the invaluable feedback from the WebDAV and DeltaV working groups.
Clemm, et al. Standards Track [Page 109] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 109] RFC 3253 Versioning Extensions to WebDAV March 2002
20 References
20 References
[ISO639] ISO, "Code for the representation of names of languages",
ISO 639:1988, 1998.
[ISO639] ISO, "Code for the representation of names of languages", ISO 639:1988, 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
Jensen, "HTTP Extensions for Distributed Authoring -
WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring - WEBDAV", RFC 2518, February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T.Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
Clemm, et al. Standards Track [Page 110] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 110] RFC 3253 Versioning Extensions to WebDAV March 2002
Appendix A - Resource Classification
Appendix A - Resource Classification
This document introduces several different kinds of versioning resources, such as version-controlled resources, versions, checked- out resources, and version history resources. As clients discover resources on a server, they may find it useful to classify those resources (for example, to make UI decisions on choice of icon and menu options).
This document introduces several different kinds of versioning resources, such as version-controlled resources, versions, checked- out resources, and version history resources. As clients discover resources on a server, they may find it useful to classify those resources (for example, to make UI decisions on choice of icon and menu options).
Clients should classify a resource by examining the values of the DAV:supported-method-set (see Section 3.1.3) and DAV:supported-live- property-set (see Section 3.1.4) properties of that resource.
Clients should classify a resource by examining the values of the DAV:supported-method-set (see Section 3.1.3) and DAV:supported-live- property-set (see Section 3.1.4) properties of that resource.
The following list shows the supported live properties and methods for each kind of versioning resource. Where an optional feature introduces a new kind of versioning resource, that feature is noted in parentheses following the name of that kind of versioning resource. If a live property or method is optional for a kind of versioning resource, the feature that introduces that live property or method is noted in parentheses following the live property or method name.
The following list shows the supported live properties and methods for each kind of versioning resource. Where an optional feature introduces a new kind of versioning resource, that feature is noted in parentheses following the name of that kind of versioning resource. If a live property or method is optional for a kind of versioning resource, the feature that introduces that live property or method is noted in parentheses following the live property or method name.
A.1 DeltaV-Compliant Unmapped URL (a URL that identifies no resource)
A.1 DeltaV-Compliant Unmapped URL (a URL that identifies no resource)
Supported methods:
Supported methods:
- PUT [RFC2616] - MKCOL [RFC2518] - MKACTIVITY (activity) - VERSION-CONTROL (workspace) - MKWORKSPACE (workspace)
- PUT [RFC2616] - MKCOL [RFC2518] - MKACTIVITY (activity) - VERSION-CONTROL (workspace) - MKWORKSPACE (workspace)
A.2 DeltaV-Compliant Resource
A.2 DeltaV-Compliant Resource
Supported live properties:
Supported live properties:
- DAV:comment - DAV:creator-displayname - DAV:supported-method-set - DAV:supported-live-property-set - DAV:supported-report-set - all properties defined in WebDAV [RFC2518].
- DAV:comment - DAV:creator-displayname - DAV:supported-method-set - DAV:supported-live-property-set - DAV:supported-report-set - all properties defined in WebDAV [RFC2518].
Clemm, et al. Standards Track [Page 111] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 111] RFC 3253 Versioning Extensions to WebDAV March 2002
Supported methods:
Supported methods:
- REPORT - all methods defined in WebDAV [RFC2518] - all methods defined in HTTP/1.1 [RFC2616].
- REPORT - all methods defined in WebDAV [RFC2518] - all methods defined in HTTP/1.1 [RFC2616].
A.3 DeltaV-Compliant Collection
A.3 DeltaV-Compliant Collection
Supported live properties:
Supported live properties:
- all DeltaV-compliant resource properties.
- all DeltaV-compliant resource properties.
Supported methods:
Supported methods:
- BASELINE-CONTROL (baseline) - all DeltaV-compliant resource methods.
- BASELINE-CONTROL (baseline) - all DeltaV-compliant resource methods.
A.4 Versionable Resource
A.4 Versionable Resource
Supported live properties:
Supported live properties:
- DAV:workspace (workspace) - DAV:version-controlled-configuration (baseline) - all DeltaV-compliant resource properties.
- DAV:workspace (workspace) - DAV:version-controlled-configuration (baseline) - all DeltaV-compliant resource properties.
Supported methods:
Supported methods:
- VERSION-CONTROL - all DeltaV-compliant resource methods.
- VERSION-CONTROL - all DeltaV-compliant resource methods.
A.5 Version-Controlled Resource
A.5 Version-Controlled Resource
Supported live properties:
Supported live properties:
- DAV:auto-version - DAV:version-history (version-history) - DAV:workspace (workspace) - DAV:version-controlled-configuration (baseline) - all DeltaV-compliant resource properties.
- DAV:auto-version - DAV:version-history (version-history) - DAV:workspace (workspace) - DAV:version-controlled-configuration (baseline) - all DeltaV-compliant resource properties.
Supported methods:
Supported methods:
- VERSION-CONTROL - MERGE (merge) - all DeltaV-compliant resource methods.
- VERSION-CONTROL - MERGE (merge) - all DeltaV-compliant resource methods.
Clemm, et al. Standards Track [Page 112] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 112] RFC 3253 Versioning Extensions to WebDAV March 2002
A.6 Version
A.6 Version
Supported live properties:
Supported live properties:
- DAV:predecessor-set - DAV:successor-set - DAV:checkout-set - DAV:version-name - DAV:checkout-fork (in-place-checkout or working resource) - DAV:checkin-fork (in-place-checkout or working resource) - DAV:version-history (version-history) - DAV:label-name-set (label) - DAV:activity-set (activity) - all DeltaV-compliant resource properties.
- DAV:predecessor-set - DAV:successor-set - DAV:checkout-set - DAV:version-name - DAV:checkout-fork (in-place-checkout or working resource) - DAV:checkin-fork (in-place-checkout or working resource) - DAV:version-history (version-history) - DAV:label-name-set (label) - DAV:activity-set (activity) - all DeltaV-compliant resource properties.
Supported methods:
Supported methods:
- LABEL (label) - CHECKOUT (working-resource) - all DeltaV-compliant resource methods.
- LABEL (label) - CHECKOUT (working-resource) - all DeltaV-compliant resource methods.
A.7 Checked-In Version-Controlled Resource
A.7 Checked-In Version-Controlled Resource
Supported live properties:
Supported live properties:
- DAV:checked-in - all version-controlled resource properties.
- DAV:checked-in - all version-controlled resource properties.
Supported methods:
Supported methods:
- CHECKOUT (checkout-in-place) - UPDATE (update) - all version-controlled resource methods.
- CHECKOUT (checkout-in-place) - UPDATE (update) - all version-controlled resource methods.
A.8 Checked-Out Resource
A.8 Checked-Out Resource
Supported live properties:
Supported live properties:
- DAV:checked-out - DAV:predecessor-set - DAV:checkout-fork (in-place-checkout or working resource) - DAV:checkin-fork (in-place-checkout or working resource) - DAV:merge-set (merge) - DAV:auto-merge-set (merge) - DAV:unreserved (activity) - DAV:activity-set (activity)
- DAV:checked-out - DAV:predecessor-set - DAV:checkout-fork (in-place-checkout or working resource) - DAV:checkin-fork (in-place-checkout or working resource) - DAV:merge-set (merge) - DAV:auto-merge-set (merge) - DAV:unreserved (activity) - DAV:activity-set (activity)
Clemm, et al. Standards Track [Page 113] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 113] RFC 3253 Versioning Extensions to WebDAV March 2002
Supported methods:
Supported methods:
- CHECKIN (checkout-in-place or working-resource) - all DeltaV-compliant resource methods.
- CHECKIN (checkout-in-place or working-resource) - all DeltaV-compliant resource methods.
A.9 Checked-Out Version-Controlled Resource (checkout-in-place)
A.9 Checked-Out Version-Controlled Resource (checkout-in-place)
Supported live properties:
Supported live properties:
- all version-controlled resource properties. - all checked-out resource properties.
- all version-controlled resource properties. - all checked-out resource properties.
Supported methods:
Supported methods:
- UNCHECKOUT - all version-controlled resource methods. - all checked-out resource methods.
- UNCHECKOUT - all version-controlled resource methods. - all checked-out resource methods.
A.10 Working Resource (working-resource)
A.10 Working Resource (working-resource)
Supported live properties:
Supported live properties:
- all DeltaV-compliant resource properties - all checked-out resource properties - DAV:auto-update.
- all DeltaV-compliant resource properties - all checked-out resource properties - DAV:auto-update.
Supported methods:
Supported methods:
- all checked-out resource methods.
- all checked-out resource methods.
A.11 Version History (version-history)
A.11 Version History (version-history)
Supported live properties:
Supported live properties:
- DAV:version-set - DAV:root-version - all DeltaV-compliant resource properties.
- DAV:version-set - DAV:root-version - all DeltaV-compliant resource properties.
Supported methods:
Supported methods:
- all DeltaV-compliant resource methods.
- all DeltaV-compliant resource methods.
Clemm, et al. Standards Track [Page 114] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 114] RFC 3253 Versioning Extensions to WebDAV March 2002
A.12 Workspace (workspace)
A.12 Workspace (workspace)
Supported live properties:
Supported live properties:
- DAV:workspace-checkout-set - DAV:baseline-controlled-collection-set (baseline) - DAV:current-activity-set (activity) - all DeltaV-compliant collection properties.
- DAV:workspace-checkout-set - DAV:baseline-controlled-collection-set (baseline) - DAV:current-activity-set (activity) - all DeltaV-compliant collection properties.
Supported methods:
Supported methods:
- all DeltaV-compliant collection methods.
- all DeltaV-compliant collection methods.
A.13 Activity (activity)
A.13 Activity (activity)
Supported live properties:
Supported live properties:
- DAV:activity-version-set - DAV:activity-checkout-set - DAV:subactivity-set - DAV:current-workspace-set - all DeltaV-compliant resource properties.
- DAV:activity-version-set - DAV:activity-checkout-set - DAV:subactivity-set - DAV:current-workspace-set - all DeltaV-compliant resource properties.
Supported methods:
Supported methods:
- all DeltaV-compliant resource methods.
- all DeltaV-compliant resource methods.
A.14 Version-Controlled Collection (version-controlled-collection)
A.14 Version-Controlled Collection (version-controlled-collection)
Supported live properties:
Supported live properties:
- DAV:eclipsed-set - all version-controlled resource properties.
- DAV:eclipsed-set - all version-controlled resource properties.
Supported methods:
Supported methods:
- all version-controlled resource methods.
- all version-controlled resource methods.
A.15 Collection Version (version-controlled-collection)
A.15 Collection Version (version-controlled-collection)
Supported live properties:
Supported live properties:
- DAV:version-controlled-binding-set - all version properties.
- DAV:version-controlled-binding-set - all version properties.
Supported methods:
Supported methods:
- all version methods.
- all version methods.
Clemm, et al. Standards Track [Page 115] RFC 3253 Versioning Extensions to WebDAV March 2002
Clemm, et al. Standards Track [Page 115] RFC 3253 Versioning Extensions to WebDAV March 2002
A.16 Version-Controlled Configuration (baseline)
A.16 Version-Controlled Configuration (baseline)
Supported live properties:
Supported live properties:
- DAV:baseline-controlled-collection - all version-controlled resource properties.
- DAV: 基線は収集を制御しました--すべてのバージョンで制御されたリソースの特性。
Supported methods:
サポートしているメソッド:
- all version-controlled resource methods.
- すべてのバージョンで制御されたリソースメソッド。
A.17 Baseline (baseline)
A.17基線(基線)
Supported live properties:
サポートしている精力の特性:
- DAV:baseline-collection - DAV:subbaseline-set - all version properties.
- DAV: 基線収集--DAV: 「副-基線」でセットしてください--すべてのバージョンの特性。
Supported methods:
サポートしているメソッド:
- all version methods.
- すべてのバージョンメソッド。
A.18 Checked-Out Version-Controlled Configuration (baseline)
A.18はバージョンで制御された構成を調べました。(基線)
Supported live properties:
サポートしている精力の特性:
- DAV:subbaseline-set - all version-controlled configuration properties.
- DAV: 「副-基線」でセットしてください--すべてのバージョンで制御された構成の特性。
Supported methods:
サポートしているメソッド:
- all version-controlled configuration methods.
- すべてのバージョンで制御された構成メソッド。
Clemm, et al. Standards Track [Page 116] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[116ページ]。
Authors' Addresses
作者のアドレス
Geoffrey Clemm Rational Software 20 Maguire Road, Lexington, MA 02421
レキシントン、MA ジェフリークレム合理的なソフトウェア20マグワイア道路、02421
EMail: geoffrey.clemm@rational.com
メール: geoffrey.clemm@rational.com
Jim Amsden IBM 3039 Cornwallis, Research Triangle Park, NC 27709
ジムAmsden IBM3039コーンウォリス、リサーチトライアングル公園、NC 27709
EMail: jamsden@us.ibm.com
メール: jamsden@us.ibm.com
Tim Ellison IBM Hursley Park, Winchester, UK S021 2JN
ティムエリソンIBM Hursley Park、ウィンチェスター、イギリスのS021 2JN
EMail: tim_ellison@uk.ibm.com
メール: tim_ellison@uk.ibm.com
Christopher Kaler Microsoft One Microsoft Way, Redmond, WA 90852
レッドモンド、ワシントン クリストファーKalerマイクロソフト1マイクロソフト道、90852
EMail: ckaler@microsoft.com
メール: ckaler@microsoft.com
Jim Whitehead UC Santa Cruz, Dept. of Computer Science 1156 High Street, Santa Cruz, CA 95064
ジム・ホワイトヘッド・UCサンタクルス、1156のHigh通り、コンピュータサイエンスサンタクルス、カリフォルニア 95064人の部
EMail: ejw@cse.ucsc.edu
メール: ejw@cse.ucsc.edu
Clemm, et al. Standards Track [Page 117] RFC 3253 Versioning Extensions to WebDAV March 2002
クレム、他 規格は2002年3月にRFC3253Versioning拡張子をWebDAVに追跡します[117ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Clemm, et al. Standards Track [Page 118]
クレム、他 標準化過程[118ページ]
一覧
スポンサーリンク
