RFC2291 日本語訳
2291 Requirements for a Distributed Authoring and Versioning Protocolfor the World Wide Web. J. Slein, F. Vitali, E. Whitehead, D. Durand. February 1998. (Format: TXT=44036 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Slein
Request for Comments: 2291 Xerox Corporation
Category: Informational F. Vitali
University of Bologna
E. Whitehead
U.C. Irvine
D. Durand
Boston University
February 1998
Sleinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2291年のゼロックス社のカテゴリ: ボローニャE.ホワイトヘッドU.C.アーバインD.ジュランドボストン大学1998年2月の情報のF.ヴィターリ大学
Requirements for a Distributed Authoring and Versioning
Protocol for the World Wide Web
分配されたオーサリングのための要件とWWWのためのVersioningプロトコル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW.
現在のWWW(WWWかウェブ)規格はタイプされたデータのリモート編集を許すアプリケーションの簡単なサポートを提供します。 実際には、WWWの既存の能力は闘争を上書きするのを有でない効率的で、スケーラブルなリモート編集をサポートするために不十分であると判明しました。 このドキュメントは実装されるなら一般的なリモート編集操作の効率を高めるウェブDistributed AuthoringとVersioningプロトコルのための要件の形に特徴のリストを提示します、そして、施錠装置を提供して、重ね書き闘争を防いでください、非HTMLデータ型の間のリンク管理サポートを改良してください、そして、簡単な属性値メタデータ施設を提供してください、そして、コンテナデータ型の作成と読書に備えてください、そして、WWWにversioningしながら、統合してください。
1. Introduction
1. 序論
This document describes functionality which, if incorporated in an extension to the existing HTTP proposed standard [HTTP], would allow tools for remote loading, editing and saving (publishing) of various media types on the WWW to interoperate with any compliant Web server. As much as possible, this functionality is described without suggesting a proposed implementation, since there are many ways to perform the functionality within the WWW framework. It is also
このドキュメントはリモートローディングのために既存のHTTP提案された標準[HTTP]への拡大に取り入れられるならツールを許容する機能性について説明します、どんな対応するウェブサーバでも共同利用するためにWWWで様々なメディアタイプの(出版)を編集して、貯蓄して。提案された実装を示さないで、できるだけ、この機能性は説明されます、WWWフレームワークの中で機能性を実行する多くの方法があるので。 また、それはそうです。
Slein, et. al. Informational [Page 1] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[1ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
possible that a single mechanism could simultaneously satisfy several requirements.
ただ一つのメカニズムが同時にいくつかの要件を満たすかもしれないのが可能です。
This document reflects the consensus of the WWW Distributed Authoring and Versioning working group (WebDAV) as to the functionality that should be standardized to support distributed authoring and versioning on the Web. As with any set of requirements, practical considerations may make it impossible to satisfy them all. It is the intention of the WebDAV working group to come as close as possible to satisfying them in the specifications that make up the WebDAV protocol.
このドキュメントは分配されたオーサリングをサポートするために標準化されて、ウェブでversioningされるべきである機能性に関してWWW Distributed AuthoringとVersioningワーキンググループ(WebDAV)のコンセンサスを反映します。 どんなセットの要件ならも、実用的な問題で、それらを皆、満たすのは不可能になるかもしれません。 WebDAVプロトコルを作るのは、WebDAVワーキンググループができるだけ仕様でそれらを満たすことの近くに来るという意志です。
2. Rationale
2. 原理
Current Web standards contain functionality which enables the editing of Web content at a remote location, without direct access to the storage media via an operating system. This capability is exploited by several existing HTML distributed authoring tools, and by a growing number of mainstream applications (e.g., word processors) which allow users to write (publish) their work to an HTTP server. To date, experience from the HTML authoring tools has shown they are unable to meet their users' needs using the facilities of Web standards. The consequence of this is either postponed introduction of distributed authoring capability, or the addition of nonstandard extensions to the HTTP protocol or other Web standards. These extensions, developed in isolation, are not interoperable.
現在のウェブ規格は離れた場所でウェブ内容の編集を可能にする機能性を含んでいます、オペレーティングシステムを通した記憶媒体への直接アクセスなしで。 この能力は既存のHTMLが会うためにオーサリングツールを分配して、ユーザがHTMLオーサリングツールからの. Toが日付を入れるHTTPサーバ、経験に彼らの仕事を書くことができる(発行します)増加している数の主流のアプリケーション(例えば、ワードプロセッサ)でそれらであることができないことを示した数個によって利用されて、彼らのユーザのものが、ウェブ規格の施設を使用する必要があるということです。 この結果は、HTTPプロトコルか他のウェブ規格への分配された書いている能力の延期された導入か標準的でない拡大の追加のどちらかです。 分離して発生するこれらの拡大は共同利用できません。
Other authoring applications have wanted to access document repositories or version control systems through Web gateways, and have been similarly frustrated. Where this access is available at all, it is through nonstandard extensions to HTTP or other standards that force clients to use a different interface for each vendor's service.
他のオーサリングアプリケーションは、ウェブゲートウェイを通して文書収納庫かバージョン管理システムにアクセスしたくて、同様にだめにされました。 このアクセスが全く利用可能であるところでは、HTTPへの標準的でない拡大か他の規格を通して、クライアントに各ベンダーのサービスに異なったインタフェースを使用させてください。
This document describes requirements for a set of standard extensions to HTTP that would allow distributed Web authoring tools to provide the functionality their users need by means of the same standard syntax across all compliant servers. The broad categories of functionality that need to be standardized are:
このドキュメントは彼らのユーザがすべての対応するサーバの向こう側の同じ標準の構文によって必要とする機能性を提供する分配されたウェブ開発ツールを許容するHTTPに1セットの標準の拡大のための要件について説明します。 標準化される必要がある機能性の広いカテゴリは以下の通りです。
Properties
Links
Locking
Reservations
Retrieval of Unprocessed Source
Partial Write
Name Space Manipulation
Collections
未加工のソース部分的の予約検索をロックする特性のリンクが名前宇宙操作収集を書きます。
Slein, et. al. Informational [Page 2] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[2ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
Versioning
Variants
Security
Internationalization
異形セキュリティ国際化をVersioningします。
3. Terminology
3. 用語
Where there is overlap, usage is intended to be consistent with that in the HTTP 1.1 specification [HTTP].
オーバラップがあるところでは、用法がHTTP1.1仕様[HTTP]でそれと一致させていることを意図します。
Client
A program which issues HTTP requests and accepts responses.
HTTPを発行するクライアントAプログラムが、応答を要求して、受け入れます。
Collection
A collection is a resource that contains other resources, either
directly or by reference.
収集A収集は直接か参照で他のリソースを含むリソースです。
Distributed Authoring Tool
A program which can retrieve a source entity via HTTP, allow
editing of this entity, and then save/publish this entity to a
server using HTTP.
分配されたAuthoring Tool Aはプログラムを作ります(次に、HTTPを使用することでこの実体をサーバにHTTPでソース実体を検索して、編集するのをこの実体を許容して、保存するか、または発行できます)。
Entity
The information transferred in a request or response.
情報が要求か応答で移した実体。
Hierarchical Collection
A hierarchical organization of resources. A hierarchical
collection is a resource that contains other resources,
including collections, either directly or by reference.
リソースの階層的なCollection A階層的な組織。 階層的な収集は直接か参照で収集を含む他のリソースを含むリソースです。
Link
A typed connection between two or more resources.
リンクAは2つ以上のリソースの間の関係をタイプしました。
Lock
A mechanism for preventing anyone other than the owner of the
lock from accessing a resource.
錠の所有者以外のだれでもリソースにアクセスするのを防ぐためにAメカニズムをロックしてください。
Member of Version Graph
A resource that is a node in a version graph, and so is derived
from the resources that precede it in the graph, and is the
basis of those that succeed it.
バージョングラフによるノードであり、したがって、グラフでそれに先行するリソースから得られて、それを引き継ぐものの基礎であるバージョンGraph Aリソースのメンバー。
Property
Named descriptive information about a resource.
リソースの特性のNamedの描写的である情報。
Reservation
A declaration that one intends to edit a resource.
人がリソースを編集するつもりであるという予約A宣言。
Slein, et. al. Informational [Page 3] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[3ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
Resource
A network data object or service that can be identified by a
URI.
リソースAネットワークデータ・オブジェクトかURIで特定できるサービス。
Server
A program which receives and responds to HTTP requests.
HTTP要求に受信して、応じるサーバAプログラム。
User Agent
The client that initiates a request.
ユーザエージェント、要求を開始するクライアント。
Variant
A representation of a resource. A resource may have one or more
representations associated with it at any given time.
リソースの異形A表現。 リソースには、その時々で、それに関連している1つ以上の表現があるかもしれません。
Version Graph
A directed acyclic graph with resources as its nodes, where each
node is derived from its predecessor(s).
バージョンGraph Aはノードとしてリソースで非循環のグラフを指示しました。各ノードはノードで前任者から得られます。
Write Lock
A lock that prevents anyone except its owner from modifying the
resource it applies to.
所有者以外のだれでもそれが申し込むリソースを変更するのを防ぐLock A錠を書いてください。
4. General Principles
4. 綱領
This section describes a set of general principles that the WebDAV extensions should follow. These principles cut across categories of functionality.
このセクションはWebDAV拡張子が従うべきである1セットの綱領について説明します。 これらの原則は機能性のカテゴリを横切りました。
4.1. User Agent Interoperability
4.1. ユーザエージェント相互運用性
All WebDAV clients should be able to work with any WebDAV-compliant HTTP server. It is acceptable for some client/server combinations to provide special features that are not universally available, but the protocol should be sufficient that a basic level of functionality will be universal.
すべてのWebDAVクライアントがどんなWebDAV対応することのHTTPサーバでも働くことができるべきです。それを特徴に提供するいくつかのクライアント/サーバ組み合わせが一般に利用可能ではありませんが、プロトコルが十分であるべきであるので、基礎水準の機能性が普遍的になるのは、許容できます。
4.2. Client Simplicity
4.2. クライアントの簡単さ
The WebDAV extensions should be designed to allow client implementations to be simple.
WebDAV拡張子は、クライアント実装が簡単であることを許容するように設計されるべきです。
Slein, et. al. Informational [Page 4] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[4ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
4.3. Legacy Client Support
4.3. レガシークライアントサポート
It should be possible to implement a WebDAV-compliant server in such a way that it can interoperate with non-WebDAV clients. Such a server would be able to understand any valid HTTP 1.1 request from an ordinary Web client without WebDAV extensions, and to provide a valid HTTP 1.1 response that does not require the client to understand the extensions.
非WebDAVクライアントと共に共同利用できるような方法でWebDAV対応することのサーバを実装するのは可能であるべきです。 そのようなサーバは、WebDAV拡張子なしで普通のウェブクライアントからのどんな有効なHTTP1.1要求も理解して、クライアントが拡大を理解しているのを必要としない有効なHTTP1.1応答を提供できるでしょう。
4.4. Data Format Compatibility
4.4. データの形式の互換性
WebDAV-compliant servers should be able to work with existing resources and URIs [URL]. Special additional information should not become a mandatory part of document formats.
WebDAV対応することのサーバは既存のリソースとURI[URL]で働くことができるべきです。 特別な追加情報はドキュメント・フォーマットの義務的な一部分になるべきではありません。
4.5. Replicated, Distributed Systems
4.5. 模写、分散システム
Distribution and replication are at the heart of the Internet. All WebDAV extensions should be designed to allow for distribution and replication. Version trees should be able to be split across multiple servers. Collections may have members on different servers. Any resource may be cached or replicated for mobile computing or other reasons. Consequently, the WebDAV extensions must be able to operate in a distributed, replicated environment.
分配と模写はインターネットの中心です。 すべてのWebDAV拡張子が、分配と模写を考慮するように設計されるべきです。 バージョン木は複数のサーバの向こう側に分かれさせることができるはずです。 収集には、メンバーが異なったサーバにいるかもしれません。 どんなリソースも、モバイル・コンピューティングか他の理由でキャッシュされるか、または模写されるかもしれません。 その結果、WebDAV拡張子は分配されて、模写された環境で作動できなければなりません。
4.6 Parsimony in Client-Server Interactions
4.6 クライアント/サーバ相互作用におけるけち
The WebDAV extensions should keep to a minimum the number of interactions between the client and the server needed to perform common functions. For example, publishing a document to the Web will often mean publishing content together with related properties. A client may often need to find out what version graph a particular resource belongs to, or to find out which resource in a version graph is the published one. The extensions should make it possible to do these things efficiently.
WebDAV拡張子はクライアントとサーバとの相互作用の数が一般的な機能を実行するために必要とした最小限に保つべきです。 例えば、ドキュメントをウェブに発表するのは、しばしば関連する特性と共に内容を発表することを意味するでしょう。 クライアントは、しばしば特定のリソースがどんなバージョングラフに属すかを見つけるか、またはバージョングラフによるどのリソースが発行されたものであるかを見つける必要があるかもしれません。 拡大で、効率的にこれらのことをするのは可能になるべきです。
4.7. Changes to HTTP
4.7. HTTPへの変化
WebDAV adds a number of new types of objects to the Web: properties, collections, version graphs, etc. Existing HTTP methods such as DELETE and PUT will have to operate in well-defined ways in this expanded environment. WebDAV should explicitly address not only new methods, headers, and MIME types, but also any required changes to the existing HTTP methods and headers.
WebDAVは多くの新しいタイプのオブジェクトをウェブに追加します: 特性、収集、バージョングラフなど DELETEやPUTなどのメソッドがこれで明確な方法で操作しなければならない既存のHTTPは環境を広くしました。 WebDAVは明らかに新しいメソッド、ヘッダー、およびMIMEの種類だけではなく、既存のHTTPメソッドとヘッダーへのどんな必要な変化も扱うはずです。
Slein, et. al. Informational [Page 5] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[5ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
4.8. Alternate Transport Mechanisms
4.8. 代替の移送機構
It may be desirable to transport WebDAV requests and responses by other mechanisms, particularly EMail, in addition to HTTP. The WebDAV protocol specification should not preclude a future body from developing an interoperability specification for disconnected operation via EMail.
HTTPに加えて他のメカニズム、特にEMailによるWebDAV要求と応答を輸送するのは望ましいかもしれません。 WebDAVプロトコル仕様は、EMailを通して切断している操作のための相互運用性仕様を開発するので、将来のボディーを排除するべきではありません。
5. Requirements
5. 要件
In the requirement descriptions below, the requirement will be stated, followed by its rationale.
以下での要件記述では、原理があとに続いていて、要件は述べられるでしょう。
5.1. Properties
5.1. 特性
5.1.1. Functional Requirements
5.1.1. 機能条件書
It must be possible to create, modify, read and delete arbitrary properties on resources of any media type.
どんなメディアタイプに関するリソースの任意の特性も作成して、変更して、読んで、削除するのは可能であるに違いありません。
5.1.2. Rationale
5.1.2. 原理
Properties describe resources of any media type. They may include bibliographic information such as author, title, publisher, and subject, constraints on usage, PICS ratings, etc. These properties have many uses, such as supporting searches on property values, enforcing copyrights, and the creation of catalog entries as placeholders for objects which are not available in electronic form, or which will be available later.
特性はどんなメディアタイプに関するリソースについても説明します。 彼らは作者や、タイトルや、出版社や、対象などの図書目録の情報、用法における規制、PICS格付けなどを含むかもしれません。 これらの特性に、多くの用途があります、特性の値で検索をサポートするのなどように、後で電子申込書で利用可能でないか、または利用可能になるオブジェクトのためのプレースホルダとして著作権、および記入の作成を実施して。
5.2. Links
5.2. リンク
5.2.1. Functional Requirements
5.2.1. 機能条件書
It must be possible to create, modify, read and delete typed links between resources of any media type.
どんなメディアタイプに関するリソースの間のタイプされたリンクを作成して、変更して、読んで、削除するのは可能であるに違いありません。
5.2.2. Rationale
5.2.2. 原理
One type of link between resources is the hypertext link, which is browsable using a hypertext style point-and-click user interface. Links, whether they are browsable hypertext links, or simply a means of capturing a relationship between resources, have many purposes. Links can support pushbutton printing of a multi-resource document in a prescribed order, jumping to the access control page for a resource, and quick browsing of related information, such as a table
リソースの間の1つのタイプのリンクはハイパーテキストリンクです。(そのリンクは、ハイパーテキストスタイルポイントアンドクリックユーザーインタフェースを使用することで「まゆ-可能」です)。 リンクには、それらが「まゆ-可能」ハイパーテキストリンク、または単にリソースの間の関係を得る手段であることにかかわらず多くの目的があります。 リンクは処方されたオーダーにおけるマルチリソースドキュメントのプッシュボタン印刷を支えることができます、リソース、および関連する情報の迅速なブラウジングのためのアクセス制御ページまでジャンプして、テーブルのように
Slein, et. al. Informational [Page 6] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[6ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
of contents, an index, a glossary, a bibliographic record, help pages, etc. While link support is provided by the HTML "LINK" element, this is limited only to HTML resources [HTML]. Similar support is needed for bitmap image types, and other non-HTML media types.
コンテンツ、インデックス、用語集、図書目録の記録、ヘルプページなどについて HTML「リンク」要素でリンクサポートを提供しますが、これをHTMLリソース[HTML]だけに制限します。 同様のサポートがビットマップイメージタイプ、および他の非HTMLメディアタイプに必要です。
5.3. Locking
5.3. ロックします。
5.3.1. General Principles
5.3.1. 綱領
5.3.1.1. Independence of locks. It must be possible to lock a resource without performing an additional retrieval of the resource, and without committing to editing the resource.
5.3.1.1. 錠からの独立。 リソースの追加検索を実行することなしでリソースを編集するのに公約することなしでリソースをロックするのは可能であるに違いありません。
5.3.1.2. Multi-Resource Locking. It must be possible to take out a lock on multiple resources residing on the same server in a single action, and this locking operation must be atomic across these resources.
5.3.1.2. マルチリソースロック。 同じサーバにただ一つの動作である複数のリソースに錠を取り出すのが可能であるに違いなく、このロック作業はこれらのリソースの向こう側に原子であるに違いありません。
5.3.2. Functional Requirements
5.3.2. 機能条件書
5.3.2.1. Write Locks. It must be possible to restrict modification of a resource to a specific person.
5.3.2.1. 錠を書いてください。 リソースの変更を特定の人に制限するのは可能であるに違いありません。
5.3.2.2. Lock Query. It must be possible to find out whether a given resource has any active locks, and if so, who holds those locks.
5.3.2.2. 質問をロックしてください。 与えられたリソースには何かアクティブな錠があるかどうかと、そうだとすれば、だれがそれらの錠を持っているかを見つけるのは可能であるに違いありません。
5.3.2.3. Unlock. It must be possible to remove a lock.
5.3.2.3. アンロックしてください。 錠を取り外すのは可能であるに違いありません。
5.3.3. Rationale
5.3.3. 原理
At present, the Web provides limited support for preventing two or more people from overwriting each other's modifications when they save to a given URI. Furthermore, there is no way to discover whether someone else is currently making modifications to a resource. This is known as the "lost update problem," or the "overwrite problem." Since there can be significant cost associated with discovering and repairing lost modifications, preventing this problem is crucial for supporting distributed authoring. A write lock ensures that only one person may modify a resource, preventing overwrites. Furthermore, locking support is a key component of many versioning schemes, a desirable capability for distributed authoring.
現在のところ、ウェブは与えられたURIに節約すると2人以上の人が互いの変更を上書きするのを防ぐための限定的なサポートを提供します。 その上、他の誰かが現在リソースへの変更をしているかどうか発見する方法が全くありません。 これは「無くなっているアップデート問題」、または「重ね書き問題」として知られています。 無くなっている変更を発見して、修理すると関連している多大な費用があることができるので、分配されたオーサリングをサポートするのに、この問題を防ぐのは重要です。 Aは、重ね書きを防いで、ある人だけがリソースを変更するかもしれないのを確実にすると錠を書きます。 その上、サポートをロックするのは、分配されたオーサリングのために体系、望ましい能力をversioningする多くの主要なコンポーネントです。
An author may wish to lock an entire web of resources even though he is editing just a single resource, to keep the other resources from changing. In this way, an author can ensure that if a local hypertext web is consistent in his distributed authoring tool, it will then be
他のリソースが変化するのを妨げるためにまさしくただ一つのリソースを編集していますが、作者はリソースの全体のウェブをロックしたがっているかもしれません。 このように、作者は、ローカルのハイパーテキストウェブが彼の分配されたオーサリングツールで一貫していると、それがその時あるのを保証できます。
Slein, et. al. Informational [Page 7] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[7ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
consistent when he writes it to the server. Because of this, it should be possible to take out a lock without also causing transmission of the contents of a resource.
彼はサーバにそれを書きます。一貫、これのために、錠を取り出すのは、また、リソースのコンテンツの送信を引き起こしながら、いつなしで可能であるべきですか?
It is often necessary to guarantee that a lock or unlock operation occurs at the same time across multiple resources, a feature which is supported by the multiple-resource locking requirement. This is useful for preventing a collision between two people trying to establish locks on the same set of resources, since with multi- resource locking, one of the two people will get a lock. If this same multiple-resource locking scenario was repeated by using atomic lock operations iterated across the resources, the result would be a splitting of the locks between the two people, based on resource ordering and race conditions.
錠かアンロック操作が同時に複数のリソースの向こう側に現れるのを保証するのがしばしば必要です、複数のリソースロック要件によってサポートされる特徴。 これは同じセットのリソースに錠を設立しようとしながら、差しで衝突を防ぐことの役に立ちます、マルチリソースがロックされている状態で2人の人のひとりが錠を手に入れるので。 この同じ複数のリソースロックシナリオがリソースの向こう側に繰り返された原子ロック操作を使用することによって繰り返されるなら、結果は2人の人の間の錠について分かれることでしょうに、リソース注文と競合条件に基づいて。
5.4. Reservations
5.4. 予約
5.4.1. Functional Requirements
5.4.1. 機能条件書
5.4.1.1. Reserve. It must be possible for a principal to register with the server an intent to edit a given resource, so that other principals can discover who intends to edit the resource.
5.4.1.1. 蓄え。 元本が与えられたリソースを編集する意図をサーバに示すのは、可能であるに違いありません、他の校長が、だれがリソースを編集するつもりであるかを発見できるように。
5.4.1.2. Reservation Query. It must be possible to find out whether a given resource has any active reservations, and if so, who currently holds reservations.
5.4.1.2. 予約質問。 与えられたリソースには何か活発な予約があるかどうかと、そうだとすれば、だれが現在予約を開催するかを見つけるのは可能であるに違いありません。
5.4.1.3. Release Reservation. It must be possible to release the reservation.
5.4.1.3. 予約をリリースしてください。 予約をリリースするのは可能であるに違いありません。
5.4.2. Rationale
5.4.2. 原理
Experience from configuration management systems has shown that people need to know when they are about to enter a parallel editing situation. Once notified, they either decide not to edit in parallel with the other authors, or they use out-of-band communication (face- to-face, telephone, etc.) to coordinate their editing to minimize the difficulty of merging their results. Reservations are separate from locking, since a write lock does not necessarily imply a resource will be edited, and a reservation does not carry with it any access restrictions. This capability supports versioning, since a check-out typically involves taking out a write lock, making a reservation, and getting the resource to be edited.
構成管理システムからの経験は、人々が、彼らがいつ平行な編集状況に入ろうとしているかを知る必要であるのを示しました。 一度通知されています、彼らが他の作者と平行してどんな編集にも決めないか、または彼らがバンドで出ているコミュニケーションを使用する、(表面表面である、電話など) 彼らの結果を合併するという困難を最小にするために彼らの編集を調整するために。 予約はロックから別々です、そして、aが書くので、錠は、リソースが編集されるのを必ず含意するというわけではありません、そして、予約はそれと共に少しのアクセス制限も運びません。 この能力はversioningをサポートします、チェックアウトが、予約をして、錠を書いて、リソースが編集されるのを手に入れながらaを取り出すことを通常伴うので。
Slein, et. al. Informational [Page 8] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[8ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
5.5. Retrieval of Unprocessed Source for Editing
5.5. 編集のための未加工のソースの検索
5.5.1. Functional Requirement
5.5.1. 機能条件書
The source of any given resource must be retrievable by any principal with authorization to edit the resource.
どんな与えられたリソースの源も、リソースを編集するために承認があるどんな主体でも回収可能でなければなりません。
5.5.2. Rationale
5.5.2. 原理
There are many cases where the source stored on a server does not correspond to the actual entity transmitted in response to an HTTP GET. Current known cases are server side include directives, and Standard Generalized Markup Language (SGML) source which is converted on the fly to HyperText Markup Language (HTML) [HTML] output entities. There are many possible cases, such as automatic conversion of bitmap images into several variant bitmap media types (e.g. GIF, JPEG), and automatic conversion of an application's native media type into HTML. As an example of this last case, a word processor could store its native media type on a server which automatically converts it to HTML. A GET of this resource would retrieve the HTML. Retrieving the source would retrieve the word processor native format.
多くのケースがサーバに保存されたソースがHTTP GETに対応して伝えられた実在物に文通しないところにあります。 現在の知られているケースはサーバ側が指示、および急いでハイパーテキストマークアップランゲージ(HTML)[HTML]出力実体に変換されるStandard Generalized Markup Language(SGML)ソースを含んでいるということです。 多くの可能なケースがあります、いくつかの異形ビットマップメディアタイプ(例えば、GIF、JPEG)へのビットマップイメージの自動変換や、アプリケーションの自然なメディアタイプのHTMLへの自動変換などのように。 この最後のケースに関する例として、ワードプロセッサは自動的にそれをHTMLに変換するサーバの自然なメディアタイプを保存するかもしれません。 このリソースのGETはHTMLを検索するでしょう。 ソースを救済すると、ワードプロセッサのネイティブの形式は検索されるでしょう。
5.6. Partial Write.
5.6. 部分的である、書いてください。
5.6.1. Functional Requirement
5.6.1. 機能条件書
After editing a resource, it must be possible to write only the changes to the resource, rather than retransmitting the entire resource.
リソースを編集した後に、全体のリソースを再送するよりむしろリソースへの変更だけを書くのは可能であるに違いありません。
5.6.2. Rationale
5.6.2. 原理
During distributed editing which occurs over wide geographic separations and/or over low bandwidth connections, it is extremely inefficient and frustrating to rewrite a large resource after minor changes, such as a one-character spelling correction. Support is needed for transmitting "insert" (e.g., add this sentence in the middle of a document) and "delete" (e.g. remove this paragraph from the middle of a document) style updates. Support for partial resource updates will make small edits more efficient, and allow distributed authoring tools to scale up for editing large documents.
広い地理的な分離低い帯域幅接続の上に起こる分配された編集の間、マイナーチェンジの後に大きいリソースを書き直すのは、非常に効率が悪くて、いらだたしいです、1キャラクタのスペル修正のように。 サポートが「差し込み」(例えば、ドキュメントの中央でこの文を加える)と「削除(例えば、ドキュメントの中央からこのパラグラフを取り除く)」スタイルアップデートを伝えるのに必要です。 部分的なリソース最新版のサポートは、小さい編集をより効率的にして、分配されたオーサリングツールが大きいドキュメントを編集するために拡大するのを許容するでしょう。
Slein, et. al. Informational [Page 9] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[9ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
5.7. Name Space Manipulation
5.7. 名前宇宙操作
5.7.1. Copy
5.7.1. コピー
5.7.1.1. Functional Requirements
5.7.1.1. 機能条件書
It must be possible to duplicate a resource without a client loading, then resaving the resource. After the copy operation, a modification to either resource must not cause a modification to the other.
リソースがその時再保存する場合、クライアントローディングなしでリソースをコピーするのは可能であるに違いありません。 コピー操作の後に、どちらかのリソースへの変更はもう片方への変更を引き起こしてはいけません。
5.7.1.2. Rationale
5.7.1.2. 原理
There are many reasons why a resource might need to be duplicated, such as changing ownership, preparing for major modifications, or making a backup. Due to network costs associated with loading and saving a resource, it is far preferable to have a server perform a resource copy than a client.
リソースがコピーされる必要があるかもしれない多くの理由があります、所有権を変更するのなどように、主要な変更の用意をするか、またはバックアップを作って。 リソースをロードして、保存すると関連しているネットワークコストのために、サーバにリソースコピーを実行させるのは、クライアントよりはるかに望ましいです。
5.7.2. Move/Rename
5.7.2. /が改名する移動
5.7.2.1. Functional Requirements
5.7.2.1. 機能条件書
It must be possible to change the location of a resource without a client loading, then resaving the resource under a different name. After the move operation, it must no longer be possible to access the resource at its original location.
クライアントローディングなしでリソースの位置を変えるのは可能であるに違いありません、リソースがその時異なった名前の下で再保存して。 移動命令の後に、元の位置でリソースにアクセスするのはもう可能であるはずがありません。
5.7.2.2. Rationale
5.7.2.2. 原理
It is often necessary to change the name of a resource, for example due to adoption of a new naming convention, or if a typing error was made entering the name originally. Due to network costs, it is undesirable to perform this operation by loading, then resaving the resource, followed by a delete of the old resource. Similarly, a single rename operation is more efficient than a copy followed by a delete operation. Note that moving a resource is considered the same function as renaming a resource.
リソースの名前を変えるのがしばしば必要です、例えば、新しい命名規則の採用かそれとも元々名前を入れながらタイプ・ミスをしたかどうかのため。 ネットワークコストのために、古いリソースについてローディングによるこの操作、次に、従われたリソースをaが削除する再保存するのを実行するのは望ましくありません。 同様に、シングルが改名する、操作はaがあとに続いたコピーが操作を削除するより効率的です。 リソースを動かすのがリソースを改名するのと同じ機能であると考えられることに注意してください。
5.8. Collections
5.8. 収集
A collection is a resource that is a container for other resources, including other collections. A resource may belong to a collection either directly or by reference. If a resource belongs to a collection directly, name space operations like copy, move, and delete applied to the collection also apply to the resource. If a resource belongs to a collection by reference, name space operations applied to the collection affect only the reference, not the resource itself.
収集は他の収集を含む他のリソースのためのコンテナであるリソースです。 リソースは直接か参照で収集に属すかもしれません。 また、リソースが直接収集に属すなら、収集に適用されて、同類がコピーして、動いて、削除する名前宇宙作戦はリソースに適用されます。 リソースが参照で収集に属すなら、収集に適用された名前宇宙作戦はリソースではなく、参照自体だけに影響します。
Slein, et. al. Informational [Page 10] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[10ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
5.8.1. Functional Requirements
5.8.1. 機能条件書
5.8.1.1. List Collection. A listing of all resources in a specific collection must be accessible.
5.8.1.1. 収集を記載してください。 特定の収集におけるすべてのリソースのリストは理解できるに違いありません。
5.8.1.2. Make Collection. It must be possible to create a new collection.
5.8.1.2. 収集をしてください。 新しい収集を作成するのは可能であるに違いありません。
5.8.1.3. Add to Collection. It must be possible to add a resource to a collection directly or by reference.
5.8.1.3. 収集の一助となってください。 直接か参照でリソースを収集に追加するのは可能であるに違いありません。
5.8.1.4. Remove from Collection. It must be possible to remove a resource from a collection.
5.8.1.4. 収集から、取り外してください。 収集からリソースを取り除くのは可能であるに違いありません。
5.8.2. Rationale
5.8.2. 原理
In [URL] it states that, "some URL schemes (such as the ftp, http, and file schemes) contain names that can be considered hierarchical." Especially for HTTP servers which directly map all or part of their URL name space into a filesystem, it is very useful to get a listing of all resources located at a particular hierarchy level. This functionality supports "Save As..." dialog boxes, which provide a listing of the entities at a current hierarchy level, and allow navigation through the hierarchy. It also supports the creation of graphical visualizations (typically as a network) of the hypertext structure among the entities at a hierarchy level, or set of levels. It also supports a tree visualization of the entities and their hierarchy levels.
[URL]ではそれを述べる、「いくつかのURL体系(ftpや、httpや、ファイル体系などの)が階層的であると考えることができる名前を含んでいます」。 特に直接それらのURL名前スペースのすべてか一部をファイルシステムに写像するHTTPサーバに、特定の階層構造レベルですべてのリソースのリストを位置させているのは非常に役に立ちます。 サポートが「節約する」この機能性… ダイアログボックス。(そのダイアログボックスは、現在の階層構造レベルで実体のリストを提供して、階層構造にナビゲーションの通ることを許します)。 また、それは階層構造レベル、またはレベルのセットで実体の中でハイパーテキスト構造のグラフィカルなビジュアル化(通常ネットワークとしての)の作成をサポートします。 また、それは、木が実体の想像とそれらの階層構造レベルであるとサポートします。
In addition, document management systems may want to make their documents accessible through the Web. They typically allow the organization of documents into collections, and so also want their users to be able to view the collection hierarchy through the Web.
さらに、ドキュメント管理システムでそれらのドキュメントはウェブを通してアクセスしやすくなりたがっているかもしれません。 また、彼らは、通常ドキュメントの組織の収集に入ることを許して、彼らのユーザにウェブを通して収集階層構造を見ることができて欲しいです。
There are many instances where there is not a strong correlation between a URL hierarchy level and the notion of a collection. One example is a server in which the URL hierarchy level maps to a computational process which performs some resolution on the name. In this case, the contents of the URL hierarchy level can vary depending on the input to the computation, and the number of resources accessible via the computation can be very large. It does not make sense to implement a directory feature for such a name space. However, the utility of listing the contents of those URL hierarchy levels which do correspond to collections, such as the large number of HTTP servers which map their name space to a filesystem, argue for the inclusion of this capability, despite not being meaningful in all
多くのインスタンスがURL階層構造レベルと収集の概念の間に強い相関関係がないところにあります。 1つの例はURL階層構造レベルがコンピュータのプロセスにどれを写像するサーバが名前に何らかの解決を実行するということです。 この場合、計算への入力によって、URL階層構造レベルのコンテンツは異なることができます、そして、計算を通してアクセス可能なリソースの数は非常に大きい場合があります。 それはそのような名前のためのディレクトリ機能を実装する意味をスペースにしません。 しかしながら、それらの名前スペースをファイルシステムに写像する多くのHTTPサーバなどの収集に対応するそれらのURL階層構造レベルのコンテンツを記載するユーティリティはこの能力の包含について賛成の議論をします、全部で重要ではありませんが
Slein, et. al. Informational [Page 11] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[11ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
cases. If listing the contents of a URL hierarchy level does not makes sense for a particular URL, then a "405 Method Not Allowed" status code could be issued.
ケース。 レベルがするURL階層構造のコンテンツを記載するのが特定のURLのために理解できないなら、「メソッドが許容しなかった405」ステータスコードを発行するかもしれません。
The ability to create collections to hold related resources supports management of a name space by packaging its members into small, related clusters. The utility of this capability is demonstrated by the broad implementation of directories in recent operating systems. The ability to create a collection also supports the creation of "Save As..." dialog boxes with "New Level/Folder/Directory" capability, common in many applications.
関連するリソースを保持するために収集を作成する能力は、小さくて、関連するクラスタにメンバーをパッケージすることによって、名前スペースの管理をサポートします。 この能力に関するユーティリティは最近のオペレーティングシステムによるディレクトリの広い実装によって実施説明されます。…ダイアログボックスはまた収集が作成をサポートするaを作成する能力として「新しいレベル/フォルダー/ディレクトリ」能力で「節約されます」、多くのアプリケーションでは、一般的です。
5.9. Versioning
5.9. Versioningします。
5.9.1. Background and General Principles
5.9.1. バックグラウンドと綱領
5.9.1.1. Stability of versions. Most versioning systems are intended to provide an accurate record of the history of evolution of a document. This accuracy is ensured by the fact that a version eventually becomes "frozen" and immutable. Once a version is frozen, further changes will create new versions rather than modifying the original. In order for caching and persistent references to be properly maintained, a client must be able to determine that a version has been frozen. Any successful attempt to retrieve a frozen version of a resource will always retrieve exactly the same content, or return an error if that version (or the resource itself) is no longer available.
5.9.1.1. バージョンの安定性。 ほとんどのversioningシステムがドキュメントの進化史の正確な記録を提供することを意図します。 バージョンが結局「凍っ」て不変になるという事実によってこの精度は確実にされます。 バージョンがいったん凍るようになると、一層の変化はオリジナルを変更するよりむしろ新しいバージョンを作成するでしょう。 適切に維持されるキャッシュしていて永続的な参照において整然とします、クライアントはバージョンが凍っていることを決定できなければなりません。 そのバージョン(または、リソース自体)がもう利用可能でないなら、リソースの凍っているバージョンを検索するどんなうまくいっている試みも、いつもまさに同じ内容を検索するか、または誤りを返すでしょう。
5.9.1.2. Operations for Creating New Versions. Version management systems vary greatly in the operations they require, the order of the operations, and how they are combined into atomic functions. In the most complete cases, the logical operations involved are:
5.9.1.2. 新しいバージョンを作成するための操作。 バージョン管理システムは彼らが必要とする操作、操作と、それらがどう原子機能に結合されるかに関するオーダーで大いに異なります。 最も完全な場合では、かかわった論理演算は以下の通りです。
o Reserve existing version
o Lock existing version
o Retrieve existing version
o Request or suggest identifier for new version
o Write new version
o Release lock
o Release reservation
o 既存のバージョンの既存のバージョンo Retrieve既存のo Lockバージョンo Requestを予約するか、または新しい新しいバージョンのo Releaseロックo Releaseのo Writeバージョン予約のために識別子を示してください。
With the exception of requesting a new version identifier, all of these operations have applications outside of versioning and are either already part of HTTP or are discussed in earlier sections of these requirements. Typically, versioning systems combine reservation, locking, and retrieval -- or some subset of these -- into an atomic checkout function. They combine writing, releasing
新しいバージョン識別子を要求するのを除いて、これらの操作のすべてについて、versioningの外にアプリケーションを持って、既にHTTPの一部であるかこれらの要件の以前のセクションで議論します。 通常、versioningシステムは条件、ロック、および検索(これらの何らかの部分集合)を原子チェックアウト機能に結合します。 彼らは書くこと、リリースを結合します。
Slein, et. al. Informational [Page 12] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[12ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
the lock, and releasing the reservation -- or some subset of these -- into an atomic checkin function. The new version identifier may be assigned either at checkout or at checkin.
錠と、原子チェックイン機能への条件(これらの何らかの部分集合)をリリースすること。 新しいバージョン識別子はチェックアウトにおいて、または、チェックインにおいて割り当てられるかもしれません。
The WebDAV extensions must find some balance between allowing versioning servers to adopt whatever policies they wish with regard to these operations and enforcing enough uniformity to keep client implementations simple.
WebDAV拡張子は、クライアント実装を簡単に保つために彼らがこれらの操作に関して願っているどんな方針も採るためにサーバをversioningして、十分を実施するのを許容することの間の何らかのバランスに一様性を見つけなければなりません。
5.9.1.3. The Versioning Model. Each version typically stands in a "derived from" relationship to its predecessor(s). It is possible to derive several different versions from a single version (branching), and to derive a single version from several versions (merging). Consequently, the collection of related versions forms a directed acyclic graph. In the following discussion, this graph will be called a "version graph". Each node of this graph is a "version" or "member of the version graph". The arcs of the graph capture the "derived from" relationships.
5.9.1.3. Versioningはモデル化します。 各バージョンは前任者との「派生」関係で通常立ちます。 ただ一つのバージョン(分岐する)からいくつかの異なった見解を得て、いくつかのバージョン(合併)からただ一つのバージョンを得るのは可能です。 その結果、関連するバージョンの収集は指示された非循環のグラフを形成します。 以下の議論では、このグラフは「バージョングラフ」と呼ばれるでしょう。 このグラフの各ノードは、「バージョン」か「バージョングラフのメンバー」です。 グラフのアークは、「派生」が関係であるとキャプチャします。
It is also possible for a single resource to participate in multiple version graphs.
また、ただ一つのリソースが複数のバージョングラフに参加するのも、可能です。
The WebDAV extensions should support this versioning model, though particular servers may restrict it in various ways.
特定のサーバはいろいろそれを制限するかもしれませんが、WebDAV拡張子はこのversioningモデルをサポートするべきです。
5.9.1.4. Versioning Policies. Many writers, including Feiler [CM] and Haake and Hicks [VSE], have discussed the notion of versioning styles (referred to here as versioning policies, to reflect the nature of client/server interaction) as one way to think about the different policies that versioning systems implement. Versioning policies include decisions on the shape of version histories (linear or branched), the granularity of change tracking, locking requirements made by a server, etc. The protocol should clearly identify the policies that it dictates and the policies that are left up to versioning system implementors or administrators.
5.9.1.4. 方針をVersioningします。 Feiler[CM]、Haake、およびヒックス[VSE]を含む多くの作家がversioningシステムが実施する異なった政策について考えることにおける一方通行としてスタイル(クライアント/サーバ相互作用の自然を反映するために方針をversioningするとしてここに言及される)をversioningするという概念について議論しました。 Versioning方針はバージョン歴史(直線的であるか分岐した)の形の決定を含んでいます、変更履歴の粒状、サーバなどによって作られた要件をロックして プロトコルは明確にそれが書き取る方針とシステム作成者か管理者をversioningするのに任せられる方針を特定するべきです。
5.9.1.5. It is possible to version resources of any media type.
5.9.1.5. それはどんなメディアタイプに関するバージョンリソースにも可能です。
5.9.2. Functional Requirements
5.9.2. 機能条件書
5.9.2.1. Referring to a version graph. There must be a way to refer to a version graph as a whole.
5.9.2.1. バージョングラフを示します。 全体でバージョングラフを示す方法があるに違いありません。
Some queries and operations apply, not to any one member of a version graph, but to the version graph as a whole. For example, a client may request that an entire graph be moved, or may ask for a version history. In these cases, a way to refer to the whole version graph is required.
いくつかの質問と操作がバージョングラフのどんなメンバーではなく、全体でバージョングラフにも適用されます。 例えば、クライアントは、全体のグラフが動かされるよう要求するか、またはバージョン歴史を求めるかもしれません。 これらの場合では、全体のバージョングラフを示す方法が必要です。
Slein, et. al. Informational [Page 13] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[13ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
5.9.2.2. Referring to a specific member of a version graph. There must be a way to refer to each member of a version graph. This means that each member of the graph is itself a resource.
5.9.2.2. バージョングラフの特定のメンバーについて言及します。 バージョングラフの各メンバーについて言及する方法があるに違いありません。 これは、グラフの各メンバーがそれ自体でリソースであることを意味します。
Each member of a version graph must be a resource if it is to be possible for a hypertext link to refer to specific version of a page, or for a client to request a specific version of a document for editing.
ハイパーテキストリンクが1ページの特定のバージョンを示すか、またはクライアントが編集のためのドキュメントの特定のバージョンを要求するのが、可能であることであるなら、バージョングラフの各メンバーはリソースであるに違いありません。
5.9.2.3. A client must be able to determine whether a resource is a version graph, or whether a resource is itself a member of a version graph.
5.9.2.3. クライアントは、リソースがバージョングラフであるかどうかかそれともリソースがそれ自体でバージョングラフのメンバーであるかどうか決定できなければなりません。
A resource may be a simple, non-versioned resource, or it may be a version graph, or it may be a member of a version graph. A client needs to be able to tell which sort of resource it is accessing.
リソースは簡単で、非versionedされたリソースであるかもしれませんかそれはバージョングラフであるかもしれませんかそれがバージョングラフのメンバーであるかもしれません。 クライアントは、それがどの種類に関するリソースにアクセスしているかを言うことができる必要があります。
5.9.2.4. There must be a way to refer to a server-defined default member of a version graph.
5.9.2.4. バージョングラフのサーバで定義されたデフォルトメンバーについて言及する方法があるに違いありません。
The server should return a default version of a resource for requests that ask for the default version, as well as for requests where no specific version information is provided. This is one of the simplest ways to guarantee non-versioning client compatibility. This does not rule out the possibility of a server returning an error when no sensible default exists.
サーバはデフォルトバージョンを求める要求のためのリソースのデフォルトバージョンを返すべきです、よくどんな特定のバージョン情報も提供されない要求のように。 これは非versioningクライアントの互換性を保証する最も簡単な方法の1つです。 これは実際的なデフォルト値が全く存在していないとサーバが誤りを返す可能性を除外しません。
It may also be desirable to be able to refer to other special members of a version graph. For example, there may be a current version for editing that is different from the default version. For a graph with several branches, it may be useful to be able to request the tip version of any branch.
また、バージョングラフの他の特別なメンバーについて言及できるのも望ましいかもしれません。 例えば、デフォルトバージョンと異なった編集のための最新版があるかもしれません。 いくつかのブランチがあるグラフに、どんなブランチのチップバージョンも要求できるのは役に立つかもしれません。
5.9.2.5. It must be possible, given a reference to a member of a version graph, to find out which version graph(s) that resource belongs to.
5.9.2.5. バージョングラフのメンバーについての言及を考えて、それは、そのリソースがどのバージョングラフに属すかを見つけるために可能でなければなりません。
This makes it possible to understand the versioning context of the resource. It makes it possible to retrieve a version history for the graphs to which it belongs, and to browse the version graph. It also supports some comparison operations: It makes it possible to determine whether two references designate members of the same version graph.
これで、リソースのversioning文脈を理解しているのは可能になります。 それで、それが属するグラフのためのバージョン歴史を検索して、バージョングラフをブラウズするのは可能になります。 また、それは、何らかの比較が操作であるとサポートします: それで、2つの参照箇所が同じバージョングラフのメンバーを任命するかどうか決定するのが可能になります。
5.9.2.6. Navigation of a version graph. Given a reference to a member of a version graph, it must be possible to discover and access the following related members of the version graph.
5.9.2.6. バージョングラフのナビゲーション。 バージョングラフのメンバーについての言及を考えて、バージョングラフの以下の関連するメンバーを発見して、アクセスするのは可能であるに違いありません。
Slein, et. al. Informational [Page 14] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[14ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
o root member of the graph
o predecessor member(s)
o successor member(s)
o default member of the graph
o グラフのグラフo前任者メンバーo後継者のメンバーoデフォルトメンバーの根のメンバー
It must be possible in some way for a versioning client to access versions related to a resource currently being examined.
それはversioningクライアントが調べられる現在リソースに関連するバージョンにアクセスする何らかの方法で可能でなければなりません。
5.9.2.7. Version Topology. There must be a way to retrieve the complete version topology for a version graph, including information about all members of the version graph. The format for this information must be standardized so that the basic information can be used by all clients. Other specialized formats should be accommodated, for servers and clients that require information that cannot be included in the standard topology.
5.9.2.7. バージョントポロジー。 バージョングラフのために完全なバージョントポロジーを検索する方法があるに違いありません、バージョングラフのすべてのメンバーの情報を含んでいて。 すべてのクライアントが基本情報を使用できるように、この情報のための形式を標準化しなければなりません。 他の専門化している形式は設備されるべきです、標準のトポロジーに含むことができない情報を必要とするサーバとクライアントのために。
5.9.2.8. A client must be able to propose a version identifier to be used for a new member of a version graph. The server may refuse to use the client's suggested version identifier. The server should tell the client what version identifier it has assigned to the new member of the version graph.
5.9.2.8. クライアントは、バージョングラフの新しいメンバーに使用されるためにバージョン識別子を提案できなければなりません。 サーバは、クライアントの提案されたバージョン識別子を使用するのを拒否するかもしれません。 サーバは、バージョングラフについてそれがどんなバージョン識別子を新しいメンバーに割り当てたかをクライアントに言うべきです。
5.9.2.9. A version identifier must be unique across a version graph.
5.9.2.9. バージョン識別子はバージョングラフの向こう側にユニークであるに違いありません。
5.9.2.10. A client must be able to supply version-specific properties to be associated with a new member of a version graph. (See Section 5.1 "Properties" above.) At a minimum, it must be possible to associate comments with the new member, explaining what changes were made.
5.9.2.10. クライアントは、バージョングラフの新しいメンバーに関連しているようにバージョン特有の性質を供給できなければなりません。 (「特性」というセクション5.1が上であることを見てください。) 最小限では、どんな変更が行われたかを説明して、新しいメンバーにコメントを関連づけるのは可能であるに違いありません。
5.9.2.11. A client must be able to query the server for information about a version tree, including which versions are locked, which are reserved for editing, and by whom (Session Tracking).
5.9.2.11. クライアントはどのバージョンがロックされるかを含むバージョン木の情報のためにサーバについて質問できなければなりません(編集して、だれが予約されるか)(セッションTracking)。
5.9.3. Rationale
5.9.3. 原理
Versioning in the context of the world-wide web offers a variety of benefits:
世界的なウェブの文脈でVersioningするのはさまざまな利益を提供します:
It provides infrastructure for efficient and controlled management of large evolving web sites. Modern configuration management systems are built on some form of repository that can track the revision history of individual resources, and provide the higher-level tools to manage those saved versions. Basic versioning capabilities are required to support such systems.
それは大きい発展ウェブサイトの効率的で制御された管理にインフラストラクチャを提供します。 現代の構成管理システムは個々のリソースに関する改訂履歴を追跡して、バージョンであると保存されたものを管理するために、よりハイレベルのツールを提供できる何らかの形式の倉庫の上に構築されます。 基本的なversioning能力が、そのようなシステムをサポートするのに必要です。
Slein, et. al. Informational [Page 15] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[15ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
It allows parallel development and update of single resources. Since versioning systems register change by creating new objects, they enable simultaneous write access by allowing the creation of variant versions. Many also provide merge support to ease the reverse operation.
それはただ一つのリソースの並行開発とアップデートを許します。 以来versioningシステムが新しいオブジェクトを作成することによって変化を登録する、可能にする、同時である、異形バージョンの作成を許容することによって、アクセスを書いてください。 また、多くが、逆の操作を緩和するためにマージサポートを提供します。
It provides a framework for coordinating changes to resources. While specifics vary, most systems provide some method of controlling or tracking access to enable collaborative resource development.
それはリソースへの変化を調整するのにフレームワークを提供します。 詳細が異なっている間、ほとんどのシステムが協力的なリソース開発を可能にするアクセスを制御するか、または追跡する何らかのメソッドを提供します。
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.
それは過去とリソースの異本にブラウジングの通ることを許します。 本来頻繁に、リソースの変更と著述業歴史は重要情報です。
It provides 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.
それは注釈のために外部的に保存されたリンクを支えることができる安定した名前とリンクサーバサポートを提供します。 注釈とリンクサーバの両方が、頻繁に彼らの直轄でないリソースの部分の安定した参照を保存する必要があります。 リソースの安定状態を提供することによって、バージョン管理システムはそれらのリソースへの安定した指針だけではなく、リソースのそれらの州の関係を決定する明確なメソッドも許容します。
It allows explicit semantic representation of single resources with multiple states. A versioning system directly represents the fact that a resource has an explicit history, and a persistent identity across the various states it has had during the course of that history.
それは複数の州と共にただ一つのリソースの明白な意味表示を許容します。 versioningシステムは直接、リソースがそれがその歴史のコースの間に持っている様々な州の向こう側に明白な歴史、および永続的なアイデンティティを持っているという事実を表します。
5.10. Variants
5.10. 異形
Detailed requirements for variants will be developed in a separate document.
異形のための詳細な要件は別々のドキュメントで開発されるでしょう。
5.10.1. Functional Requirements
5.10.1. 機能条件書
It must be possible to send variants to the server, describing the relationships between the variants and their parent resource. In addition, it must be possible to write and retrieve variants of property labels, property descriptions, and property values.
異形とそれらの親リソースとの関係について説明して、異形をサーバに送るのは可能であるに違いありません。 さらに、特性のラベル、不動産の表示、および特性の値の異形を書いて、検索するのは可能でなければなりません。
5.10.2. Rationale
5.10.2. 原理
The HTTP working group is addressing problems of content negotiation and retrieval of variants of a resource. To extend this work to an authoring environment, WEBDAV must standardize mechanisms for authors to use when submitting variants to a server. Authors need to be able to provide variants in different file or document formats, for different uses. They need to provide variants optimized for different
HTTPワーキンググループは満足している交渉の問題とリソースの異形の検索を扱っています。 この仕事を書いている環境に広げるために、WEBDAVはサーバに異形を提出するとき作者が使用するメカニズムを標準化しなければなりません。作者は、異なったファイルかドキュメント・フォーマットに異形を供給できる必要があります、異なった用途のために。 彼らが、最適化された異形を提供する必要がある、相違
Slein, et. al. Informational [Page 16] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[16ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
clients and for different output devices. They need to be able to provide variants in different languages in the international environment of the Web. In support of internationalization requirements (See 5.12 below), variants need to be supported not just for the content of resources, but for any information intended for human use, such as property values, labels, and descriptions.
クライアントと異なった出力装置のために。 彼らは、異なった言語でウェブの国際的な環境に異形を提供できる必要があります。 国際化要件(5.12未満を見る)を支持して、異形は、リソースの内容だけのためにサポートされるのではなく、人間が使うために意図するどんな情報のためにもサポートされる必要があります、特性の値や、ラベルや、記述などのように。
5.11. Security
5.11. セキュリティ
5.11.1. Authentication. The WebDAV specification should state how the WebDAV extensions interoperate with existing authentication schemes, and should make recommendations for using those schemes.
5.11.1. 認証。 WebDAV仕様は、WebDAV拡張子が既存の認証体系でどう共同利用するかを述べるべきであり、それらの体系を使用するための推薦状をするべきです。
5.11.2. Access Control. Access control requirements are specified in a separate access control work in progress [AC].
5.11.2. コントロールにアクセスしてください。 アクセス制御要件は別々のアクセス制御処理中の作業[西暦]で指定されます。
5.11.3. Interoperability with Security Protocols. The WebDAV specification must provide a minimal list of security protocols which any compliant server / client must support. These protocols should insure the authenticity of messages and the privacy and integrity of messages in transit.
5.11.3. セキュリティプロトコルがある相互運用性。 WebDAV仕様はどんな言いなりになっているサーバ/クライアントもサポートしなければならないセキュリティプロトコルの最小量のリストを提供しなければなりません。 これらのプロトコルはトランジットにおけるメッセージのメッセージの信憑性、プライバシー、および保全を保障するべきです。
5.12. Internationalization
5.12. 国際化
5.12.1. Character Sets and Languages
5.12.1. 文字コードと言語
Since Web distributed authoring occurs in a multi-lingual environment, information intended for user comprehension must conform to the IETF Character Set Policy [CHAR]. This policy addresses character sets and encodings, and language tagging.
ウェブの分配されたオーサリングが多言語環境で起こるので、ユーザ読解のために意図する情報はIETF文字コードPolicy[CHAR]に従わなければなりません。 この方針は文字集合、encodings、および言語タグ付けを扱います。
5.12.2. Rationale
5.12.2. 原理
In the international environment of the Internet, it is important to insure that any information intended for user comprehension can be displayed in a writing system and language agreeable to both the client and the server. The information encompassed by this requirement includes not only the content of resources, but also such things as display names and descriptions of properties, property values, and status messages.
インターネットの国際的な環境で、クライアントとサーバの両方に快い書記体系と言語でユーザ読解のために意図するどんな情報も表示できるのを保障するのが重要です。この要件によって包含された情報はリソースの内容だけではなく、名前を表示するようなものと特性、特性の値、およびステータスメッセージの記述も含んでいます。
6. Acknowledgements
6. 承認
Our understanding of these issues has emerged as the result of much thoughtful discussion, email, and assistance by many people, who deserve recognition for their effort.
私たちのこれらの問題の理解は多くの思慮に富む議論の、そして、メールであって、支援している彼らの取り組みのための認識に値する多くの人々が結果として現れました。
Slein, et. al. Informational [Page 17] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[17ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
Terry Allen, tallen@sonic.net
Alan Babich, FileNet, babich@filenet.com
Dylan Barrell, Open Text, dbarrell@opentext.ch
Barbara Bazemore, PC DOCS, barbarab@pcdocs.com
Martin Cagan, Continuus Software, Marty_Cagan@continuus.com
Steve Carter, Novell, srcarter@novell.com
Dan Connolly, World Wide Web Consortium, connolly@w3.org
Jim Cunningham, Netscape, jfc@netscape.com
Ron Daniel Jr., Los Alamos National Laboratory, rdaniel@lanl.gov
Mark Day, Lotus, Mark_Day@lotus.com
Martin J. Duerst, mduerst@ifi.unizh.ch
Asad Faizi, Netscape, asad@netscape.com
Ron Fein, Microsoft, ronfe@microsoft.com
David Fiander, Mortice Kern Systems, davidf@mks.com
Roy Fielding, U.C. Irvine, fielding@ics.uci.edu
Mark Fisher, Thomson Consumer Electronics, FisherM@indy.tce.com
Yaron Y. Goland, Microsoft, yarong@microsoft.com
Phill Hallam-Baker, MIT, hallam@ai.mit.edu
Dennis Hamilton, Xerox PARC, hamilton@parc.xerox.com
Andre van der Hoek, University of Colorado, Boulder,
andre@cs.colorado.edu
Del Jensen, Novell, dcjensen@novell.com
Gail Kaiser, Columbia University, kaiser@cs.columbia.edu
Rohit Khare, World Wide Web Consortium, khare@w3.org
Ora Lassila, Nokia Research Center, ora.lassila@research.nokia.com
Ben Laurie, A.L. Digital, ben@algroup.co.uk
Mike Little, Bellcore, little@bellcore.com
Dave Long, America Online, dave@sb.aol.com
Larry Masinter, Xerox PARC, masinter@parc.xerox.com
Murray Maloney, SoftQuad, murray@sq.com
Jim Miller, World Wide Web Consortium, jmiller@w3.org
Howard S. Modell, Boeing, howard.s.modell@boeing.com
Keith Moore, University of Tennessee, Knoxville, moore@cs.utk.edu
Henrik Frystyk Nielsen, World Wide Web Consortium, frystyk@w3.org
Jon Radoff, NovaLink, jradoff@novalink.com
Alan Robertson, alanr@bell-labs.com
Henry Sanders, Microsoft,
Andrew Schulert, Microsoft, andyschu@microsoft.com
Christopher Seiwald, Perforce Software, seiwald@perforce.com
Einar Stefferud, stef@nma.com
Richard Taylor, U.C. Irvine, taylor@ics.uci.edu
Robert Thau, MIT, rst@ai.mit.edu
Sankar Virdhagriswaran, sv@hunchuen.crystaliz.com
Dan Whelan, FileNet, dan@FILENET.COM
Gregory J. Woodhouse, gjw@wnetc.com
テリー・アレン、 tallen@sonic.net アランBabich、FileNet、 babich@filenet.com ディランBarrell、Open Text、 dbarrell@opentext.ch バーバラBazemore、PC DOCS、 barbarab@pcdocs.com マーチン・ケイガン、Continuusソフトウェア、 Marty_Cagan@continuus.com スティーブ・カーター、ノベル、 srcarter@novell.com ダン・コノリー、ワールドワイドウェブコンソーシアム、 connolly@w3.org ジムカニンハム、Netscape、 jfc@netscape.com ロンダニエルJr.、ロスアラモス国立研究所、 rdaniel@lanl.gov は日をマークします、ロータス、 Mark_Day@lotus.com マーチンJ.Duerst、 mduerst@ifi.unizh ch Asad Faizi、Netscape、 asad@netscape.com ロンフェイン、マイクロソフト、 ronfe@microsoft.com デヴィッドFiander、MorticeカーンSystems、 davidf@mks.com ロイFielding、U.C.アーバイン fielding@ics.uci.edu マーク・フィッシャー、トムソンConsumer Electronics( FisherM@indy.tce.com ヤロンY); Goland、マイクロソフト、 yarong@microsoft.com フィル・ハラム-ベイカー、MIT、 hallam@ai.mit.edu デニス・ハミルトン、ゼロックスPARC、 hamilton@parc.xerox.com アンドレはderフックをバンに積みます、コロラドの大学、ボウルダー、 andre@cs.colorado.edu デル・ジェンセン、ノベル、 dcjensen@novell.com ゲイル・カイser、コロンビア大学、 kaiser@cs.columbia.edu Rohit Khare、ワールドワイドウェブコンソーシアム、 khare@w3.org Ora Lassila、ノキアResearchセンター、 ora.lassila@research.nokia.com ベン・ローリー、A.L.Digital、 ben@algroup.co.uk マイク・リトル、Bellcore、 little@bellcore.com デーヴLong、アメリカOnline dave@sb.aol.com ラリーMasinter、ゼロックスPARC、 masinter@parc.xerox.com マレーマローニー、SoftQuad、 murray@sq.com ジム・ミラー、ワールドワイドウェブコンソーシアム、 jmiller@w3.org ハワード・S.モデル、ボーイング( howard.s.modell@boeing ); comキース・ムーア、テネシー、ノクスビル moore@cs.utk.edu Henrik Frystykニールセンの大学、ワールドワイドウェブコンソーシアム、 frystyk@w3.org ジョンRadoff、NovaLink、 jradoff@novalink.com アラン・ロバートソン、 alanr@bell-labs.com ヘンリーSanders、マイクロソフト、アンドリューSchulert、マイクロソフト( andyschu@microsoft ); comクリストファーSeiwald、Perforce Software、 seiwald@perforce.com Einar Stefferud、 stef@nma.com リチャード・テイラー、U.C.アーバイン、 taylor@ics.uci.edu ロバート・トー、MIT、 rst@ai.mit.edu Sankar Virdhagriswaran、 sv@hunchuen.crystaliz.com ダン・ウィーラン、Fileネット、 dan@FILENET.COM グレゴリー・J.ウッドハウス、 gjw@wnetc.com
Slein, et. al. Informational [Page 18] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[18ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
7. References
7. 参照
[AC] J. Radoff, "Requirements for Access Control within Distributed Authoring and Versioning Environments on the World Wide Web", unpublished manuscript, <http://lists.w3.org/Archives/Public/w3c- dist-auth/1997AprJun/0183.html>
[西暦]J.Radoff、「アクセスのための要件はWWWの分配されたオーサリングとVersioning環境の中で制御します」、未発表原稿、<http://lists.w3.org/アーカイブ/公衆/w3c dist-auth/1997AprJun/0183.html>。
[CHAR] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998.
[焦げます] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、1998年1月。
[CM] P. Feiler, "Configuration Management Models in Commercial Environments", Software Engineering Institute Technical Report CMU/SEI-91-TR-7, <http://www.sei.cmu.edu/products/publications/91.reports/91.tr.007.html>
[CM]P.Feiler、「商業環境における構成管理モデル」、ソフトウェア工学研究所技術報告書SEI91-TR米カーネギーメロン大学/7、<http://www.sei.cmu.edu/製品/刊行物/91.reports/91.tr.007.html>。
[HTML] Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, November 1995.
[HTML] バーナーズ・リー、T.、およびD.コノリー、「2インチ、RFC1866、1995年ハイパーテキストマークアップランゲージ仕様--11月。」
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[HTTP] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」
[ISO 10646] ISO/IEC 10646-1:1993. "International Standard -- Information Technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane."
[ISO10646] ISO/IEC10646-1:1993。 「国際規格--情報技術--普遍的な複数の八重奏コード化文字集合(UCS)--第1部:、」 「アーキテクチャと基本多言語水準。」
[URL] Berners-Lee, T., Masinter, L., and M. McCahill. "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]バーナーズ・リー、T.、Masinter、L.、およびM. McCahill。 「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[VSE] A. Haake, D. Hicks, "VerSE: Towards Hypertext Versioning Styles", Proc. Hypertext'96, The Seventh ACM Conference on Hypertext, 1996, pages 224-234.
[VSE]A.Haake(D.ヒックス)は「以下の作詩をします」。 「ハイパーテキストVersioning様式」、Proc。 ハイパーテキスト96年、ハイパーテキスト、1996、224-234ページのSeventh ACMコンファレンス。
Slein, et. al. Informational [Page 19] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[19ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
8. Authors' Addresses
8. 作者のアドレス
Judith Slein Xerox Corporation 800 Phillips Road 128-29E Webster, NY 14580
ジュディスSleinゼロックス社800のフィリップスRoad128-29Eウェブスター、ニューヨーク 14580
EMail: slein@wrc.xerox.com
メール: slein@wrc.xerox.com
Fabio Vitali Department of Computer Science University of Bologna ITALY
Bolognaイタリアのファビオヴィターリコンピュータサイエンス学部大学
EMail: fabio@cs.unibo.it
メール: fabio@cs.unibo.it
E. James Whitehead, Jr. Department of Information and Computer Science University of California Irvine, CA 92697-3425
E.ジェームス・ホワイトヘッドと情報のJr.部とカリフォルニア大学アーバイン、コンピュータサイエンスカリフォルニア92697-3425
Fax: 714-824-4056 EMail: ejw@ics.uci.edu
Fax: 714-824-4056 メールしてください: ejw@ics.uci.edu
David G. Durand Department of Computer Science Boston University Boston, MA
デヴィッド・G.ジュランドコンピュータサイエンス学部ボストン大学ボストン(MA)
EMail: dgd@cs.bu.edu
メール: dgd@cs.bu.edu
Slein, et. al. Informational [Page 20] RFC 2291 Distributed Authoring and Versioning February 1998
et Slein、アル。 情報[20ページ]のRFC2291は1998年2月にオーサリングとVersioningを分配しました。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Slein, et. al. Informational [Page 21]
et Slein、アル。 情報[21ページ]
一覧
スポンサーリンク
