W3C手続き文書
W3C Process Document

1. 導入
Introduction

W3Cの仕事は, ウェブ技術の標準化を中心に展開されています. この仕事を成し遂げるために, W3Cは, 会員, 事務局, 社会全体の合意を基にした, 質の高い標準の開発を推進する手続きに従います. W3Cの手続きは, 全てW3Cの使命の一面である公正, 責任 前進を推進します. この文書は, W3Cが使命の遂行において従う手続きについて述べています.

W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote the development of high-quality standards based on the consensus of the Membership, Team, and public. W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission. This document describes the processes W3C follows in pursuit of its mission.

W3C手続き文書は, 合意を形成し, (会員と社会全体両方による)審査を要求し, 実装と相互運用性の経験を具体化し, 技術報告書開発手続きの一部として会員間の幅広い賛同を必要とすることで, 技術的な決定における質と公平性の目標をより高めます. W3Cの参加者は, W3C会員の代表者, 事務局, それら以外の専門知識をもたらしたり, それら以外の利害関係者を代表したりすることができる外部の専門家を含みます. 事務局の代表者は, 技術的な作業に寄与するとともに, W3Cの他の部会と, 対象の部会との統合を確かなものにする手助けをします.

The W3C Process promotes the goals of quality and fairness in technical decisions by encouraging consensus, soliciting reviews (by both Members and public), incorporating implementation and interoperability experience, and requiring Membership-wide approval as part of the technical report development process. Participants in W3C include representatives of its Members and the Team, as well as Invited Experts who can bring additional expertise or represent additional stakeholders. Team representatives both contribute to the technical work and help ensure the group’s proper integration with the rest of W3C.

W3C勧告と呼ばれるW3Cの技術標準は, W3Cの作業部会によって開発されます. W3Cは他の形式の文書も公開しており, それら全てについて§ 6 W3C技術報告書で述べています. W3Cは様々な形式の部会を持っています. この文書は, W3Cの憲章を持つ作業部会と関連部会の構成と指針について述べており, § 3.1 W3C部会への参加指針と§ 3.4 憲章を持つ部会:作業部会と関連部会を参照して下さい. W3Cは, 独自の手続き文書 [BG-CG]で別個に説明している共同部会とビジネス部会についても管理しています.

W3C’s technical standards, called W3C Recommendations, are developed by its Working Groups; W3C also has other types of publications, all described in § 6 W3C Technical Reports. W3C has various types of groups; this document describes the formation and policies of its chartered Working Groups and Interest Groups, see § 3.1 Policies for Participation in W3C Groups and § 3.4 Chartered Groups: Working Groups and Interest Groups. W3C also operates Community and Business Groups, which are separately described in their own process document [BG-CG].

加えて, 様々な部会がコンソーシアムによって正式に設置されています. W3C諮問委員会は, 各会員の代表者で構成され, W3C会員により選ばれる2つの管理部会を持ちます. 諮問会議(AB)は, コンソーシアム内を横断する技術的でない課題の解決を助け, W3C手続き文書の発展を管理します. 技術諮問委員会(TAG)は, コンソーシアム内を横断する技術的な課題の解決を手助けします.

In addition, several groups are formally established by the Consortium: the W3C Advisory Committee, which has a representative from each Member, and two oversight groups elected by its membership: the Advisory Board (AB), which helps resolve Consortium-wide non-technical issues and manages the evolution of the W3C process; and the Technical Architecture Group (TAG), which helps resolve Consortium-wide technical issues.

ここに, どのようにW3Cがウェブ技術の標準化に着手するかについての一般的な概要を示します.

Here is a general overview of how W3C initiates standardization of a Web technology:

1. 特定の項目に関心を持った人がいるとします. 例えば, 会員が, 共同部会の中で提案されたものを開発することや, 会員提案の中で意見を出すことで, 興味を示したとします. また, 事務局が, W3C内外での関心の現れに対する作業について監視し, W3C界隈で関心が持たれている項目について議論するために, 人々を集めようとワークショップを開催します.
   People generate interest in a particular topic. For instance, Members express interest by developing proposals in Community Groups or proposing ideas in Member Submissions. Also, the Team monitors work inside and outside of W3C for signs of interest, and helps organize Workshops to bring people together to discuss topics that interest the W3C community.
2. 十分な関心が寄せられ, 取り組もうという人々がいる場合, 事務局は, 会員とともに関連部会または作業部会の憲章案を提案する作業を行います. W3C会員が憲章案を審査し, 関心の寄せられた項目に資源を割り振るW3Cの対応が可能な場合, W3Cは部会を承認し, それらの部会は作業を開始します.
   When there is enough interest and an engaged community, the Team works with the Membership to draft proposed Interest Group or Working Group charters. W3C Members review the proposed charters, and when there is support within W3C for investing resources in the topic of interest, the W3C approves the group(s), and they begin their work.

この手続き文書のその他の節は, 連絡体制(§ 9 連絡体制), 機密(§ 7 普及指針), 正式な決定と抗議(§ 5 決定)を含む内容を扱っています.

Further sections of this Process Document deal with topics including liaisons (§ 9 Liaisons), confidentiality (§ 7 Dissemination Policies), and formal decisions and appeals (§ 5 Decisions).

2. 会員と事務局
Members and the Team

W3Cの使命は, ウェブの完全な潜在能力を引き出すように導くことです. W3Cの会員組織は, この完了のために資源を提供し, W3C事務局は, 取組みを調整するために, 技術的な指揮と組織を提供します.

W3C’s mission is to lead the Web to its full potential. W3C Member organizations provide resources to this end, and the W3C Team provides the technical leadership and organization to coordinate the effort.

2.1. 会員
Members

W3C会員は, 会員規約 [会員規約]に同意した組織です. それらの会員は, W3C手続き文書の中で次のように表現されます.

W3C Members are organizations subscribed according to the Membership Agreement [MEMBER-AGREEMENT]. They are represented in W3C processes as follows:

1. 各会員組織を代表する1人が, W3Cの仕事を監督する諮問委員会に参加します.
   One representative per Member organization particiaptes in the Advisory Committee which oversees the work of the W3C.
2. 会員組織の代表者が, 技術報告書を作成したり審査したりする作業部会や関連部会に参加します.
   Representatives of Member organizations participate in Working Groups and Interest Groups, where they author and review technical reports.

W3Cの会員になることは, “W3Cに加入するには” [加入]で述べられているように, (最新のW3C会員 [会員一覧]にあるように)全ての団体に開かれています. 事務局は, 会員の参加の同意を事務局内にとどまらせ, どの会員にもW3Cの中で優先の取扱いを受けないことを確かなものにしなければなりません.

W3C membership is open to all entities, as described in “How to Join W3C” [JOIN]; (refer to the public list of current W3C Members [MEMBER-LIST]). The Team must ensure that Member participation agreements remain Team-only and that no Member receives preferential treatment within W3C.

W3Cは個人に合わせた会員の種類を持っていないにも関わらず, 個人はW3Cに加入してもよいです. 個人が他のW3C会員を代表してもいるとき, 関連会員に付随する制限が適用されます.

While W3C does not have a class of membership tailored to individuals, individuals may join W3C. Restrictions pertaining to related Members apply when the individual also represents another W3C Member.

2.1.1. 会員の権利
Rights of Members

各会員組織は, 次の権利や恩恵を享受します.

Each Member organization enjoys the following rights and benefits:

• 諮問委員会の席.
  A seat on the Advisory Committee;
• 会員限定の情報の利用.
  Access to Member-only information;
• 会員提案の手続き.
  The Member Submission process;
• W3C会員ロゴの広報資料への利用と, W3Cに会員が参加していることの公表. より詳細な情報については, 新会員オリエンテーション [導入]で述べられている会員ロゴ利用指針を参照して下さい.
  Use of the W3C Member logo on promotional material and to publicize the Member’s participation in W3C. For more information, please refer to the Member logo usage policy described in the New Member Orientation [INTRO].

さらに, 会員規約に含まれるさらに細かい制限を条件として, 会員組織の代表者は, 次のようにW3Cに参加します.

Furthermore, subject to further restrictions included in the Member Agreement, representatives of Member organizations participate in W3C as follows:

• 作業部会や関連部会への参加.
  In Working Groups and Interest Groups.
• ワークショップやシンポジウムへの参加.
  In Workshops and Symposia;
• W3C特別研究員として事務局への参加.
  On the Team, as W3C Fellows.

W3C会員[会員規約]の権利や恩恵は, この文書で述べられている手続きに合致するかどうかによります. W3Cの活動に参加している誰かへの懲戒処分については, § 3.1.1.1 期待と懲戒で説明しています.

The rights and benefits of W3C membership [MEMBER-AGREEMENT] are contingent upon conformance to the processes described in this document. Disciplinary action for anyone participating in W3C activities is described in § 3.1.1.1 Expectations and Discipline.

会員についての追加の情報は, 会員ウェブサイト [会員HP]で確認できます.

Additional information for Members is available at the Member Web site [MEMBER-HP].

2.1.2. 会員共同体と関連会員
Member Consortia and Related Members

2.1.2.1. 会員共同体
Membership Consortia

“会員共同体”は, 2つ以上の個人, 企業, 組織, 政府による, 共同体, 利用者社会, 提携を意味します. もしくは, W3Cの確かな目標に向けて参加してその目標を成し遂げるのとは別に, 共通の目標を成し遂げるために資源を共同出資したり, 共通の活動に参加したりする目的を持った, 個人, 企業, 組織, 政府の連携を意味します. 共同資本の会社や類似した組織は, 単に同じ株主を持つに過ぎないことから, 会員共同体ではありません. 見込まれている会員が会員共同体として適任であるか明確でない場合, ディレクターは賢明に判断するでしょう. 会員共同体に対して, W3C手続き文書の中で述べたW3C会員の権利や恩恵は, 会員共同体の有償職員や諮問委員会の委員にまで及びます.

A “Member Consortium” means a consortium, user society, or association of two or more individuals, companies, organizations or governments, or any combination of these entities which has the purpose of participating in a common activity or pooling resources to achieve a common goal other than participation in, or achieving certain goals in, W3C. A joint-stock corporation or similar entity is not a Member Consortium merely because it has shareholders or stockholders. If it is not clear whether a prospective Member qualifies as a Member Consortium, the Director may reasonably make the determination. For a Member Consortium, the rights and privileges of W3C Membership described in the W3C Process Document extend to the Member Consortium's paid staff and Advisory Committee representative.

会員共同体は, 組織によって雇用されているが, 会員の代表として権利を行使してもよい, 4名の(事務局の裁量でそれ以上の)個人を指名してもよいです.

Member Consortia may also designate up to four (or more at the Team’s discretion) individuals who, though not employed by the organization, may exercise the rights of Member representatives.

メンバーとして個人を含む会員共同体に対して, それらの個人は, W3Cの仕事に参加するときに, 雇用されている所属を開示しなければなりません. 関連会員に対する規定も適用されます. さらに, それらの個人は, 自分達の雇用主特有の利益ではなく, W3C会員の広範囲に及ぶ利益を代表しなければなりません.

For Member Consortia that have individual people as members, these individuals must disclose their employment affiliation when participating in W3C work. Provisions for related Members apply. Furthermore, these individuals must represent the broad interests of the W3C Member organization and not the particular interests of their employers.

会員としての組織の側面を持つ会員共同体に対して, 全てのそのような組織の指名された代表者は, 会員組織の公式な代表者(例えば, 諮問委員会の委員またはプロジェクトチームの議長)でなければなりません. また, それらの代表者は, W3Cの仕事に参加するときに, 雇用されている所属を開示しなければなりません. 関連会員に対する規定も適用されます. さらに, それらの個人は, 自分達の雇用主特有の利益ではなく, W3C会員の広範囲に及ぶ利益を代表しなければなりません.

For Member Consortia that have organizations as Members, all such designated representatives must be an official representative of the Member organization (e.g. a Committee or Task Force Chairperson) and must disclose their employment affiliation when participating in W3C work. Provisions for related Members apply. Furthermore, these individuals must represent the broad interests of the W3C Member organization and not the particular interests of their employers.

全ての会員共同体の代表者に対して, 会員共同体のためのIPR(訳注:知的所有権)の取り組みが必要になります. ただし, 代表者の雇用主によって, それ以上のIPRの取り組みが必要になっていない場合に限ってです.

For all representatives of a Member Consortium, IPR commitments are made on behalf of the Member Consortium, unless a further IPR commitment is made by the individuals' employers.

2.1.2.2. 関連会員
Related Members

合意の手続きの誠実さを確実にする利益の点で, この文書における手続きの中では, 場合によって会員の関係が, 関連会員の状態によって影響されます. ここでは, 2つの会員が, 次の場合に関連していると言います.

In the interest of ensuring the integrity of the consensus process, Member involvement in some of the processes in this document is affected by related Member status. As used herein, two Members are related if:

1. どちらかの会員が, もう一方の系列組織である場合.
   Either Member is a subsidiary of the other, or
2. 両方の会員が, 共通の組織の系列組織である場合.
   Both Members are subsidiaries of a common entity, or
3. 会員が, W3Cの参加に影響する雇用契約またはコンサルタント契約を結んでいる場合.
   The Members have an employment contract or consulting contract that affects W3C participation.

系列組織は, 他の単独の組織に, 事実上の管理下に置かれているか, 過半数の資本金を所有されているかする組織です.

A subsidiary is an organization of which effective control and/or majority ownership rests with another, single organization.

関連会員は, 新会員オリエンテーション [導入]で述べられている仕組みによって, 自分達の関係を開示しなければなりません.

Related Members must disclose these relationships according to the mechanisms described in the New Member Orientation [INTRO].

2.2. W3C事務局
The W3C Team

事務局は, ディレクター, CEO, W3C有償職員, 無償研修生, W3C特別研究員で構成されています. W3C特別研究員は, 事務局の一部として働く, 会員組織の従業員です. W3C特別研究員プログラム [特別研究員]を参照して下さい. 事務局は, ウェブ技術についての技術的指揮を提供し, (利用可能な資源といった)現実的な制限の中で目標に届くためにW3Cの活動を組織して管理し, ウェブやW3Cの技術について, 会員と社会全体を通じ合わせます.

The Team consists of the Director, CEO, W3C paid staff, unpaid interns, and W3C Fellows. W3C Fellows are Member employees working as part of the Team; see the W3C Fellows Program [FELLOWS]. The Team provides technical leadership about Web technologies, organizes and manages W3C activities to reach goals within practical constraints (such as resources available), and communicates with the Members and the public about the Web and W3C technologies.

ディレクターとCEOは, この文書で述べられている何らかの自分達の役割について, TAGでの委員を除いて, (一般に事務局内の他の人物に)責任を委任してもよいです.

The Director and CEO may delegate responsibility (generally to other individuals in the Team) for any of their roles described in this document, except participation in the TAG.

事務局決定は, 例えディレクターやCEO以外の事務局の人員によって行われたとしても, ディレクターやCEOの権限に由来します.

Team Decisions derive from the Director and CEO's authority, even when they are carried out by other members of the Team.

ディレクターは, この文書の関係する所を通じて責任が規定されている, W3Cの技術的な設計者を指揮します. 鍵となる働きは, W3Cの技術体系の選択における合意を判断すること, 技術報告書の公表, 新しい部会の認可です. また, 部会の議長を指名すること, 部会決定への抗議に対して"タイブレーカー"として決着を付けること, 正式な異議の結果を判断することです. そして, ディレクターは, TAGの議長です.

The Director is the lead technical architect at W3C, whose responsibilities are identified throughout this document in relevant places. Some key ones include: assessing consensus within W3C for architectural choices, publication of technical reports, and chartering new Groups; appointing group Chairs, adjudicating as "tie-breaker" for Group decision appeals, and deciding on the outcome of formal objections; the Director is generally Chair of the TAG.

事務局の給料, 細かい予算化, 他の営業上の決定といった事務局の管理上の情報は, ホスト機関による管理を条件として, 事務局内限定です.

Team administrative information such as Team salaries, detailed budgeting, and other business decisions are Team-only, subject to oversight by the Host institutions.

注意: W3Cは現在, 法人組織ではありません. 法的な契約によると, W3Cは4つの“ホスト”組織, 北京航空航天大学, 欧州情報処理数学コンソーシアム(ERCIM), 慶応義塾大学, マサチューセッツ工科大学(MIT)によって代表されています. W3Cの中において, ホスト機関は, ホスト規約によって統治されています. ホスト自身は, W3Cの会員ではありません.

Note: W3C is not currently incorporated. For legal contracts, W3C is represented by four “Host” institutions: Beihang University, the European Research Consortium for Informatics and Mathematics (ERCIM), Keio University, and the Massachusetts Institute of Technology (MIT). Within W3C, the Host institutions are governed by hosting agreements; the Hosts themselves are not W3C Members.

3. 部会と参加者
Groups and Participation

この手続き文書の意図するところでは, W3C部会は, W3Cの作業部会, 関連部会, 諮問委員会, 諮問会議, TAGのうちの1つで, 参加者は, そのような部会の一員です.

For the purposes of this Process, a W3C Group is one of W3C’s Working Groups, Interest Groups, Advisory Committee, Advisory Board, or TAG, and a participant is a member of such a group.

3.1. W3C部会への参加指針
Policies for Participation in W3C Groups

3.1.1. 個人の参加基準
Individual Participation Criteria

3.1.1.1. 期待と懲戒
Expectations and Discipline

W3Cに参加するために, 個人が証明を期待されている3つの資質があります.

There are three qualities an individual is expected to demonstrate in order to participate in W3C:

1. 役割に必要な技術的な能力.
   Technical competence in one’s role;
2. 公正にふるまう手腕.
   The ability to act fairly;
3. 役割に必要な社会的能力.
   Social competence in one’s role.

W3Cの活動への参加のために, 自分の組織から個人を指名した諮問委員会の委員は, 指名した人の資質を評価し証明することに責任があります.

Advisory Committee representatives who nominate individuals from their organization for participation in W3C activities are responsible for assessing and attesting to the qualities of those nominees.

何らかのW3Cの活動の参加者は, W3C倫理規定および職業行為規定 [CEPC]の条件と精神, およびW3C特許指針[特許指針]の“開示情報”で説明されている参加者の要件を遵守しなければなりません.

Participants in any W3C activity must abide by the terms and spirit of the W3C Code of Ethics and Professional Conduct [CEPC] and the participation requirements described in “Disclosure” in the W3C Patent Policy [PATENT-POLICY].

ディレクターは, (ABやTAGも含め)何らかの部会の参加者を, (a)この手続き文書や特にCEPC, (b)会員規約, (c)適用される法令における個々のふるまいで求められていることを欠くといった, 深刻または繰り返しの違反行為が行われた場合, そのことに起因して活動停止にしたり, 解任したりといった懲戒の手続きを行ってもよいです. 部会の参加者の活動停止または解任についての基準を参照して下さい.

The Director may take disciplinary action, including suspending or removing for cause a participant in any group (including the AB and TAG) if serious and/or repeated violations, such as failure to meet the requirements on individual behavior of (a) this process and in particular the CEPC, or (b) the membership agreement, or (c) applicable laws, occur. Refer to the Guidelines to suspend or remove participants from groups.

3.1.1.2. 利益衝突の指針
Conflict of Interest Policy

W3Cの作業に実質的に加わっている個人は, W3Cでの個人の役割と利益衝突が生じる関係性が分かった場合に, その重要な関係性を開示しなければなりません. これらの開示情報は, 個人の所属が変わった場合や, (例えば, 個人がW3Cに加入または離脱した組織と関係があることで)W3Cとの関係が変わった場合に, 最新に保たれなければなりません. W3Cの部会について述べたこの文書の各節は, それらの部会に対する開示の仕組みについてより詳細な情報を提供します.

Individuals participating materially in W3C work must disclose significant relationships when those relationships might reasonably be perceived as creating a conflict of interest with the individual’s role at W3C. These disclosures must be kept up-to-date as the individual’s affiliations change and W3C membership evolves (since, for example, the individual might have a relationship with an organization that joins or leaves W3C). Each section in this document that describes a W3C group provides more detail about the disclosure mechanisms for that group.

部会内の役割を果たす, 利益衝突が生じる恐れのある個人の力量は, その個人の所属に依存します. それらの所属が変わった場合, その個人の役割の割り当ては, 評価されなければなりません. 役割は, 適切な手続きによって再び割り当てられてもよいです. 例えば, ディレクターは, 現在の部会の議長が所属を変えたときに, (例えば, 利益衝突の恐れがある場合, もしくは, 議長の新しい雇い主がW3Cの活動の中で多くの代表を務めていることになるであろう恐れがある場合,) 新しい議長を指名してもよいです.

The ability of an individual to fulfill a role within a group without risking a conflict of interest depends on the individual’s affiliations. When these affiliations change, the individual’s assignment to the role must be evaluated. The role may be reassigned according to the appropriate process. For instance, the Director may appoint a new group Chair when the current Chair changes affiliations (e.g., if there is a risk of conflict of interest, or if there is risk that the Chair’s new employer will be over-represented within a W3C activity).

次のものは, 開示情報が適切な筋書きの例です.

The following are some scenarios where disclosure is appropriate:

• W3Cに関わる活動を行っている組織の有償のコンサルタント, もしくは, 資本の持ち分(株式の分担, ストックオプション, 企業の資本の他の形式)によって報酬を支払われたコンサルタント.
  Paid consulting for an organization whose activity is relevant to W3C, or any consulting compensated with equity (shares of stock, stock options, or other forms of corporate equity).
• W3Cに関係する他の組織で(理事会における代表といった)意思決定の役割, 責任を負うもの.
  A decision-making role/responsibility (such as participating on the Board) in other organizations relevant to W3C.
• 一切, 意思決定の権限に関係しないとしても, 公に理事者に見える立場の者.
  A position on a publicly visible advisory body, even if no decision-making authority is involved.

これらの事実について助言を求める個人は, 事務局に連絡すべきです.

Individuals seeking assistance on these matters should contact the Team.

事務局の人員は, W3C事務局の利益衝突指針 [衝突指針]を前提としています.

Team members are subject to the W3C Team conflict of interest policy [CONFLICT-POLICY].

3.1.1.3. 会員組織を代表する個人
Individuals Representing a Member Organization

一般に, W3Cの公式な定員の中の会員を代表する個人は, 会員組織の従業員です. ただし, 諮問委員会の委員は, 会員を代表するのに, 従業員でない人を指名してもよいです. 従業員でない会員の代表者は, その個人が参加している事務局や部会において, 所属との関係を開示しなければなりません.

Generally, individuals representing a Member in an official capacity within W3C are employees of the Member organization. However, an Advisory Committee representative may designate a non-employee to represent the Member. Non-employee Member representatives must disclose relevant affiliations to the Team and to any group in which the individual participates.

例外的な状況(例えば, 部会の進展を阻んだり, 利益衝突を生じたりしているであろう状況)において, ディレクターは, 諮問委員会の委員が指名した個人の部会への参加を拒否してもよいです.

In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), the Director may decline to allow an individual designated by an Advisory Committee representative to participate in a group.

部会の憲章は, W3Cの会員(もしくは関連会員のグループ)を代表する個人の人数を制限してもよいです.

A group charter may limit the number of individuals representing a W3C Member (or group of related Members).

3.1.2. 会議
Meetings

この節の要件は, W3C部会の公式な会議に適用されます.

The requirements in this section apply to the official meetings of any W3C group.

W3Cは, 会議を次の2つの形式に区分しています.

W3C distinguishes two types of meetings:

1. 対面での会議は, ほとんどの出席者が, 同じ物理的な場所で参加することが期待される会議です.
   A face-to-face meeting is one where most of the attendees are expected to participate in the same physical location.
2. 分散型の会議は, ほとんどの出席者が, 遠隔で(例えば, 電話, ビデオ会議, IRCで)参加することが期待される会議です.
   A distributed meeting is one where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC).

議長は, 例外的な基準で会議に出席するように, 特に高度な専門知識を持った人物を招待してもよいです. この人物は, 会議の来賓で, 部会の参加者ではありません. 会議の来賓は, 投票権を持ちません. 全ての会議の来賓に憲章で定めれらた秘密保持の水準や部会の他の要件を確実に尊重させることは, 議長の責任です.

A Chair may invite an individual with a particular expertise to attend a meeting on an exceptional basis. This person is a meeting guest, not a group participant. Meeting guests do not have voting rights. It is the responsibility of the Chair to ensure that all meeting guests respect the chartered level of confidentiality and other group requirements.

3.1.2.1. 会議の計画と案内
Meeting Scheduling and Announcements

会議の案内は, 全ての適切な部会のメーリングリスト, すなわち, 予期される会議の参加者に最も関係するメーリングリストに送られるべきです.

Meeting announcements should be sent to all appropriate group mailing lists, i.e. those most relevant to the anticipated meeting participants.

次の表は, 会議を体系付けるために推奨される要件を一覧にしたものです.

The following table lists recommendations for organizing a meeting:

^* (例えば, 旅行の準備など)適切な計画となるよう, 議長は, 会議の日程や場所を十分に前もって通知する責任があります. 会議についてのより期間の短い通知は, 部会の参加者から何も異議が無いという条件で認められます.

^* To allow proper planning (e.g., travel arrangements), the Chair is responsible for giving sufficient advance notice about the date and location of a meeting. Shorter notice for a meeting is allowed provided that there are no objections from group participants.

3.1.2.2. 会議の議事録
Meeting Minutes

部会は, 会議の議事録を作成して保管すべきです. また, 会議の議事を通して行ったどの公式な部会決定も記録しなければなりません. 部会決定の根拠が明確でさえあれば, そのような決定に至った議事の詳細は必要ないです.

Groups should take and retain minutes of their meetings, and must record any official group decisions made during the meeting discussions. Details of the discussion leading to such decisions are not required, provided that the rationale for the group decision is nonetheless clear.

3.1.2.3. 会議の録音等や文字起こし
Meeting Recordings and Transcripts

会議の開始の時に録音等の意思を伝え, 会議の録音等された部分に出席した誰も反対しないのでなければ, 誰も, 会議の録音や録画をしたり, 自動文字起こしを保存したりしてはなりません. 誰かから反対された場合, 録音等や保存は行ってはなりません. 録音等の案内は, (a)誰が録音等や文字起こしを確認できるか, (b)録音等の目的や利用方法, (c)どのように(例えば, 個別の環境で, クラウドサービスで)どの程度の期間保存するのかを網羅しなければなりません.

No-one may take an audio or video recording of a meeting, or retain an automated transcript, unless the intent is announced at the start of the meeting, and no-one participating in the recorded portion of the meeting withholds consent. If consent is withheld by anyone, recording/retention must not occur. The announcement must cover: (a) who will have access to the recording or transcript and (b) the purpose/use of it and (c) how it will be retained (e.g. privately, in a cloud service) and for how long.

3.1.3. 議論や公開のためのツール
Tooling for Discussions and Publications

この手続き文書の下で運用されているW3C部会に対し, 核となる運用の原則は, 障害, 国境, 時間を超えて利用できるようにすることです. よって, 参加者になる予定の人全てが効果的に参加できるようにし, 将来の参加者や立ち合い者が最新の決定の根拠や由来を理解できるようにし, 発行物の永続的な利用を保証するために, W3Cは, 次のようにする必要があります.

For W3C Groups operating under this Process, a core operating principle is to allow access across disabilities, across country borders, and across time. Thus in order to allow all would-be participants to effectively participate, to allow future participants and observers to understand the rationale and origins of current decisions, and to guarantee long-lived access to its publications, W3C requires that:

• 部会によって一般社会に提案された(すなわち, 自分達以外からの利用や参照を意図した)全ての報告書, 発行物, その他の成果は, W3Cが管理するURIで発行, 紹介されるべきです. 基礎をなすサービスが停止した場合に, 後を受け継ぐリンクや他の鍵となる機能無しで, W3Cがそれらの内容を提供し続けられるW3Cのシステムで代替されるべきです.
  All reports, publications, or other deliverables produced by the group for public consumption (i.e. intended for use or reference outside its own membership) should be published and promoted at a W3C-controlled URL, and backed up by W3C systems such that if the underlying service is discontinued, W3C can continue to serve such content without breaking incoming links or other key functionality.
• 部会によって一般社会に提供された全ての報告書, 発行物, その他の成果は, 国際化や障害のある人々のアクセシビリティに対し最善の実践を行うべきです. W3Cが管理するドメインを利用するネットワークが想定されるかもしれません.
  All reports, publications, or other deliverables produced by the group for public consumption should follow best practices for internationalization and for accessibility to people with disabilities. Network access to W3C-controlled domains may be assumed.
• 公式な会議の議事録や他の決定の記録は, W3Cによって将来参照できるように保存されなければなりません. 部会で提案された, 部会の作業に関連し, 部会の全てのメンバーから参照できるよう意図された他の永続的な文字での議論も, 同様であるべきです. これらの議論は, メーリングリストを通して行われたもの, また, 課題を記録するサービスや, 何らかの同じような公共の場で行われたものを含みます.
  Official meeting minutes and other records of decisions made must be archived by W3C for future reference; and other persistent text-based discussions sponsored by the group, pertaining to their work and intended to be referenceable by all group members should be. This includes discussions conducted over email lists or in issue-tracking services or any equivalent fora.

  注意:そのような保存されたものの不足や消失は, そのこと自体が, 他の有効な決定を無効にすることはありません.

  Note: The lack, or loss, of such archives does not by itself invalidate an otherwise-valid decision.

• 文書や成果の提供または公式な部会の議論のために部会が利用している何らかのツールは, 効果的な参加を可能とするために, 障害のある人々を含む, 参加したいと願う全ての人々から(追加の費用無しで)利用可能であるべきです.
  Any tooling used by the group for producing its documentation and deliverables or for official group discussions should be usable (without additional cost) by all who wish to participate, including people with disabilities, to allow their effective participation.

  注意:そのツールを利用できない新しい参加者が加わった場合, このことは作業部会にツールを変更するか, 何らかの処置を講じることを必要とするでしょう.

  Note: If a new participant joins who cannot use the tool, this can require the Working Group to change its tooling or operate some workaround.

• 部会によって議論や記録管理のために利用される, 全てのツールや保存されたものは, 新しい参加者や立ち合い者が部会のツールや記録を簡単に見つけられるように文書化されるべきです.
  All tools and archives used by the group for its discussions and recordkeeping should be documented such that new participants and observers can easily find the group’s tools and records.

事務局は, これらの決まりに対する支持を確実にし, 従わない部会を従わせるようにする責任があります.

The Team is responsible for ensuring adherence to these rules and for bringing any group not in compliance into compliance.

3.1.4. 部会からの辞任
Resignation from a Group

W3C会員または外部の専門家は, 部会を辞めてもよいです. 諮問委員会の委員または外部の専門家から事務局への書面での告知によって, 会員とその代表者, または外部の専門家は, 関係する部会から辞めることになると考えられるでしょう. 事務局は, その告知を記録しなければなりません. ある部会を辞めた後に残る義務についての情報については, W3C特許指針[特許指針]の“作業部会からの除名と辞任” を参照して下さい.

A W3C Member or Invited Expert may resign from a group. On written notification from an Advisory Committee representative or Invited Expert to the team, the Member and their representatives or the Invited Expert will be deemed to have resigned from the relevant group. The team must record the notification. See “Exclusion and Resignation from the Working Group” in the W3C Patent Policy [PATENT-POLICY] for information about obligations remaining after resignation from certain groups.

3.2. 諮問委員会(AC)
The Advisory Committee (AC)

3.2.1. 諮問委員会の役割
Role of the Advisory Committee

諮問委員会は, W3C全体としての会員を代表します. 諮問委員会は次のことに責任があります.

The Advisory Committee represents the Members of the W3C at large. It is responsible for:

• 各諮問委員会の会議におけるW3Cの計画の審査.
  reviewing plans for W3C at each Advisory Committee meeting.
• 憲章の提案, 勧告案, 手続き文書案といったW3Cの正式な提案の審査.
  reviewing formal proposals of the W3C: Charter Proposals, Proposed Recommendations, and Proposed Process Documents.
• 諮問会議の議長以外の諮問会議の委員の選挙.
  electing the Advisory Board participants other than the Advisory Board Chair.
• 技術諮問委員会の委員の過半数(6)の選挙.
  electing a majority (6) of the participants on the Technical Architecture Group.

諮問委員会の委員は, W3C決定またはディレクター決定に対する諮問委員会の抗議を提出してもよいです.

Advisory Committee representatives may initiate an Advisory Committee Appeal of a W3C decision or Director's decision.

W3C特許指針[特許指針]で述べられている諮問委員会の委員の追加の役割も参照して下さい.

See also the additional roles of Advisory Committee representatives described in the W3C Patent Policy [PATENT-POLICY].

3.2.2. 諮問委員会への参加
Participation in the Advisory Committee

諮問委員会は, 各会員組織の1人の代表者で構成されます(最新のW3C会員の一覧[会員一覧]の会員限定の一覧を参照して下さい).

The Advisory Committee is composed of one representative from each Member organization (refer to the Member-only list of current Advisory Committee representatives. [CURRENT-AC])

組織がW3Cに加入するとき(“W3Cに加入するには” [加入]参照), 組織は, 会員規約の一環として諮問委員会の委員を指名しなければなりません. 新会員オリエンテーション [導入]は, 諮問委員会メーリングリストへの参加申込の仕方と脱退の仕方について説明し, 諮問委員会の会議の情報を提供し, 新しい諮問委員会の委員の指名の仕方を説明するなどしています. 諮問委員会の委員は, 新会員オリエンテーションで説明されている仕組みによって情報を開示することで, 利益衝突の指針に従わなければなりません.

When an organization joins W3C (see “How to Join W3C” [JOIN]), it must name its Advisory Committee representative as part of the Membership Agreement. The New Member Orientation [INTRO] explains how to subscribe or unsubscribe to Advisory Committee mailing lists, provides information about Advisory Committee Meetings, explains how to name a new Advisory Committee representative, and more. Advisory Committee representatives must follow the conflict of interest policy by disclosing information according to the mechanisms described in the New Member Orientation.

ACの委員は, (代理人を指名する権限を除いて)何らかの会員の権利と責任を代理人に委任してもよいです.

The AC representative may delegate any of their rights and responsibilities to an alternate (except the ability to designate an alternate).

3.2.3. 諮問委員会メーリングリスト
Advisory Committee Mailing Lists

事務局は, 諮問委員会の利用のために, 2つのメーリングリストを提供しなければなりません.

The Team must provide two mailing lists for use by the Advisory Committee:

1. 事務局から諮問委員会への公式な通知(例えば, この文書で必要とされている通知)のためのメーリングリスト. このメーリングリストは, 諮問委員会の委員に対しては, 受け取り専用です.
   One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is read-only for Advisory Committee representatives.
2. 諮問委員会の委員間の議論のためのメーリングリスト. このメーリングリストは, 第一に諮問委員会の委員のためのものですが, 事務局は議論を監視しなければならず, 適切なときに議論に参加すべきです. 進行中の詳細な議論は, (新規または既存の, ワークショップのために作られるメーリングリストといった)他の適切なメーリングリストに移るべきです.
   One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee representatives, the Team must monitor discussion and should participate in discussion when appropriate. Ongoing detailed discussions should be moved to other appropriate lists (new or existing, such as a mailing list created for a Workshop).

諮問委員会の委員は, 自分達の組織から追加の人物を, これらのメーリングリストに参加させるよう依頼してもよいです. 配信に含められない場合は, 事務局の裁量で, 内部的に追加のメールアドレスの一時停止に至ってもよいです.

An Advisory Committee representative may request that additional individuals from their organization be subscribed to these lists. Failure to contain distribution internally may result in suspension of additional email addresses, at the discretion of the Team.

3.2.4. 諮問委員会の会議
Advisory Committee Meetings

事務局は, 諮問委員会の対面での会議を年2回開催します. 事務局は, (一般にCEO(訳注:最高経営責任者)である)それらの会議の議長を指名します. 諮問委員会の各会議では, 事務局は, 次の内容について諮問委員会に関する最新情報を提供すべきです.

The Team organizes a face-to-face meeting for the Advisory Committee twice a year. The Team appoints the Chair of these meetings (generally the CEO). At each Advisory Committee meeting, the Team should provide an update to the Advisory Committee about:

資源
Resources

• 各段階のW3C会員の数.
  The number of W3C Members at each level.
• W3Cの財務状態の概要.
  An overview of the financial status of W3C.

配分
Allocations

• 事務局の大きさや, おおよその配置を含めた, 年次予算の配分.
  The allocation of the annual budget, including size of the Team and their approximate deployment.
• (主に作業部会や関連部会を含めた)全ての活動の一覧, および特に前回の諮問委員会以降に開始または終了した活動を中心とした各活動の簡潔な報告書.
  A list of all activities (including but not limited to Working and Interest Groups) and brief status statement about each, in particular those started or terminated since the previous Advisory Committee meeting.
• 他の組織との連絡体制を続けるための資源の配分.
  The allocation of resources to pursuing liaisons with other organizations.

各会員組織は, 諮問委員会の各会議に1名の代表者を送るべきです. 特別な事情がある場合に(例えば, 組織からの代表者の交代の時期である場合に), 会議の議長は, 会員組織が会議に2名の代表者を送ることを認めてもよいです.

Each Member organization should send one representative to each Advisory Committee Meeting. In exceptional circumstances (e.g., during a period of transition between representatives from an organization), the meeting Chair may allow a Member organization to send two representatives to a meeting.

事務局は, 諮問委員会の各会議の時間と場所を, 遅くとも前回の会議の終了までに通知しなければなりません. 1年分の通知が望ましいです. 事務局は, 前もって今後1年の諮問委員会の各会議の地域を通知しなければなりません.

The Team must announce the date and location of each Advisory Committee meeting no later than at the end of the previous meeting; one year’s notice is preferred. The Team must announce the region of each Advisory Committee meeting at least one year in advance.

諮問委員会の会議 [AC会議]についてのより詳しい情報は, 会員ウェブページで確認できます.

More information about Advisory Committee meetings [AC-MEETING] is available at the Member Web site.

3.3. 選挙で選ばれる部会:ABとTAG
Elected Groups: The AB and the TAG

W3C手続き文書は, 諮問委員会から選挙で選ばれる諮問会議(AB)と技術諮問委員会(TAG)といった2種類の選挙で選ばれる部会を定義しています.

The W3C Process defines two types of elected groups: the Advisory Board (AB) and the Technical Architecture Group (TAG), both elected by the Advisory Committee.

3.3.1. 諮問会議(AB)
Advisory Board (AB)

3.3.1.1. 諮問会議の役割
Role of the Advisory Board

諮問会議は, 計画, 管理, 法的問題, 手続き, 利益衝突の解決の課題において, 事務局に継続的な助言を提供しています. 諮問会議は, 諮問委員会で挙げられた課題を追跡したり, そのような課題に会員の意見を求めたり, それらの課題を解決するための活動を提案したりすることで, 会員のために尽くしてもいます. 諮問会議は, 手続き文書の発展を管理しています. 諮問会議は, 会員提案がウェブ技術体系とは無関係な理由で却下されたときに, 提案の抗議を聞き取りします. TAGも参照して下さい.

The Advisory Board provides ongoing guidance to the Team on issues of strategy, management, legal matters, process, and conflict resolution. The Advisory Board also serves the Members by tracking issues raised between Advisory Committee meetings, soliciting Member comments on such issues, and proposing actions to resolve these issues. The Advisory Board manages the evolution of the Process Document. The Advisory Board hears a Submission Appeal when a Member Submission is rejected for reasons unrelated to Web architecture; see also the TAG.

諮問会議は, 管理者の理事会ではなく, W3Cの中で何ら決定を行う権限を持っていません. その役割は, 厳密に諮問を行うことです.

The Advisory Board is not a board of directors and has no decision-making authority within W3C; its role is strictly advisory.

諮問会議の詳細(例えば, 諮問会議の委員の一覧, メーリングリストの情報, 諮問会議の議事の要約)は, 諮問会議ホームページ [AB-HP]で確認できます.

Details about the Advisory Board (e.g., the list of Advisory Board participants, mailing list information, and summaries of Advisory Board meetings) are available at the Advisory Board home page [AB-HP].

3.3.1.2. 諮問会議の構成
Composition of the Advisory Board

諮問会議は, 9名から11名の選挙で選ばれる委員と(その委員のうちの1人でもよい)議長から構成されます. ABでの貢献度に応じて, 事務局は, 委員の中から共同議長として選ぶべきである議長を指名します. 議長(ら)は, ABの各任期の始めに, その指名に基づいてABの無記名投票による2/3の承認を条件としています. その任期に§ 3.4.1 全ての憲章を持つ部会に対する要件で述べる事務局の連絡員も指名されます. CEOと事務局の連絡員は, 全ての通常の諮問会議の会合に常に招待されます.

The Advisory Board consists of nine to eleven elected participants and one Chair (who may be one of the elected participants). With the input of the AB, the Team appoints the Chair, who should choose a co-chair among the elected participants. The Chair(s) are subject to ratification by secret ballot by two thirds of the AB upon appointment and at the start of each AB term. The team also appoints a Team Contact, as described in § 3.4.1 Requirements for All Chartered Groups. The CEO and Team Contact have a standing invitation to all regular Advisory Board sessions.

9名から11名の諮問会議の委員は, W3C諮問委員会によって, AB/TAG 推薦と選挙の手続きに従って選ばれます.

The nine to eleven Advisory Board participants are elected by the W3C Advisory Committee following the AB/TAG nomination and election process.

選出された諮問会議の委員の任期は, 2年間です. 任期はずれているので, 毎年5名もしくは6名の任期が終了します. 誰か個人が未完了の任期を埋めるために選ばれたなら, その個人の任期は, その任期の通常の満期に終了します. 通常の諮問会議の任期は, 7月1日に始まり, 6月30日に終了します.

The terms of elected Advisory Board participants are for two years. Terms are staggered so that each year, either five or six terms expire. If an individual is elected to fill an incomplete term, that individual’s term ends at the normal expiration date of that term. Regular Advisory Board terms begin on 1 July and end on 30 June.

3.3.1.3. 諮問会議の連絡調整
Communications of the Advisory Board

事務局は, 諮問会議と事務局限定のメーリングリストを, 諮問会議の連絡のために利用可能にしなければなりません.

The Team must make available a mailing list, confidential to the Advisory Board and Team, for the Advisory Board to use for its communication.

諮問会議は, 会議ごとの要約を諮問委員会と各部会の議長に送るべきです. 諮問会議は, 諮問委員会の会議の度に, 自身の活動報告も行うべきです.

The Advisory Board should send a summary of each of its meetings to the Advisory Committee and other group Chairs. The Advisory Board should also report on its activities at each Advisory Committee meeting.

3.3.2. 技術諮問委員会(TAG)
Technical Architecture Group (TAG)

3.3.2.1. 技術諮問委員会の役割
Role of the Technical Architecture Group

TAGの使命は, ウェブ技術体系について, まとめ役を果たすことです. この使命には, 次の3つの側面があります.

The mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:

1. ウェブ技術体系の基本原則について, 根拠を提供し, 合意を形成すること. また, 必要な場合にその基本原則を解釈し, 明確化すること.
   to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;
2. TAGに提起された一般的なウェブ技術体系に関係する課題を解決すること.
   to resolve issues involving general Web architecture brought to the TAG;
3. W3C内外の複数分野にまたがった技術に関して, 技術開発の調整を手助けすること.
   to help coordinate cross-technology architecture developments inside and outside W3C.

TAGは, 会員提案がウェブ技術体系に関係した理由で却下されたときに, 提案の抗議を聞き取りします. 諮問会議も参照して下さい.

The TAG hears a Submission Appeal when a Member Submission is rejected for reasons related to Web architecture; see also the Advisory Board.

TAGの権限の範囲は, ウェブ技術体系の技術的課題に限られます. TAGは, 一般にW3C諮問委員会, 諮問会議, 事務局が処理すべきW3Cの管理, 手続き, 組織統治の課題について議論すべきではありません. TAGの背景や権限の範囲についての詳しい情報, またTAG委員に期待される適正に関しては, TAG憲章 [TAG憲章]を参照して下さい.

The TAG's scope is limited to technical issues about Web architecture. The TAG should not consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee, Advisory Board, and Team. Please refer to the TAG charter [TAG-CHARTER] for more information about the background and scope of the TAG, and the expected qualifications of TAG participants.

TAGが課題の解決のために投票を行う場合, TAGの各参加者は, (指名されたか, 選任されたか, 議長であるかに関わらず)1票を持ちます. TAG憲章の投票 [TAG憲章]の節, およびこの手続き文書の一般的な投票についての節も参照して下さい.

When the TAG votes to resolve an issue, each TAG participant (whether appointed, elected, or the Chair) has one vote; see also the section on voting in the TAG charter [TAG-CHARTER] and the general section on votes in this Process Document.

TAGの詳細(例えば, TAGの委員の一覧, メーリングリストの情報, TAGの議事の要約)は, TAGホームページ [TAG-HP]で確認できます.

Details about the TAG (e.g., the list of TAG participants, mailing list information, and summaries of TAG meetings) are available at the TAG home page [TAG-HP].

3.3.2.2. 技術諮問委員会の構成
Composition of the Technical Architecture Group

TAGは, 次の人々から構成されます.

The TAG consists of:

• 終身会員であるTim Berners-Lee.
  Tim Berners-Lee, who is a life member;
• 職務上のディレクター.
  The Director, sitting ex officio;
• ディレクターに指名された3名の委員.
  Three participants appointed by the Director;
• 諮問委員会により, AB/TAG 推薦と選挙の手続きに従って選任された6名の委員.
  Six participants elected by the Advisory Committee following the AB/TAG nomination and election process.

事務局は, 委員の1人でなければならないTAGの議長を指名します. 事務局は§ 3.4.1 全ての憲章を持つ部会に対する要件で述べているように, TAGに対する事務局の連絡員 [事務局の連絡員]も指名します.

The Team appoints the Chair of the TAG, who must be one of the participants. The team also appoints a Team Contact [TEAM-CONTACT] for the TAG, as described in § 3.4.1 Requirements for All Chartered Groups.

選任された, またはディレクターに指名されたTAGの委員の任期は2年間です. 任期はずれているので, 毎年3名の選任された委員の任期と, 1名もしくは2名の指名された委員の任期が終了します. 誰か個人が未完了の任期を埋めるために指名されたか選任されたならば, その個人の任期は, その任期の通常の満期に終了します.

The terms of elected and Director-appointed TAG participants are for two years. Terms are staggered so that each year three elected terms, and either one or two appointed terms expire. If an individual is appointed or elected to fill an incomplete term, that individual’s term ends at the normal expiration date of that term. Regular TAG terms begin on 1 February and end on 31 January.

ディレクターは, 諮問委員会が委員を選任した結果を公表した後に, 指名した委員を公表してもよいです.

The Director may announce the appointed participants after the results for the Advisory Committee election of participants have been announced.

3.3.2.3. 技術諮問委員会の連絡調整
Communications of the Technical Architecture Group

事務局は, TAGに対する2つのメーリングリストを利用できるようにしなければなりません.

The Team must make available two mailing lists for the TAG:

• ウェブ技術体系の課題に対する, 公開の議論の(単に入力に限らない)メーリングリスト. TAGは, このメーリングリストでの公の業務を管理するでしょう.
  a public discussion (not just input) list for issues of Web architecture. The TAG will conduct its public business on this list.
• TAGとの議論や, 何らかの理由で公開のメーリングリストに送ることができない依頼のための, 会員限定のメーリングリスト.
  a Member-only list for discussions within the TAG and for requests to the TAG that, for whatever reason, cannot be made on the public list.

TAGは, 追加の特定の項目に対する公開のメーリングリストの作成を要求してもよいです. TAGのいくつかの議論(例えば, 提案の抗議)のためであれば, TAGは, 会員限定となるメーリングリストを利用してもよいです.

The TAG may also request the creation of additional topic-specific, public mailing lists. For some TAG discussions (e.g., a Submission Appeal), the TAG may use a list that will be Member-only.

TAGは, 会議ごとの要約を, 諮問委員会や他の部会の議長に送るべきです. TAGは, 諮問委員会の会議の度に, 自身の活動報告も行うべきです.

The TAG should send a summary of each of its meetings to the Advisory Committee and other group Chairs. The TAG should also report on its activities at each Advisory Committee meeting.

3.3.3. 選挙で選ばれる部会の委員
Participation in Elected Groups

3.3.3.1. 選挙で選ばれる部会の委員への期待
Expectations for Elected Groups Participants

諮問会議とTAGの委員は, W3Cで特別な役割を持っています. 委員らは, 特定の通信網, 技術, 企業, 利用者のためだけでなく, ウェブのための最善の解決方法を見つけるよう, 最善の判断を行うことを期待されて, 会員から選任され, ディレクターから指名されています. 諮問会議とTAGの委員は, 定期的に全てに参加することを期待されています. 諮問会議とTAGの委員は, 諮問委員会の会議に出席すべきです.

Advisory Board and TAG participants have a special role within W3C: they are elected by the Membership and appointed by the Director with the expectation that they will use their best judgment to find the best solutions for the Web, not just for any particular network, technology, vendor, or user. Advisory Board and TAG participants are expected to participate regularly and fully. Advisory Board and TAG participants should attend Advisory Committee meetings.

諮問会議とTAGに選任または指名された人物は, W3C会員全体やウェブ界隈の必要性を満たすために, 個々の能力の中で活動します. その人物が会員の代表者であろうが, 外部の専門家であろうが, その役割における活動は, 諮問会議またはTAGでの活動とは引き離され, 別個のものです.

Individuals elected or appointed to the Advisory Board or TAG act in their personal capacity, to serve the needs of the W3C membership as a whole, and the Web community. Whether they are Member representatives or Invited Experts, their activities in those roles are separate and distinct from their activities on the Advisory Board or TAG.

個人が諮問会議またはTAGに参加するのは, その個人の任期が始まった瞬間から, (例えば, 任期の終了によって)席を退任するまでの間です. 諮問会議やTAGの委員は, その委員の雇用主の営業利益を主張しないにも関わらず, その委員らの参加は, (AB/TAG 推薦と選挙の手続きの節で述べるように)会員の代表者, 外部の専門家の状況, 事務局の代表者と結び付く責任を持っています.

An individual participates on the Advisory Board or TAG from the moment the individual’s term begins until the seat is vacated (e.g. because the term ends). Although Advisory Board and TAG participants do not advocate for the commercial interests of their employers, their participation does carry the responsibilities associated with Member representation, Invited Expert status, or Team representation (as described in the section on the AB/TAG nomination and election process).

TAGまたはABへの参加は, 選任または指名された特定の人物に地位を与え, 委員の席は, 他の誰にも委任してはなりません.

Participation in the TAG or AB is afforded to the specific individuals elected or appointed to those positions, and a participant’s seat must not be delegated to any other person.

3.3.3.2. 選挙で選ばれる部会の委員の制限
Elected Groups Participation Constraints

W3C会員の多様性が表現されることを確実にするため, 諮問会議とTAGにおける若干の席が割り当てられています.

Given the few seats available on the Advisory Board and the TAG, and in order to ensure that the diversity of W3C Members is represented:

• § 3.3.3.3 諮問会議と技術諮問委員会の選挙を通じて, 第一の所属が同じ2名の委員は, 既存の委員の所属が変わったことに起因する場合を除いて, TAGの選任された席を同時に占有してはなりません. TAGに対する次の定期で予定されている選任期間が完了したとき, その組織は、多くても1つの持っている席を返さなければなりません.
  Two participants with the same primary affiliation per § 3.3.3.3 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the TAG except when this is caused by a change of affiliation of an existing participant. At the completion of the next regularly scheduled election for the TAG, the organization must have returned to having at most one seat.
• § 3.3.3.3 諮問会議と技術諮問委員会の選挙を通じて, 第一の所属が同じ2名の委員は, ABの選任された席を同時に占有してはなりません. いかなる理由でも(例え, ABの委員が仕事を変わったためであっても), この制限が満たされない場合, その状況が解消しない限り, 1名の委員は, ABの委員を退任しなければなりません. 30日経ってもその状況が解消しない場合, 議長は, 後で述べる証明可能な無作為選択手続きを適用して, 委員を続ける1名を選び, 他の席の退任を宣言するでしょう.
  Two participants with the same primary affiliation per § 3.3.3.3 Advisory Board and Technical Architecture Group Elections must not both occupy elected seats on the AB. If, for whatever reason, these constraints are not satisfied (e.g., because an AB participant changes jobs), one participant must cease AB participation until the situation has been resolved. If after 30 days the situation has not been resolved, the Chair will apply the verifiable random selection procedure described below to choose one person for continued participation and declare the other seat(s) vacant.
• 同じ人物が, TAGとAB両方の委員をしてはなりません.
  An individual must not participate on both the TAG and the AB.

3.3.3.3. 諮問会議と技術諮問委員会の選挙
Advisory Board and Technical Architecture Group Elections

諮問会議と技術諮問委員会の一部は, 諮問委員会によって, 単記移譲式投票システムを用いて選任されます. 事務局が諮問委員会に推薦の要請を送ったときに, 選挙の手続きが始まります. どの推薦の要請も, 最小と最大の対象の席, 推薦の締切, 選挙のために事務局が選んだ特定の投票集計システムの詳細, どのように候補を推薦するかといった運営上の情報を指定します. 事務局は, 推薦の要請の後に投票集計システムを修正してもよいですが, 遅くとも投票の要請までに確定させなければなりません. 事務局は, 遅くとも推薦の手続きの一部である推薦期間の開始までに, 指名を表明すべきです.

The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, using a Single Transferable Vote system. An election begins when the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the minimum and maximum number of available seats, the deadline for nominations, details about the specific vote tabulation system selected by the Team for the election, and operational information such as how to nominate a candidate. The Team may modify the tabulation system after the Call for Nominations but must stabilize it no later than the Call for Votes. The Team should announce appointments no later than the start of a nomination period as part of the Call for Nominations.

TAGの定期で予定されている選挙において, 最小と最大の対象となる席は同じです. その年に任期が終わる3席に, 退任したか, もしくは新しく選任されたメンバーが席を努め始めるまでに, 退任するであろう他の席の数を加えた数です.

In the case of regularly scheduled elections of the TAG, the minimum and maximum number of available seats are the same: the 3 seats of the terms expiring that year, plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats.

ABの定期で予定されている選挙において, 最小と最大の対象となる席は異なります. 最大の数は, その年に任期が終了する5席または6席に, 退任したか, もしくは新しく選任されたメンバーが席を努め始めるまでに, 退任するであろう他の席の数を加えた数です. 最小の数は, 前の年から占められている席にその数を加えたときに, ABの最小の大きさ(9名)に達するような数です.

In the case of regularly scheduled elections of the AB, the minimum and maximum number of available seats differ: The maximum number is the 5 or 6 seats of the terms expiring that year, plus the number of other seats that are vacant or will be vacant by the time the newly elected members take their seats; the minimum number is such that when added to the occupied seats from the prior year, the minimum size of the AB (9) is reached.

各会員(または関連会員のグループ)は, 1名の候補者を推薦してもよいです. 推薦は, 候補者の同意を得なければなりません. 候補者が会員の代表として推薦されるためには, その候補者は会員の代表の資格を得なければならず, 会員の諮問委員会の委員は, 推薦に作業部会における会員の代表者に対して必要な情報(と同じ内容)を付け加えなければなりません. 候補者が外部の専門家として推薦されるためには, その候補者は作業部会における外部の専門家に対して必要な情報(と同じ内容)を提供しなければならず, 推薦した諮問委員会の委員はその情報を推薦に付け加えなければなりません. 候補者が事務局の代表者として推薦されるためには, 推薦する諮問委員会の委員は, 事務局の運営から最善の確実な賛成を得なければなりません. 候補者は, 会員組織の従業員である必要はなく, W3C特別研究員でもよいです. 推薦の書式は, 候補者の第一の所属を問わなければならず, その所属は投票用紙に報告されるでしょう. ほとんどの候補者において, 第一の所属は, その人の雇用主で, W3Cのデータベースのその人の所属と一致するでしょう. 契約者や外部の専門家において, 第一の所属は, 通常, その契約者が契約している企業か, 外部の専門家の状況によります. 状況によって(例えば, コンサルタントが1つの組織のみをコンサルティングしている場合には), 第一の所属は, 候補者がコンサルティングしている組織になってよいです. 所属の変更は, 候補者が再度推薦された場合に, 候補者の分野が異なる回答となるような場合に限定されます(その結果, 雇用の終了, また新しい雇用の了承は, 所属の変更です). (他の契約といった他の公式な関係は, 潜在的な利益衝突として開示されるべきです.) 各推薦は, 候補者についての若干の有益な寸評を付け加えるべきです.

Each Member (or group of related Members) may nominate one individual. A nomination must be made with the consent of the nominee. In order for an individual to be nominated as a Member representative, the individual must qualify for Member representation and the Member’s Advisory Committee representative must include in the nomination the (same) information required for a Member representative in a Working Group. In order for an individual to be nominated as an Invited Expert, the individual must provide the (same) information required for an Invited Expert in a Working Group and the nominating Advisory Committee representative must include that information in the nomination. In order for an individual to be nominated as a Team representative, the nominating Advisory Committee representative must first secure approval from Team management. A nominee is not required to be an employee of a Member organization, and may be a W3C Fellow. The nomination form must ask for the nominee’s primary affiliation, and this will be reported on the ballot. For most nominees, the primary affiliation is their employer and will match their affiliation in the W3C database. For contractors and invited experts, this will normally be their contracting company or their invited expert status; in some cases (e.g. where a consultant is consulting for only one organization) this may be the organization for whom the nominee is consulting. A change of affiliation is defined such that this field would carry a different answer if the nominee were to be re-nominated (therefore, terminating employment, or accepting new employment, are changes of affiliation). (Other formal relationships such as other contracts should be disclosed as potential conflicts of interest.) Each nomination should include a few informative paragraphs about the nominee.

推薦の締切の後に, 候補者の人数によって次のように区分されます.

If, after the deadline for nominations, the number of nominees is:

• 対象となる席の最小の数より大きいか等しく, 対象となる席の最大の数より小さいか等しい場合, 候補者は, そのことをもって選任されます. この状況は, 未完了の任期に割り当てる結果と同様と考えられます. さらに, 数が対象となる席の最大の数より小さい場合, 長い任期がまず埋められます.
  Greater than or equal to the minimum number of available seats and less than or equal to the maximum number of available seats, those nominees are thereby elected. This situation constitutes a tie for the purpose of assigning incomplete terms. Furthermore, if the number is less than the maximum number of available seats, the longest terms are filled first.
• 対象となる席の最小の数より小さい場合, 十分な人数の人々が推薦されるまで, 推薦の要請が発せられます. 既に推薦されている候補者は, 新たに発せられる要請の後に, 再度推薦される必要はありません.
  Less than the minimum number of available seats, Calls for Nominations are issued until a sufficient number of people have been nominated. Those already nominated do not need to be renominated after a renewed call.
• 対象となる席の最大の数より大きい場合, 事務局は, 全ての候補の名前, 対象となる席の(最大の)数, 投票の締切, 選挙のために事務局が選んだ投票集計システムの詳細, 運営上の情報を含む投票の要請を発します.
  Greater than the maximum number of available seats, the Team issues a Call for Votes that includes the names of all candidates, the (maximum) number of available seats, the deadline for votes, details about the vote tabulation system selected by the Team for the election, and operational information.

投票の際, 各会員(関連会員のグループ)は, 会員の望ましい順に候補者を並べた1票を提出してもよいです. 一旦, 投票を締め切った後, 事務局は諮問委員会に結果を通知します. 同票の場合は, 後で述べる証明可能な無作為選択手続きが対象となる席を埋めるために利用されるでしょう.

When there is a vote, each Member (or group of related Members) may submit one ballot that ranks candidates in the Member’s preferred order. Once the deadline for votes has passed, the Team announces the results to the Advisory Committee. In case of a tie the verifiable random selection procedure described below will be used to fill the available seats.

最も短い未完了の任期は, 投票の集計で最も低かった選任された候補者に割り当てられ, 次に短い任期は, 次に低かった選任された候補者にといった具合になります. 未完了の任期に適当な候補者の間で同点の状況では, 後で述べる証明可能な無作為選択手続きが未完了の任期を割り当てるのに利用されるでしょう.

The shortest incomplete term is assigned to the elected candidate ranked lowest by the tabulation of votes, the next shortest term to the next-lowest ranked elected candidate, and so on. In the case of a tie among those eligible for a incomplete term, the verifiable random selection procedure described below will be used to assign the incomplete term.

より詳細な内容については, 諮問会議とTAGの選挙をどのように系統立てるか [選挙の方法]を参照して下さい.

Refer to How to Organize an Advisory Board or TAG election [ELECTION-HOWTO] for more details.

3.3.3.4. 証明可能な無作為選択手続き
Verifiable Random Selection Procedure

証明可能な無作為選択手続きを利用する必要がある場合(例えば, ABまたはTAGの選挙で同点の状況, もしくは未完了の任期を埋めるために“くじ引き”を行う必要がある場合), W3Cは, RFC 3797 [RFC3797]で定義された無作為で証明可能な選択手続きを利用します. この手続きは, (他に指定がなければ, 姓のアルファベット順の)名前の入力された一覧を“結果の順番”で並び替えます.

When it is necessary to use a verifiable random selection process (e.g., in an AB or TAG election, to “draw straws” in case of a tie or to fill a incomplete term), W3C uses the random and verifiable procedure defined in RFC 3797 [RFC3797]. The procedure orders an input list of names (listed in alphabetical order by family name unless otherwise specified) into a “result order”.

W3Cは, 次の場合にこの手続きを適用します.

W3C applies this procedure as follows:

1. N人が(Nより少ない)M席に対して同点の場合. この場合, 同点だったN人の人物の名前のみが, 手続きに入力として提供されます. M席は, 結果の順番を基に割り当てられます.
   When N people have tied for M (less than N) seats. In this case, only the names of the N individuals who tied are provided as input to the procedure. The M seats are assigned in result order.
2. 全ての選任される人物か確定した後で, N人が(Nより少ない)M席の未完了の任期に適任な場合. この場合, それらのN人の人物の名前のみが, 手続きに入力として提供されます. 未完了の任期は, 結果の順番を基に割り当てられます.
   After all elected individuals have been identified, when N people are eligible for M (less than N) incomplete terms. In this case, only the names of those N individuals are provided as input to the procedure. The incomplete terms are assigned in result order.

3.3.3.5. 選挙で選ばれる部会の退任
Elected Groups Vacated Seats

諮問会議またはTAGの委員は, 次のいずれかの場合に席を退任します.

An Advisory Board or TAG participant’s seat is vacated when:

• 委員が辞任した場合.
  the participant resigns, or
• 諮問会議とTAGの委員が, 諮問会議とTAGの委員の制限にもはや抵触するような所属に変わった場合.
  an Advisory Board or TAG participant changes affiliations such that the Advisory Board and TAG participation constraints are no longer met, or
• ディレクターが§ 3.1.1 個人の参加基準の節に示した基準に抵触する過失を犯した委員を解任した場合.
  the Director dismisses the participant for failing to meet the criteria in section § 3.1.1 Individual Participation Criteria, or
• 委員の任期が終了した場合.
  their term ends.

委員が所属を変わったが, 委員の制限に抵触しない場合, その委員の席は, 次の定期で予定されているその委員会の選挙のときに退任します.

If a participant changes affiliation, but the participation constraints are met, that participant’s seat becomes vacant at the next regularly scheduled election for that group.

退任された席は, 次の日程で埋められます.

Vacated seats are filled according to this schedule:

• 退任された席が指名されたTAGの席の場合, ディレクターは, 直ちに誰かを再指名してもよいです. ただし, 次の定期で予定されている選挙より遅くなることの無いように指名します.
  When an appointed TAG seat is vacated, the Director may re-appoint someone immediately, but no later than the next regularly scheduled election.
• 退任された席がABまたはTAGのどちらかの選任された席の場合, その委員会の議長が, 次の定期で予定されている選挙より前に, (例えば, その委員会の仕事量のために)W3Cが選挙を開催するよう求めない限り, 次の定期のときに埋められます.
  When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election for the group unless the group Chair requests that W3C hold an election before then (for instance, due to the group’s workload).
  • 委員会の議長は, 次の定期で予定されている選挙が3ヵ月以内である場合, そのような選挙の要請を行うべきではありません.
    The group Chair should not request such an election if the next regularly scheduled election is fewer than three months away.
  • 将来の特定の日に辞任する場合も含め, 現在の委員が辞任の意向を示したらすぐに委員会の議長が選挙を求めてもよく, 選挙が始まってもよいです.
    The group Chair may request an election, and the election may begin, as soon as a current member gives notice of a resignation, including a resignation effective as of a given date in the future.

  そのような選挙が開催された場合, 対象となる席の最小の数は, 選任された席の合計の最小の数(TAGは6名, ABは9名)から継続する委員の数を引いた数です. 最大の数は, 全ての空いている席の数に一致します. 対象となる席の数と任期の長さを除いて, 諮問会議と技術諮問委員会の選挙の通常の規則が適用されます.

  When such an election is held, the minimum number of available seats is such that when added to the number of continuing participants, the minimum total number of elected seats is met (6 for the TAG, 9 for the AB); and the maximum number corresponds to all unoccupied seats. Except for the number of available seats and the length of the terms, the usual rules for Advisory Board and Technical Architecture Group Elections apply.

3.4. 憲章を持つ部会:作業部会と関連部会
Chartered Groups: Working Groups and Interest Groups

この文書は, 2種類の憲章を持つ部会を定義しています.

This document defines two types of chartered groups:

作業部会.

Working Groups.

作業部会は, 典型的に部会の憲章で定義された成果(例えば, 勧告工程にある技術報告書, ソフトウェア, テストツール, 他の部会の成果の審査)を生み出します.

Working Groups typically produce deliverables (e.g., Recommendation Track technical reports, software, test suites, and reviews of the deliverables of other groups) as defined in their charter.

作業部会は, W3C特許指針[特許指針]で述べられている追加の参加者の要件を持っており, 特に“作業部会の参加者のライセンス責務”や“W3C RFライセンス要件からの除外”の特許主張の除外手続きを参照して下さい.

Working Groups have additional participation requirements described in the W3C Patent Policy [PATENT-POLICY], see particularly the “Licensing Obligations of Working Group Participants” and the patent claim exclusion process in “Exclusion From W3C RF Licensing Requirements”.

関連部会.

Interest Groups.

関連部会の第一の目標は, 潜在的なウェブ技術や指針を計画しようとしている人々を呼び集めることです. 関連部会は, 意見交換のための公共の場です.

The primary goal of an Interest Group is to bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas.

関連部会は, 勧告工程にある技術報告書は発行しませんが, メモ工程にある技術報告書は発行できます.

Interest Groups do not publish Recommendation Track technical reports; but can publish technical reports on the Note Track.

3.4.1. 全ての憲章を持つ部会に対する要件
Requirements for All Chartered Groups

各部会は, 憲章を持たなければなりません. 憲章に対する要件は, 部会の種類に依存します. 全ての部会憲章は, (例え, 部会の他の進捗状況が会員限定であっても)公開でなければなりません.

Each group must have a charter. Requirements for the charter depend on the group type. All group charters must be public (even if other proceedings of the group are Member-only).

各部会は, 部会の仕事を調整する議長(または共同議長)を持たなければなりません. ディレクターは, 全ての部会の議長を指名(および再指名)します. 議長は, (ディレクターにより招待された), 会員の代表者, 事務局の代表者, 外部の専門家のどれかです. それらの形式の参加者に適用される, この文書に書かれた要件が, 議長にも同様に適用されます. 議長の役割 [議長]は, 合意の要領 [案内]で述べられています.

Each group must have a Chair (or co-Chairs) to coordinate the group’s tasks. The Director appoints (and re-appoints) Chairs for all groups. The Chair is a Member representative, a Team representative, or an Invited Expert, (invited by the Director). The requirements of this document that apply to those types of participants apply to Chairs as well. The role of the Chair [CHAIR] is described in the Art of Consensus [GUIDE].

各部会は, 議長, 部会の参加者, 事務局の間の連絡を担う事務局の連絡員を置かなければなりません. 事務局の連絡員の役割 [事務局の連絡員]は, 合意の要領 [案内]で述べられています. 議長と事務局の連絡員は同一人物でない方がよいです.

Each group must have a Team Contact, who acts as the interface between the Chair, group participants, and the rest of the Team. The role of the Team Contact [TEAM-CONTACT] is described in the Art of Consensus [GUIDE]. The Chair and the Team Contact of a group should not be the same individual.

各部会は, 公式な部会のやり取り(例えば, 会議の案内や議事録, 決定の文書化, 決定への正式な異議)を一覧に記録したメーリングリストを持たなければなりません. 新しい参加者の全ての関係するメーリングリストへの参加を確実にするのは, 議長と事務局の連絡員の責任です. 部会のメーリングリスト [部会メール]の一覧を参照して下さい.

Each group must have an archived mailing list for formal group communication (e.g., for meeting announcements and minutes, documentation of decisions, and Formal Objections to decisions). It is the responsibility of the Chair and Team Contact to ensure that new participants are subscribed to all relevant mailing lists. Refer to the list of group mailing lists [GROUP-MAIL].

議長は, 部会の割り当てた任務を遂行するために(部会の参加者で構成される)プロジェクトチームを形作ってもよいです. プロジェクトチームの任務の範囲は, 部会の憲章の範囲を超えてはなりません. 部会は, プロジェクトチームを作る過程を文書化すべきです(例えば, 各プロジェクトチームは略式の"憲章"を持ってもよいでしょう). プロジェクトチームは, 技術報告書を公表しません. 部会は, プロジェクトチームの成果を技術報告書の一部として採用してもよいです.

A Chair may form task forces (composed of group participants) to carry out assignments for the group. The scope of these assignments must not exceed the scope of the group’s charter. A group should document the process it uses to create task forces (e.g., each task force might have an informal "charter"). Task forces do not publish technical reports; the Working Group may choose to publish their results as part of a technical report.

3.4.2. 憲章を持つ部会への参加
Participation in Chartered Groups

3種類の作業部会の参加者がいます. 会員の代表者, 外部の専門家, (事務局の連絡員を含む)事務局の代表者 です.

There are three types of individual participants in a Working Group: Member representatives, Invited Experts, and Team representatives (including the Team Contact).

4種類の関連部会の参加者がいます. 作業部会と同じ3種類に加えて, 参加要件がメーリングリストに参加することのみである関連部会には, 一般の参加者がいます.

There are four types of individual participants in an Interest Group: the same three types as for Working Groups plus, for an Interest Group where the only participation requirement is mailing list subscription, public participants.

この文書または部会の憲章に注意書きがある場合を除いて, 全ての参加者は, 部会の中で同じ権利と責任を持っています. 個人の参加基準も参照して下さい.

Except where noted in this document or in a group charter, all participants share the same rights and responsibilities in a group; see also the individual participation criteria.

参加者は, 作業部会または関連部会の中の複数の組織を代表してもよいです. それらの組織は, 全て部会のメンバーでなければなりません.

A participant may represent more than one organization in a Working Group or Interest Group. Those organizations must all be members of the group.

個人は, 作業部会または関連部会の実在している間に, いつ部会の参加者になってもよいです. W3C特許指針[特許指針]の“既に設立されている作業部会に参加する”の関係する要件を参照して下さい.

An individual may become a Working or Interest Group participant at any time during the group’s existence. See also relevant requirements in “Joining an Already Established Working Group” in the W3C Patent Policy [PATENT-POLICY].

例外的な基準として, 作業部会や関連部会の参加者は, 会議に出席する代理人を指名してもよく, その場合, 議長に通知すべきです. 代理人は, 投票も含めて, 参加者の代理として行動してもよいです. 投票する代理人について, 参加者は, 前もって書面で議長に通知しなければなりません. 部会への礼儀として, 代理人が部会の議論をよく知らないのなら, 元の参加者は, 投票で代理として行動する権限を他の参加者に渡すべきです.

On an exceptional basis, a Working or Interest Group participant may designate a substitute to attend a meeting and should inform the Chair. The substitute may act on behalf of the participant, including for votes. For the substitute to vote, the participant must inform the Chair in writing in advance. As a courtesy to the group, if the substitute is not well-versed in the group’s discussions, the regular participant should authorize another participant to act as proxy for votes.

速やかに進展させるため, 作業部会は, 小さく(典型的に15名より少なく)なるように意図されており, 憲章で定義した分野の専門家で構成されます. 作業部会が効率的であるには大きく成長し過ぎた場合, W3Cは, 関連部会(議論の公共の場)とより小さい作業部会(強く専念する参加者の核と成る部会)に分割してもよいです.

To allow rapid progress, Working Groups are intended to be small (typically fewer than 15 people) and composed of experts in the area defined by the charter. In principle, Interest Groups have no limit on the number of participants. When a Working Group grows too large to be effective, W3C may split it into an Interest Group (a discussion forum) and a much smaller Working Group (a core group of highly dedicated participants).

3.4.3. 憲章を持つ部会の参加者の種類
Types of Participants in Chartered Groups

3.4.3.1. 作業部会における会員の代表者
Member Representative in a Working Group

全ての次の条件を満たす場合, その人物は, 作業部会における会員の代表者です.

An individual is a Member representative in a Working Group if all of the following conditions are satisfied:

• 当該会員の諮問委員会の委員が, 作業部会の参加者としてその人物を指名してきた場合.
  the Advisory Committee representative of the Member in question has designated the individual as a Working Group participant, and
• その人物が会員の代表者に適任である場合.
  the individual qualifies for Member representation.

作業部会における会員の代表者として個人を指名するために, 諮問委員会の委員は, 議長と事務局の連絡員に, 全ての次に示す情報を, (W3C特許指針[特許指針]の参加者の要件を含めて)参加の要請や憲章で必要とされている全ての他の情報を加えたうえで, 提供しなければなりません.

To designate an individual as a Member representative in a Working Group, an Advisory Committee representative must provide the Chair and Team Contact with all of the following information, in addition to any other information required by the Call for Participation and charter (including the participation requirements of the W3C Patent Policy [PATENT-POLICY]):

1. その人物が代表するW3C会員の名称と, その人物がその会員組織の従業員であるかどうか.
   The name of the W3C Member the individual represents and whether the individual is an employee of that Member organization;
2. その人物が, (憲章の日付とバージョンを表示して)憲章に明記された条件を受け入れるという声明書.
   A statement that the individual accepts the participation terms set forth in the charter (with an indication of charter date or version);
3. その会員が, 参加のために(例えば, 旅行, 通信, 会議のために)必要な財務上の支援を行うという声明書.
   A statement that the Member will provide the necessary financial support for participation (e.g., for travel, telephone calls, and conferences).

会員は, 最初の会員の参加者が作業部会に加わってから, 次のいずれかが起こるまで作業部会に参加します.

A Member participates in a Working Group from the moment the first Member representative joins the group until either of the following occurs:

• 部会が終了するまで.
  the group closes, or
• 会員が作業部会を辞めるまで. このことは, 会員の諮問委員会の委員を通して行われます.
  the Member resigns from the Working Group; this is done through the Member’s Advisory Committee representative.

3.4.3.2. 関連部会における会員の代表者
Member Representative in an Interest Group

参加要件が関連部会のメーリングリストの購読だけでない場合で, 次の全ての要件を満たす場合, その人物は関連部会における会員の代表者です.

When the participation requirements exceed Interest Group mailing list subscription, an individual is a Member representative in an Interest Group if all of the following conditions are satisfied:

• 当該会員の諮問委員会の委員が, 関連部会の参加者としてその人物を指名してきた場合.
  the Advisory Committee representative of the Member in question has designated the individual as an Interest Group participant, and
• その人物が会員の代表者に適任である場合.
  the individual qualifies for Member representation.

関連部会における会員の代表者として個人を指名するために, 諮問委員会の委員は, 参加の要請の指示に従わなければなりません.

To designate an individual as a Member representative in an Interest Group, the Advisory Committee representative must follow the instructions in the Call for Participation and charter.

関連部会への会員の参加は, 作業部会と同じ条件によって終了します.

Member participation in an Interest Group ceases under the same conditions as for a Working Group.

3.4.3.3. 作業部会における外部の専門家
Invited Expert in a Working Group

議長は, 作業部会に参加する特定の専門知識を持った人物を招待してもよいです. その人物は, (例えば, 他の組織との連絡係として行動しているといった具合に)部会の中で組織を代表してもよいです.

The Chair may invite an individual with a particular expertise to participate in a Working Group. This individual may represent an organization in the group (e.g., if acting as a liaison with another organization).

次の全ての要件を満たす場合, その人物は, 作業部会における外部の専門家です.

An individual is an Invited Expert in a Working Group if all of the following conditions are satisfied:

• 議長が, 部会の参加者として, その人物を指名している場合.
  the Chair has designated the individual as a group participant,
• 事務局の連絡員が, 議長の選抜に合意している場合.
  the Team Contact has agreed with the Chair’s choice, and
• その人物が, 外部の専門家として必要な情報を, 議長と事務局の連絡委員に提供している場合.
  the individual has provided the information required of an Invited Expert to the Chair and Team Contact.

誰かを作業部会における外部の専門家として指名するために, 議長は, 事務局の連絡員に通知し, 選んだ根拠を提供しなければなりません. 議長と事務局の連絡員が指名について合意しない場合, ディレクターは, その人物が作業部会に参加するために招待されるかどうか決定します.

To designate an individual as an Invited Expert in a Working Group, the Chair must inform the Team Contact and provide rationale for the choice. When the Chair and the Team Contact disagree about a designation, the Director determines whether the individual will be invited to participate in the Working Group.

作業部会に外部の専門家として参加するために, その人物は次のことをしなければなりません.

To participate in a Working Group as an Invited Expert, an individual must:

• もし, その人物が, その部会で参加者として組織を代表しているならば, その組織を特定しなければなりません.
  identify the organization, if any, the individual represents as a participant in this group,
• 外部の専門家・協力者規約 [協力者規約]の条件に合意しなければなりません.
  agree to the terms of the invited expert and collaborators agreement [COLLABORATORS-AGREEMENT],
• 憲章に明記されている参加条件を, W3C特許指針[特許指針]の参加の要件, 特に“外部の専門家に対するライセンス義務における注意”と“開示情報”を含めて, 特定の憲章の日付とバージョンを示して受け入れなければなりません.
  accept the participation terms set forth in the charter, including the participation requirements of the W3C Patent Policy [PATENT-POLICY], especially in “Note on Licensing Commitments for Invited Experts” and in “Disclosure”, indicating a specific charter date or version,
• その人物がW3C会員の従業員であるかどうか開示しなければなりません. 利益衝突の指針を参照して下さい.
  disclose whether the individual is an employee of a W3C Member; see the conflict of interest policy,
• その人物が参加のために(例えば, 旅行, 通信, 会議のために)誰が財務上の支援を行うのかを記した声明書を提供しなければなりません.
  provide a statement of who will provide the necessary financial support for the individual’s participation (e.g., for travel, telephone calls, and conferences), and
• その人物の雇用主(または自営業である場合のその人物自身), もしくはその人物が代表している組織がW3C会員でない場合, それらの組織がW3Cに参加するつもりであるかどうか示さなければなりません. それらの組織がW3Cに参加するつもりがない場合, その選択に対し, その人物が知っている理由を示さなければなりません.
  if the individual’s employer (including a self-employed individual) or the organization the individual represents is not a W3C Member, indicate whether that organization intends to join W3C. If the organization does not intend to join W3C, indicate reasons the individual is aware of for this choice.

議長は, 作業部会における外部の専門家として, W3C会員の従業員である人物を指名すべきではありません. 議長は, 憲章によって課された参加の条件を出し抜くために, 外部の専門家の立場を利用してはなりません.

The Chair should not designate as an Invited Expert in a Working Group an individual who is an employee of a W3C Member. The Chair must not use Invited Expert status to circumvent participation limits imposed by the charter.

外部の専門家は, その人物が作業部会に参加した瞬間から, 次のいずれかが起こるまで作業部会に参加します.

An Invited Expert participates in a Working Group from the moment the individual joins the group until any of the following occurs:

• 部会が終了するまで.
  the group closes, or
• 議長またはディレクターが参加の招待を取り消すまで.
  the Chair or Director withdraws the invitation to participate, or
• その人物が辞めるまで.
  the individual resigns.

3.4.3.4. 関連部会における外部の専門家
Invited Expert in an Interest Group

参加要件が関連部会のメーリングリストの購読だけでない場合, 関連部会における外部の専門家に対する参加要件は, 作業部会における外部の専門家の要件と同じになります.

When the participation requirements exceed Interest Group mailing list subscription, the participation requirements for an Invited Expert in an Interest Group are the same as those for an Invited Expert in a Working Group.

3.4.3.5. 作業部会における事務局の代表者
Team Representative in a Working Group

W3C運営から指名された場合, その人物は, 作業部会における事務局の代表者です. 事務局の代表者は, 技術的な作業に寄与するとともに, W3Cの他の部会と, 対象の部会との統合を確かなものにする手助けをします.

An individual is a Team representative in a Working Group when so designated by W3C management. Team representatives both contribute to the technical work and help ensure the group’s proper integration with the rest of W3C.

事務局の代表者は, その人物が作業部会に参加した瞬間から, 次のいずれかが起こるまで作業部会に参加します.

A Team representative participates in a Working Group from the moment the individual joins the group until any of the following occurs:

• 部会が終了するまで.
  the group closes, or
• W3Cの運営が, 議長にeメールを送り, そのコピーを部会のメーリングリストへも送ることによって, 事務局の代表者を変更するまで.
  W3C management changes Team representation by sending email to the Chair, copying the group mailing list.

事務局は, 作業部会の作成が通知されてから, 部会が終了するまで作業部会に参加します.

The Team participates in a Working Group from the moment the creation of the group is announced until the group closes.

3.4.3.6. 関連部会における事務局の代表者
Team Representative in an Interest Group

参加要件が関連部会のメーリングリストの購読だけでない場合で, W3Cの運営から指名された場合, その人物は, 関連部会における事務局の代表者です.

When the participation requirements exceed Interest Group mailing list subscription, an individual is a Team representative in an Interest Group when so designated by W3C management.

4. 憲章を持つ部会の開始から終了まで
Lifecycle of Chartered Groups

4.1. 憲章の開発の提案
Initiating Charter Development

W3Cは, 会員や事務局の関心に基づき, 憲章をもつ部会の憲章を作成します. 事務局は, 新しい作業部会または関連部会の憲章を開発し始めたとき, 諮問委員会に通知しなければなりません. このことは, 正式な提案が確認できるようになる前であっても配慮されるべきです. 諮問委員会の委員は, 諮問委員会の議論一覧に, または他の明示された経路で意見を返してもよいです.

W3C creates charters for chartered groups based on interest from the Members and Team. The Team must notify the Advisory Committee when a charter for a new Working Group or Interest Group is in development. This is intended to raise awareness, even if no formal proposal is yet available. Advisory Committee representatives may provide feedback on the Advisory Committee discussion list or via other designated channels.

W3Cは, いつでも作業部会または関連部会の憲章の作業に取り掛かってよいです.

W3C may begin work on a Working Group or Interest Group charter at any time.

4.2. 憲章の内容
Content of a Charter

作業部会または関連部会の憲章は, 次に示す情報を全て含まなければなりません.

A Working Group or Interest Group charter must include all of the following information.

• 部会の使命(例えば, 技術または手続きの開発, 他の部会の成果の審査).
  The group’s mission (e.g., develop a technology or process, review the work of other groups).
• 部会の仕事の範囲と成功の基準.
  The scope of the group’s work and criteria for success.
• 部会の活動期間(典型的に6ヵ月から2年までの間).
  The duration of the group (typically from six months to two years).
• 何らかの成果(技術報告書, 他の部会の成果の審査, ソフトウェア)の特質.
  The nature of any deliverables (technical reports, reviews of the deliverables of other groups, or software).
• 可能であれば, 期待される重要な段階の期日.
  Expected milestone dates where available.

  注意:憲章において, 他の部会の成果の審査の計画を含むことは必須ではありません.

  Note: A charter is not required to include schedules for review of other group’s deliverables.

• (中間の結果も含めた)成果の公開を承認する部会の手続き.
  The process for the group to approve the release of deliverables (including intermediate results).
• この部会の成果における, W3C内外の部会との依存関係. どの依存関係に対しても, 憲章は, 成果についてのやり取りの仕組みを指定しなければなりません.
  Any dependencies by groups within or outside of W3C on the deliverables of this group. For any dependencies, the charter must specify the mechanisms for communication about the deliverables.
• W3C内外の部会における, この部会の依存関係. この依存関係は, W3Cの対等の部会 [憲章]を含みます.
  Any dependencies of this group on other groups within or outside of W3C. Such dependencies include interactions with W3C Horizontal Groups [CHARTER].
• 部会の進捗状況と成果の機密レベル.
  The level of confidentiality of the group’s proceedings and deliverables.
• 会議の仕組みと予定されている頻度.
  Meeting mechanisms and expected frequency.
• 決まっていれば, 最初の対面での会議の日程. 提案された部会の最初の対面での会議の日程は, 提案の日から8週間後以降でなければなりません.
  If known, the date of the first face-to-face meeting. The date of the first face-to-face meeting of a proposed group must not be sooner than eight weeks after the date of the proposal.
• 部会に従事する際の, 部会とW3Cの残りの部会, 一般社会とのやり取りの仕組み.
  Communication mechanisms to be employed within the group, between the group and the rest of W3C, and with the general public.
• § 5.2.3 投票による決定で指定されている以外の, 何らかの投票の手続きまたは要件.
  Any voting procedures or requirements other than those specified in § 5.2.3 Deciding by Vote.
• 参加者に期待される従事期間の見込み.
  An estimate of the expected time commitment from participants.
• 事務局に期待される従事期間やその水準(例えば, 開発の経緯の記録, 技術報告書を書いたり編集すること, コードの開発, 試験手続きの体系化).
  The expected time commitment and level of involvement by the Team (e.g., to track developments, write and edit technical reports, develop code, or organize pilot experiments).
• 知的所有権の情報. 部会の成功に影響する(特許と著作権を含む)知的所有権の考慮すべきことは何か? 特に, W3C特許指針[特許指針]の“W3C仕様書のライセンスの目標”における, ロイヤリティフリーライセンスの目標を満たすことが困難となると考えられる, 何らかの理由があるか?
  Intellectual property information. What are the intellectual property (including patents and copyright) considerations affecting the success of the Group? In particular, is there any reason to believe that it will be difficult to meet the Royalty-Free licensing goals in “Licensing Goals for W3C Specifications” in the W3C Patent Policy [PATENT-POLICY]?

W3C特許指針[特許指針]の“W3C仕様書のライセンスの目標”における憲章の要件も参照して下さい.

See also the charter requirements in “Licensing Goals for W3C Specifications” in the W3C Patent Policy [PATENT-POLICY].

(同じ名前の前身となる部会を含む)何らかの他の憲章の下で公表された技術報告書の作業を継続する, 全ての勧告工程にある成果に対して, 少なくとも存在する初期草案に対して, 採用する作業部会の提案された憲章の中の説明は, 次に示す情報を提供しなければなりません.

For every Recommendation Track deliverable that continues work on technical report published under any other Charter (including a predecessor group of the same name), for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

• 表題, 不変のURL, 成果における作業の基礎になるであろう, (“採用された草案”に分類される)草案や他の勧告工程にある文書の公表された日付.
  The title, stable URL, and publication date of the Working Draft or other Recommendation-track document that will serve as the basis for work on the deliverable (labeled “Adopted Draft”);
• 表題, 不変のURL, W3C特許指針[特許指針]を通して, 最も直近の除外機会(注釈:W3C特許指針で特許所有者がRFライセンスから除外されることを表明できる機会)に基礎として使われていた(“除外された草案”に分類される)文書の公開された日付.
  The title, stable URL, and publication date of the document that was used as the basis for its most recent Exclusion Opportunity as per the W3C Patent Policy [PATENT-POLICY]. (labeled “Exclusion Draft”); and
• 除外された草案を公表した作業部会の(“除外された草案の憲章”に分類される)憲章の不変のURL.
  The stable URL of the Working Group charter under which the Exclusion Draft was published (labeled the “Exclusion Draft Charter”).

上記の全てのデータは, 示された分類を使用して, 採用する作業部会の憲章の中で特定されなければなりません.

All of the above data must be identified in the adopting Working Group’s charter using the labels indicated.

採用された草案や除外された草案は, それぞれ全体が何らかの修正無しに採用されなければなりません. 提案された憲章は, 開始され終了された除外された草案を公表する中で生じた, どの除外機会のものか日付をはっきりと述べなければなりません. W3C特許指針[特許指針]の“既に設立されている作業部会に参加する”を通じて, このことは, 作業部会に参加する中で除外が直接行われるのみであることを, 潜在的に意味しています.

The Adopted Draft and the Exclusion Draft must each be adopted in their entirety and without any modification. The proposed charter must state the dates on which the Exclusion Opportunity that arose on publishing the Exclusion Draft began and ended. As per “Joining an Already Established Working Group” in the W3C Patent Policy [PATENT-POLICY], this potentially means that exclusions can only be made immediately on joining a Working Group.

関連部会の憲章は, 関連部会への参加要件が, (誰でも)関連部会のメーリングリストの購読のみであることを指定することを含め, 参加に関する規定を含んでもよいです. この種類の関連部会は, 一般の参加者を受け入れてもよいです.

An Interest Group charter may include provisions regarding participation, including specifying that the only requirement for participation (by anyone) in the Interest Group is subscription to the Interest Group mailing list. This type of Interest Group may have public participants.

憲章は, この文書で必要とされる規定以外の規定を含んでもよいです. 憲章は, どの追加の規定がW3C手続き文書の規定を超えた制限(例えば, 作業部会内の同じ会員組織や関連会員のグループを代表する参加者の人数の制限)を課しているか強調して示すべきです.

A charter may include provisions other than those required by this document. The charter should highlight whether additional provisions impose constraints beyond those of the W3C Process Document (e.g., limits on the number of individuals in a Working Group who represent the same Member organization or group of related Members).

4.3. 憲章の諮問委員会による審査
Advisory Committee Review of a Charter

ディレクターは, 新しいまたは本質的に修正された, 作業部会または関連部会の憲章ごとに, 次のいずれかの場合を除いて諮問委員会による審査を依頼しなければなりません.

The Director must solicit Advisory Committee review of every new or substantively modified Working Group or Interest Group charter, except for either:

• 憲章の延長.

  a charter extension

• 重大な点で部会が役割を果たす方法に影響を与えない憲章の本質的な変更.

  substantive changes to a charter that do not affect the way the group functions in any significant way.

審査の期間は, 少なくとも28日間取らなければなりません. 次に示す内容は, 諮問委員会による審査を必要としないであろう本質的な変更の例です. 例えば, 範囲内の成果の追加, 事務局の連絡員の変更, 議長の変更です. ただし, このような変更は, 諮問委員会および作業部会の参加者または関連部会の参加者に通知されなければならず, 根拠が提供されなければなりません.

The review period must be at least 28 days. The following are examples of substantive changes that would not require an Advisory Committee Review: the addition of an in-scope deliverable, a change of Team Contact, or a change of Chair. Such changes must nonetheless be announced to the Advisory Committee and to participants in the Working or in the Interest Group, and a rationale must be provided.

本質的に修正された憲章の審査の要請は, 重要な変更(例えば, 関連する成果または資源の割り当て)を強調して示さなければならず, 変更の根拠を含まなければなりません.

The Call for Review of a substantively modified charter must highlight important changes (e.g., regarding deliverables or resource allocation) and include rationale for the changes.

何らかの新しいまたは本質的に修正された作業部会の憲章の諮問委員会による審査の一環として, どの諮問委員会の委員も, 審査期間の延長を要求してもよいです.

As part of the Advisory Committee review of any new or substantively modified Working Group charter, any Advisory Committee representative may request an extended review period.

そのような要求は, 審査の要請に対する会員の回答意見と一緒に提出されなければなりません. 何らかのそのような要求を受領した上で, ディレクターは, 作業部会の参加の要請が, 憲章の審査の要請から少なくとも60日後に行われることを確実にしなければなりません.

Such a request must be submitted with a Member’s comments in response to the Call for Review. Upon receipt of any such request, the Director must ensure that the Call for Participation for the Working Group occurs at least 60 days after the Call for Review of the charter.

4.4. 憲章を持つ部会における参加の要請
Call for Participation in a Chartered Group

作業部会または関連部会の憲章に対する諮問委員会による審査の後, ディレクターは, 諮問委員会に参加の要請を行ってもよいです. 参加の要請の前に, 憲章は, 審査意見によって修正されてもよいです.

After Advisory Committee review of a Working Group or Interest Group charter, the Director may issue a Call for Participation to the Advisory Committee. Charters may be amended based on review comments before the Call for Participation.

新しい部会に対して, この要請の発表は, 公式に部会を作ります. その発表は, 憲章への参照, 部会の議長(ら)の名前, 事務局の連絡員(ら)の名前を含まなければなりません.

For a new group, this announcement officially creates the group. The announcement must include a reference to the charter, the name(s) of the group’s Chair(s), and the name(s) of the Team Contact(s).

参加の要請後, どの会員の代表者や外部の専門家も, 指名(もしくは再指名)されなければなりません. 部会が再度憲章を作った場合, 新しい参加の要請の前からの作業部会または関連部会に参加している個人は, 正式に部会に参加する(すなわち, 憲章や特許指針の条件を約束する)前であったとしても, 参加の要請から45日以内に開催される何らかの会議に出席してもよいです.

After a Call for Participation, any Member representatives and Invited Experts must be designated (or re-designated). When a group is re-chartered, individuals participating in the Working Group or Interest Group before the new Call for Participation may attend any meetings held within forty-five (45) days of the Call for Participation even if they have not yet formally rejoined the group (i.e., committed to the terms of the charter and patent policy).

諮問委員会の委員は, 作業部会または関連部会の憲章を, 作成もしくは実質的に修正する決定に対して, 諮問委員会の抗議を提出してもよいです.

Advisory Committee representatives may initiate an Advisory Committee Appeal against the decision to create or substantially modify a Working Group or Interest Group charter.

4.5. 憲章の延長
Charter Extension

何も他の実質的な修正無しに, 作業部会または関連部会の憲章を延長するために, ディレクターは, 諮問委員会に延長を通知します. また, その通知は, 新しい期間を示さなければなりません. その通知は, 延長の根拠, 憲章への参照, 部会の議長(ら)の名前, 事務局の連絡員(ら)の名前, 部会に参加する場合の説明も含まなければなりません.

To extend a Working Group or Interest Group charter with no other substantive modifications, the Director announces the extension to the Advisory Committee. The announcement must indicate the new duration. The announcement must also include rationale for the extension, a reference to the charter, the name(s) of the group’s Chair(s), the name of the Team Contact, and instructions for joining the group.

憲章の延長後, 諮問委員会の委員と議長にとって, 会員の代表者と外部の専門家を再指名することは必須ではありません.

After a charter extension, Advisory Committee representatives and the Chair are not required to re-designate Member representatives and Invited Experts.

諮問委員会の委員は, 作業部会または関連部会の憲章の延長に関するディレクターの決定に対して, 諮問委員会の抗議を提出してもよいです.

Advisory Committee representatives may initiate an Advisory Committee Appeal against a Director’s decision regarding the extension of a Working Group or Interest Group charter.

4.6. 憲章を持つ部会の終了
Chartered Group Closure

作業部会または関連部会の憲章は, 部会の期間を指定します. ディレクターは, 次のいずれかの状況において, 憲章で指定された期日以外を優先して, 部会を終了することを決めてもよいです.

A Working Group or Interest Group charter specifies a duration for the group. The Director may decide to close a group prior to the date specified in the charter in any of the following circumstances:

• W3Cの中で認められた優先順位によって, 憲章に書かれた成果を生み出したり, 部会を管理したりするのに不十分な資源しか無い場合.
  There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C.
• 部会が憲章に書かれた成果を, 予定よりも早く生み出した場合.
  The group produces chartered deliverables ahead of schedule.

ディレクターは, 諮問委員会への通知によって, 作業部会または関連部会を終了します. 諮問委員会の委員は, 諮問委員会の抗議を提出してもよいです.

The Director closes a Working Group or Interest Group by announcement to the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal.

作業部会を終了することは, W3C特許指針[特許指針]に関する影響があります.

Closing a Working Group has implications with respect to the W3C Patent Policy [PATENT-POLICY].

5. 決定
Decisions

W3Cは, 話し合いを通じて課題を解決しようと試みています. 決定に強く反対している個人は, 議長に対して何らかの正式な異議を示すべきです.

W3C attempts to resolve issues through dialog. Individuals who disagree strongly with a decision should register with the Chair any Formal Objections.

5.1. 決定の種類
Types of Decisions

作業部会または関連部会の議長は, 自らの判断に基づいて特定の決定を行う特権を持っています. このような決定は, 議長決定と呼ばれます.

The Chair of a Working Group or Interest Group has the prerogative to make certain decisions based on their own judgment. Such decisions are called chair decisions.

対称的に, 部会の合意を評価すること, または投票(§ 5.2.3 投票による決定参照)に従うことに基づいて, 作業部会または関連部会の議長によって行われる決定は, (部会の“決議”としても知られる)部会決定と呼ばれます.

In contrast, decisions taken by the Chair of a Working Group or Interest Group on the basis of having assessed the consensus of the group or following a vote (see § 5.2.3 Deciding by Vote) are called group decisions (also known as group “resolutions”).

W3C決定は, ディレクターにより, 諮問委員会の審査の後にW3C界隈の合意を評価する役割を行使したうえで決定されるものです.

A W3C decision is one where the Director decides, after exercising the role of assessing consensus of the W3C Community after an Advisory Committee review.

5.2. 合意形成
Consensus Building

5.2.1. 合意
Consensus

合意は, W3Cの核となる価値です. 合意を促進するために, W3C手続き文書は, 部会が全ての見解や異議, また, それらを解決する試みを確実に熟慮するよう, 議長に求めています. それらの見解や異議が部会の活動的な参加者から述べられていようが, 他の所(例えば, 他のW3C部会, 他の組織の部会, 一般の社会全体)から述べられていようが, どちらであってもです. 決定は, (対面または分散型の)会議を通して, もしくは, 継続的な文書での議論を通して行われてもよいです.

Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Decisions may be made during meetings (face-to-face or distributed) as well as through persistent text-based discussions.

注意: ディレクター, CEO, COO(訳注:最高業務執行責任者)は, 諮問委員会の中の合意を判断する役割があります.

Note: The Director, CEO, and COO have the role of assessing consensus within the Advisory Committee.

次の用語は, この文書の中で, 適切な人々の集まりの中の, 決定に対する支持の水準を説明しています.

The following terms are used in this document to describe the level of support for a decision among a set of eligible individuals:

合意:
Consensus:

集まりの中の人々の相当な数が決定を支持し, その集まりの中の誰も正式な異議を示していないこと. その集まりの中の人々は, 棄権してもよいです. 棄権は, 意見が無いことを表明するか, 沈黙するかです.

A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set.

全員の合意:
Unanimity:

集まりの中の全ての人々が決定を支持する(すなわち, その集まりの誰も棄権しない)合意の特別な状況.

The particular case of consensus where all individuals in the set support the decision (i.e., no individual in the set abstains).

不同意:
Dissent:

集まりの中の少なくとも1人が正式な異議を示している場合.

At least one individual in the set registers a Formal Objection.

通常, 決定において参加するのに適切な人々の集まりは, 部会の参加者の集まりです. 手続き文書は, 決定のための定数(すなわち, 議長が質問を投げ掛ける前に出席する必要がある適切な人々の最小の数)を必須としていません. 憲章は, 合意の決定に定数の要件を含んでもよいです.

By default, the set of individuals eligible to participate in a decision is the set of group participants. The Process Document does not require a quorum for decisions (i.e., the minimal number of eligible participants required to be present before the Chair can call a question). A charter may include a quorum requirement for consensus decisions.

全員の合意は可能性が非常に低いので, 部会は, 相当数の支持や少数の棄権であれば, 決定の合意を形成するように努力すべきです. 手続き文書は, 決定を行うための動きに同意する, 参加者の割合を特段必要としていません. 広い範囲に及ぶ無関心(すなわち, わずかな支持とたくさんの棄権)がある場合の決定を避けるため, 部会は, 決定を記録しようとする前に, 効力のある支持の最小の閾値を決定すべきです. 適切な割合は, 部会の大きさや決定の性質によって変わってもよいです. 憲章は, 決定の合意の閾値の要件を含んでもよいです. 例えば, 適切な参加者の過半数(すなわち, 50%以上の何らかの値)を必要とするかもしれません.

Where unanimity is not possible, a group should strive to make consensus decisions where there is significant support and few abstentions. The Process Document does not require a particular percentage of eligible participants to agree to a motion in order for a decision to be made. To avoid decisions where there is widespread apathy, (i.e., little support and many abstentions), groups should set minimum thresholds of active support before a decision can be recorded. The appropriate percentage may vary depending on the size of the group and the nature of the decision. A charter may include threshold requirements for consensus decisions. For instance, a charter might require a supermajority of eligible participants (i.e., some established percentage above 50%) to support certain types of consensus decisions.

5.2.2. 不同意の管理
Managing Dissent

場合によっては, 憲章の全ての観点の注意深い考察の後でさえ, 部会は, 部会自身で合意に至ることができないかもしれません. 議長は, 不同意だった(すなわち, 少なくとも1つの正式な異議があった)決定と記録してもよく, そのため, 部会は(例えば, 適切な時期に成果を生み出すといった)進展を行うことができます. 反対者は, 単に決定を受け入れられないというだけでは, 部会の作業を止めることができません. 議長が, 部会は反対者の正当な関心事に可能な限り責任において適切に熟慮したと考えるならば, 部会は進むべきです.

In some cases, even after careful consideration of all points of view, a group might find itself unable to reach consensus. The Chair may record a decision where there is dissent (i.e., there is at least one Formal Objection) so that the group can make progress (for example, to produce a deliverable in a timely manner). Dissenters cannot stop a group’s work simply by saying that they cannot live with a decision. When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group should move on.

部会は, 弱い異議しか生じない提案を支持すべきです. このような提案は, 大半から支持されるが, 若干の人から強い異議がある提案より望ましいです. 不同意がある決定を行う部分において, 議長は, 不同意の参加者が同じ会員組織(または関連会員組織)で働いているかを意識し, 状況に応じて参加者の貢献度に重きを置くことが期待されます.

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people. As part of making a decision where there is dissent, the Chair is expected to be aware of which participants work for the same (or related) Member organizations and weigh their input accordingly.

5.2.3. 投票による決定
Deciding by Vote

技術的な議論を通して合意に至る全ての可能な手段と妥協が上手くいかず, 膠着状態を打破するには投票が必要であると, 議長が決めた後にのみ, 部会は, 実質的な課題を解決するために, 投票を行うべきです. この場合, 議長は, (例えば, 会議の議事録または記録されたeメールの文面の中に)次のことを記録しなければなりません.

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock. In this case the Chair must record (e.g., in the minutes of the meeting or in an archived email message):

• 投票されることとなった課題の説明.
  an explanation of the issue being voted on;
• 課題を解決するための投票(例えば, 単純な多数決)を行う決定.
  the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue;
• 投票の結果.
  the outcome of the vote;
• 正式な異議.
  any Formal Objections.

実質的な課題を解決する目的で投票するためには, 投票者は部会の参加者でなければなりません. 各組織が部会の中で(外部の専門家も含め)複数の参加者を代表している場合でさえ, その代表する組織は多くて1票しか持ってはなりません. 投票の目的のために次のように扱われます.

In order to vote to resolve a substantive issue, an individual must be a group participant. Each organization represented in the group must have at most one vote, even when the organization is represented by several participants in the group (including Invited Experts). For the purposes of voting:

• 会員または関連会員のグループは, 単独の組織と見なされます.
  A Member or group of related Members is considered a single organization.
• 事務局は, 組織と見なされます.
  The Team is considered an organization.

他に憲章で決まっていない限り, 外部の専門家は投票してもよいです.

Unless the charter states otherwise, Invited Experts may vote.

参加者が投票に参加できない場合, その参加者は, 誰かに会議で代理として行動する権限を与えてもよいです. 欠席する参加者は, 代理を利用する指示書と一緒に, 誰が代理として行動するのか議長に書面で知らせなければなりません. 作業部会または関連部会に対する, 参加者の代理人として会議に参加する個人についての関係する必要事項を参照して下さい.

If a participant is unable to attend a vote, that individual may authorize anyone at the meeting to act as a proxy. The absent participant must inform the Chair in writing who is acting as proxy, with written instructions on the use of the proxy. For a Working Group or Interest Group, see the related requirements regarding an individual who attends a meeting as a substitute for a participant.

部会は, 実質的な課題を解決する以外の, 他の目的で投票を行ってもよいです. 例えば, 議長は, 可能性のある決定について, 合意があるかどうかを決定する手段として“世論調査”の投票をよく行います.

A group may vote for other purposes than to resolve a substantive issue. For instance, the Chair often conducts a “straw poll” vote as a means of determining whether there is consensus about a potential decision.

部会は, 手続きを決定するにも投票を行ってもよいです. 例えば, 会議を(地理的にほとんど変わらない)サンフランシスコまたはサンノゼのどちらで開催するか, 単純な多数決で決めることは適当です. 重要でない課題を決定するのに単純な多数決を用いる場合, 投票者にとって投票する理由を表明することは必須ではなく, 部会にとって個人の投票を記録することは必須ではありません.

A group may also vote to make a process decision. For example, it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose (there’s not much difference geographically). When simple majority votes are used to decide minor issues, voters are not required to state the reasons for votes, and the group is not required to record individual votes.

部会の憲章は, 実質的な課題についての決定を行うのに, (例えば, 必要な定数または閾値といった)正式な投票の手続きを含んでもよいです.

A group charter may include formal voting procedures (e.g., quorum or threshold requirements) for making decisions about substantive issues.

5.3. 課題への正式な取組み
Formally Addressing an Issue

この文書の文脈で, ある課題が公開され, その課題を挙げた審査者に実質的に返答したとき, 部会はその課題を正式に取り組んだことになります. 実質的な返答は, 決定に対する論理的根拠(例えば, 技術的説明, 憲章の該当範囲を指し示すこと,文書の必要な部分を指し示すこと)を含んでいるべきです. 返答の適切さは, W3Cの審査者が一般的に技術的に何を感じるのかを考えることで測られます. 部会が審査者の意見が誤解に基づいていると考えるならば, 部会は, 決定に至る前に説明を求めるべきです.

In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C reviewer would generally consider to be technically sound. If a group believes that a reviewer’s comments result from a misunderstanding, the group should seek clarification before reaching a decision.

礼儀として, 議長と審査者は, 返答と承認の日程の見込みを設定すべきです. 部会は, 審査者の最初の意見に適時返答すべきです. 部会は, 部会の実質的な返答を審査者が承認する期限を設定すべきです. 審査者は, 部会の工程を止めることはできません. 審査者にとって, 実質的な返答を承認したり, それに意見したりするのに1週間以上必要なのが一般的です. 部会の審査者に返答する責務は, 無理の無い時間が経過すると終わる訳ではありません. しかしながら, 審査者は, 自分達の意見が適時部会に送られていないとき, より軽く扱われるであろうことを理解すべきです.

As a courtesy, both Chairs and reviewers should set expectations for the schedule of responses and acknowledgments. The group should reply to a reviewer’s initial comments in a timely manner. The group should set a time limit for acknowledgment by a reviewer of the group’s substantive response; a reviewer cannot block a group’s progress. It is common for a reviewer to require a week or more to acknowledge and comment on a substantive response. The group’s responsibility to respond to reviewers does not end once a reasonable amount of time has elapsed. However, reviewers should realize that their comments will carry less weight if not sent to the group in a timely manner.

実質的な返答は, 記録されるべきです. 部会は, 部会に寄せられた全ての実質的な課題と返答の正確な要約を, (例えば, メーリングリストの記録へのリンクを持った課題の書式の一覧の中で)管理すべきです.

Substantive responses should be recorded. The group should maintain an accurate summary of all substantive issues and responses to them (e.g., in the form of an issues list with links to mailing list archives).

5.4. 新しい情報が提供された場合の決定の再考
Reopening a Decision When Presented With New Information

議長は, 次のものを含む新しい情報が提供されたときに, 決定を再考してもよいです.

The Chair may reopen a decision when presented with new information, including:

• 追加の技術的情報.
  additional technical information,
• 予定されていた会議に出席できなかった参加者からのeメールによる意見.
  comments by email from participants who were unable to attend a scheduled meeting,
• 会議中, 話さないことを選んだ出席者からのeメールによる意見(そのため, 例えば, 後で同僚と協議したり, 文化的な理由が原因で協議したりできます).
  comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).

議長は, 決定が再考されることになったことを記録すべきで, 部会の参加者から要求があった場合は記録しなければなりません.

The Chair should record that a decision has been reopened, and must do so upon request from a group participant.

5.5. 議長決定と部会決定への抗議
Chair Decision and Group Decision Appeals

部会の参加者が, それらの事案は, 部会または議長によって十分に熟慮されたものでないと考える場合には, その参加者は, ディレクターに(諮問委員会の委員を通じて会員組織の代表者が)その決定を承認するか否認するか要求してもよいです. このことは, 部会決定への抗議または議長決定への抗議と呼ばれます. 参加者は, 事務局の連絡員に自分達の要請のことを知らせることもすべきです. 事務局への連絡は, 部会の参加者が正当な手続きに関係する事案を挙げた場合, ディレクターに知らせなければなりません.

When group participants believe that their concerns are not being duly considered by the group or the Chair, they may ask the Director (for representatives of a Member organization, via their Advisory Committee representative) to confirm or deny the decision. This is a Group Decision Appeal or a Chair Decision Appeal. The participants should also make their requests known to the Team Contact. The Team Contact must inform the Director when a group participant has raised concerns about due process.

決定について協議するディレクターへの要請は, (技術的または手続き上のいずれかの)課題の要約, 決定, 異議の論理的根拠を含んでいなければなりません. 論理的根拠, 決定は記録されなければなりません.

Any requests to the Director to confirm a decision must include a summary of the issue (whether technical or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions must be recorded.

諮問委員会の抗議についての手続きは, 別途説明します.

Procedures for Advisory Committee appeals are described separately.

5.6. 正式な異議の記録と報告
Recording and Reporting Formal Objections

W3Cの手続きにおいて, 個人は, 決定に正式な異議を表明してもよいです. 部会決定への正式な異議は, ディレクターが関連する決定を評価する一部として(例えば, 技術報告書を進展させる要請の返答の中で)熟慮するよう, 審査者が要請するものです.

In the W3C process, an individual may register a Formal Objection to a decision. A Formal Objection to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g., in response to a request to advance a technical report).

注意: この文書で, “正式な異議”という用語は, この手続きの影響を強調するのに使われています. 正式な異議は, ディレクターの考察を受け取ります. 単独で使われる“異議”という言葉は, 通常の言語の意味を持ちます.

Note: In this document, the term “Formal Objection” is used to emphasize this process implication: Formal Objections receive Director consideration. The word “objection” used alone has ordinary English connotations.

正式な異議を表明した個人は, 技術的な論点を引き合いに出し, 正式な異議を取り除く変更を提案すべきです. それらの提案は, はっきりせず不十分なものでもよいです. 実質的な論点や理論的根拠を提供しない正式な異議は, 真剣な考察を受け取れそうにないでしょう.

An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection; these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments or rationale are unlikely to receive serious consideration.

それぞれの正式な異議の記録は, 誰でも利用できなければなりません. 諮問委員会への(文書の)審査の要請は, どんな正式な異議があるか明確にしなければなりません.

A record of each Formal Objection must be publicly available. A Call for Review (of a document) to the Advisory Committee must identify any Formal Objections.

5.7. 諮問委員会の審査
Advisory Committee Reviews

諮問委員会の審査は, 諮問委員会が憲章, 技術報告書, 他の事柄の承認を正式に協議する手続きです.

Advisory Committee review is the process by which the Advisory Committee formally confers its approval on charters, technical reports, and other matters.

5.7.1. 審査期間の開始
Start of a Review Period

それぞれの諮問委員会の審査の期間は, 事務局から諮問委員会への審査の要請によって始まります. 審査の要請は, 提案について説明し, 締切に注意を引き, 決定が利用できるようになる時期を推定し, 他の実用的な情報を含みます. 各会員組織は, 1つの審査意見を送ってよく, その意見は, 諮問委員会の委員によって返されなければなりません.

Each Advisory Committee review period begins with a Call for Review from the Team to the Advisory Committee. The Call for Review describes the proposal, raises attention to deadlines, estimates when the decision will be available, and includes other practical information. Each Member organization may send one review, which must be returned by its Advisory Committee representative.

事務局は, 諮問委員会の審査意見のために2つの経路を提供しなければなりません.

The Team must provide two channels for Advisory Committee review comments:

1. 記録された事務局限定の経路
   an archived Team-only channel;
2. 記録された会員限定の経路
   an archived Member-only channel.

審査の要請は, どちらの経路がその要請における審査意見の通常の経路であるかを指定しなければなりません.

The Call for Review must specify which channel is the default for review comments on that Call.

審査者は, 情報をどちらかの, または両方の経路に送ってもよいです. 審査者は, 自分の審査意見を, 諮問委員会の議論一覧で他の会員と共有してもよいですし, また, その意見を公開して利用できるようにしてもよいです.

Reviewers may send information to either or both channels. A reviewer may also share their own reviews with other Members on the Advisory Committee discussion list, and may also make it available to the public.

会員組織は, 審査期間中に(例えば, 他の会員からの意見を受けて)審査意見を修正してもよいです.

A Member organization may modify its review during a review period (e.g., in light of comments from other Members).

5.7.2. 審査期間の終了後
After the Review Period

審査期間の終了後, ディレクターは, 諮問委員会に提案の支持の水準(合意または不同意)を周知しなければなりません. ディレクターは, 何らかの正式な異議があったかどうかも, 機密レベルの変更に注意して示さなければなりません. このW3C決定は, 一般に次のうちの1つです.

After the review period, the Director must announce to the Advisory Committee the level of support for the proposal (consensus or dissent). The Director must also indicate whether there were any Formal Objections, with attention to changing confidentiality level. This W3C decision is generally one of the following:

1. 場合によってはまとめられた編集上の変更と一緒に, 提案は承認されます.
   The proposal is approved, possibly with editorial changes integrated.
2. 場合によってはまとめられた実質的な変更と一緒に, 提案は承認されます. この場合, その周知は, 実質的な変更の提案があったとしても, 文書を進展する決定の根拠を含まなければなりません.
   The proposal is approved, possibly with substantive changes integrated. In this case the announcement must include rationale for the decision to advance the document despite the proposal for a substantive change.
3. 明確な課題を正式に取り組むための発案者への要求と一緒に, 提案は追加の作業のために差し戻されます.
   The proposal is returned for additional work, with a request to the initiator to formally address certain issues.
4. 提案は却下されます.
   The proposal is rejected.

この文書は, 諮問委員会の審査期間の終了からW3C決定までの時間間隔を指定していません. このことは, 審査の間に集められた意見を熟慮する十分な時間を, 会員や事務局が持つことを確かなものにするためです. 諮問委員会は, 審査期間の終了後2週間より早く周知を期待すべきではなく, もし3週間経っても, 結果が周知されない場合, ディレクターは, 最新情報を諮問委員会に提供すべきです.

This document does not specify time intervals between the end of an Advisory Committee review period and the W3C decision. This is to ensure that the Members and Team have sufficient time to consider comments gathered during the review. The Advisory Committee should not expect an announcement sooner than two weeks after the end of a review period. If, after three weeks, the outcome has not been announced, the Director should provide the Advisory Committee with an update.

5.8. 諮問委員会の投票
Advisory Committee Votes

諮問委員会は, TAGまたは諮問会議の席の選挙や, 抗議の投票のきっかけとなるのに必要な支持を達成した諮問委員会の抗議の中で, 投票します. 諮問委員会が投票するときはいつでも, 各会員または関連会員のグループは, 1票を持ちます.

The Advisory Committee votes in elections for seats on the TAG or Advisory Board, and in the event of an Advisory Committee Appeal achieving the required support to trigger an appeal vote. Whenever the Advisory Committee votes, each Member or group of related Members has one vote.

5.9. 諮問委員会の委員による抗議
Appeal by Advisory Committee Representatives

諮問委員会の委員は, 特定の決定に対し, 特別な状況でのみ起こっているとしても抗議してよいです.

Advisory Committee representatives may appeal certain decisions, though appeals are only expected to occur in extraordinary circumstances.

W3C決定が諮問委員会の審査に従って行われたとき, 諮問委員会の委員は, 諮問委員会の抗議を提出してもよいです. それらのW3C決定は, 部会の作成や修正に関係する決定, また, 勧告工程にある文書や手続き文書の新しい成熟レベルへの遷移を含みます.

When a W3C decision is made following an Advisory Committee review, Advisory Committee representatives may initiate an Advisory Committee Appeal. These W3C decisions include those related to group creation and modification, and transitions to new maturity levels for Recommendation Track documents and the Process document.

諮問委員会の委員は, 諮問委員会の審査を反映していない特定のディレクター決定に対しても, 抗議を提出してよいです. それらの状況は, ディレクター決定の要件について説明する節の中で特定され, 追加の(審査されていない)勧告工程の文書の成熟レベル, 部会の憲章の延長と終了, 覚書を含みます.

Advisory Committee representatives may also initiate an appeal for certain Director's decisions that do not involve an Advisory Committee review. These cases are identified in the sections which describe the requirements for the Director's decision and include additional (non-reviewed) maturity levels of Recommendation Track documents, group charter extensions and closures, and Memoranda of Understanding.

全ての場合に, 抗議は, 決定から3週間以内に提出されなければなりません.

In all cases, an appeal must be initiated within three weeks of the decision.

諮問委員会の委員は, 事務局に要求を送ることで抗議を提出します. 要求は, “ディレクター決定に抗議する”と言い, 決定を特定すべきです. 1週間以内に, 事務局は, 諮問委員会に抗議の流れを周知し, その抗議に対する賛成の支持の声明を回答する仕組みを, 諮問委員会の委員に提供しなければなりません. それらの声明の記録は, 会員限定でなければなりません. もし, 事務局の周知から1週間以内に, 諮問委員会の5%以上が抗議の要求を支持したならば, 事務局は, ディレクター決定と抗議の支持へのリンクを一緒に付けて, “ディレクター決定を承認するか?”を諮問委員会に問う投票を開催しなければなりません.

An Advisory Committee representative initiates an appeal by sending a request to the Team. The request should say “I appeal this Director’s Decision” and identify the decision. Within one week the Team must announce the appeal process to the Advisory Committee and provide a mechanism for Advisory Committee representatives to respond with a statement of positive support for this appeal. The archive of these statements must be member-only. If, within one week of the Team’s announcement, 5% or more of the Advisory Committee support the appeal request, the Team must organize an appeal vote asking the Advisory Committee “Do you approve of the Director’s Decision?” together with links to the Director's decision and the appeal support.

投票は, 意見と一緒に3つの選択可能な回答“承認”, “却下”,“棄権”を認めなければなりません.

The ballot must allow for three possible responses: “Approve”, “Reject”, and “Abstain”, together with Comments.

却下の票の数が, 承認の票の数を超えたならば, 決定はくつがえされます. その場合, 可能性のある次の段階は次のとおりです.

If the number of votes to reject exceeds the number of votes to approve, the decision is overturned. In that case, there are the following possible next steps:

1. 提案が却下されます.
   The proposal is rejected.
2. 適用できる決定の手続きを再提案した後, 提案が追加の作業のために差し戻されます.
   The proposal is returned for additional work, after which the applicable decision process is re-initiated.

6. W3C技術報告書
W3C Technical Reports

W3C技術報告書開発手続きは, ウェブ技術を標準化するために, 作業部会が従う工程と要件をまとめたものです. W3C技術報告書開発手続きは, 次のように設計されています.

The W3C technical report development process is the set of steps and requirements followed by W3C Working Groups to standardize Web technology. The W3C technical report development process is designed to:

• 多様な仕様書開発の方法論に対応する.
  support multiple specification development methodologies
• 安定した技術報告書の内容に対する合意を最大化する.
  maximize consensus about the content of stable technical reports
• 高い技術および編集上の質を確かなものにする.
  ensure high technical and editorial quality
• 仕様書間の一貫性を促進する.
  promote consistency among specifications
• ロイヤリティフリーで相互運用性のある, ウェブ標準の実装を手助けする.
  facilitate royalty-free, interoperable implementations of Web Standards, and
• W3Cや広く社会から支持を得る.
  earn endorsement by W3C and the broader community.

W3C特許指針[特許指針]の“W3C仕様書のライセンスの目標”も参照して下さい.

See also “licensing goals for W3C Specifications” in the W3C Patent Policy [PATENT-POLICY].

6.1. 技術報告書の種類
Types of Technical Reports

この章は, W3C勧告, メモ, データ一覧の発行や維持管理に対する正式な要件について説明しています.

This chapter describes the formal requirements for publishing and maintaining a W3C Recommendation, Note, or Registry Report.

勧告
Recommendations

作業部会は, ウェブの標準として標準仕様書または手引きを生み出すために, W3C勧告工程における技術報告書を開発します. 勧告工程の手続きは, 広範囲にわたる審査, 十分な実装の実績, 合意形成のための要件を含んでおり, 実装に対してロイヤリティフリーIPRライセンスを参加者が約束するために, W3C特許指針[特許指針]を条件としてます. 詳細については, § 6.3 W3C勧告工程を参照して下さい.

Working Groups develop technical reports on the W3C Recommendation Track in order to produce normative specifications or guidelines as standards for the Web. The Recommendation Track process incorporates requirements for wide review, adequate implementation experience, and consensus-building, and is subject to the W3C Patent Policy [PATENT-POLICY], under which participants commit to Royalty-Free IPR licenses for implementations. See § 6.3 The W3C Recommendation Track for details.

メモ
Notes

部会は, 典型的に, 仕様書に刺激を与える使用方法やその使用の最善の実施例といった技術仕様書でない情報を文書化するか, もしくは, 思いのままの作業の状態を明確にするのに, W3CメモおよびW3C声明として文書を発行することもできます. 詳細については, § 6.4 メモ工程(メモと声明)を参照して下さい.

Groups can also publish documents as W3C Notes and W3C Statements, typically either to document information other than technical specifications, such as use cases motivating a specification and best practices for its use. See § 6.4 The Note Track (Notes and Statements) for details.

データ一覧
Registries

作業部会は, 値や他のデータを一覧にまとめたものを文書化するため, データ一覧を発行することもできます. それらは, 勧告工程の文書にデータ一覧節として直接埋め込まれることもありますが, 典型的に分割されたデータ一覧報告書の中で発行されます. データ一覧を定義するには, 広範囲にわたる審査と 合意が必要ですが, 一度設定したなら, データ一覧登録データの変更は容易で, 作業部会無しでもできます. 詳しくは, § 6.5 データ一覧工程を参照して下さい.

Working Groups can also publish registries in order to document collections of values or other data. These are typically published in a separate registry report, although they can also be directly embedded in Recommendation Track documents as a registry section. Defining a registry requires wide review and consensus, but once set up, changes to registry entries are lightweight and can even be done without a Working Group. See § 6.5 The Registry Track for details.

個々の作業部会や関連部会は, この章の要件と衝突しなければ, 発行物を開発する追加の手続きを受け入れるべきです.

Individual Working Groups and Interest Groups should adopt additional processes for developing publications, so long as they do not conflict with the requirements in this chapter.

6.2. 技術報告書に対する一般的な要件
General Requirements for Technical Reports

6.2.1. 技術報告書の発行
Publication of Technical Reports

この文書で使われている発行は, W3Cのhttps://www.w3.org/TR の技術報告書一覧でW3C技術報告書として一覧にされた文書を生み出すことに当てはまります. 技術報告書開発工程の一環として発行される全ての文書は, 公開された文書でなければなりません. W3Cは, 古い文書を無期限に元々の場所, 元々の形式で利用できるよう努力します.

Publishing as used in this document refers to producing a version which is listed as a W3C Technical Report on its Technical Reports index at https://www.w3.org/TR [TR]. Every document published as part of the technical report development process must be a public document. W3C strives to make archival documents indefinitely available at their original address in their original form.

技術報告書開発手続きの一部として発行された文書は, その成熟レベルを明確に示さなければなりません. また, 文書の状態についての情報を含まなければなりません. この状態の情報は次のとおりです.

Every document published as part of the technical report development process must clearly indicate its maturity level, and must include information about the status of the document. This status information:

• 仕様書が発行されるたびに一意のものでなければなりません.
  must be unique each time a specification is published,
• どの作業部会が仕様書を開発したのかをはっきり述べなければなりません.
  must state which Working Group developed the specification,
• どのように意見やバグの報告を送るか, また, それらがどこに記録されるかをはっきり述べなければなりません.
  must state how to send comments or file bugs, and where these are recorded,
• 次の段階で期待される内容を含まなければなりません.
  must include expectations about next steps,
• どのようにその技術が国際標準やW3C内外の関連する作業に関係しているかを説明すべきです.
  should explain how the technology relates to existing international standards and related work inside or outside W3C, and
• 前回のバージョンからの重大な変更について説明するか, 説明へのリンクを貼るかすべきです.
  should explain or link to an explanation of significant changes from the previous version.

技術報告書開発手続きの一部として発行された技術報告書は, 部会の議長に指名された1人以上の編集者によって編集されます. 部会の議論を技術報告書の次の草案に正確に確実に反映させることは, 編集者の責務です. 編集者は, § 3.4.2 憲章を持つ部会への参加を通じて, 自分達が編集した文書に対する部会の責任において, 部会の参加者でなければなりません.

Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. It is the responsibility of these editors to ensure that the decisions of the Group are correctly reflected in subsequent drafts of the technical report. An editor must be a participant, per § 3.4.2 Participation in Chartered Groups in the Group responsible for the document(s) they are editing.

事務局にとって, 事務局の発行の決まり [発行の決まり](例えば, 名前, 状態の情報, 書式, 著作権の要件)に合致しない技術報告書を発行することは必須ではありません. この決まりは, 時折, 事務局によって変更される対象です. 事務局は, この決まりのどの変更も部会の議長と諮問委員会に通知しなければなりません.

The Team is not required to publish a Technical Report that does not conform to the Team’s Publication Rules [PUBRULES] (e.g., for naming, status information, style, and copyright requirements). These rules are subject to change by the Team from time to time. The Team must inform group Chairs and the Advisory Committee of any changes to these rules.

W3C技術報告書の第一の言語は英語です. W3Cは, 技術報告書の翻訳を促しています. W3C技術報告書の翻訳についての情報 [翻訳]は, W3Cのウェブサイトで利用できます.

The primary language for W3C Technical Reports is English. W3C encourages the translation of its Technical Reports. Information about translations of W3C technical reports [TRANSLATION] is available at the W3C Web site.

6.2.2. 審査と審査の責務
Reviews and Review Responsibilities

文書は, 発行された瞬間から審査が可能です, 作業部会は, 技術報告書についてのどの実質的な審査意見も迅速に正式に取り組むべきです.

A document is available for review from the moment it is first published. Working Groups should formally address any substantive review comment about a technical report in a timely manner.

審査者は, 可能な限り早く実質的な技術の審査意見を送るべきです. 作業部会は, 熟慮した文書に実質的な変更をたびたび行いたくはないです. 特にその変更が, 既存の実装に対する重大な互換性の問題を引き起こす場合は行いたくはないです. 作業部会は, 審査者から挙げられた実質的な, もしくは興味深い提案を, 現在の仕様書に組み込まなかったとしても記録すべきです.

Reviewers should send substantive technical reviews as early as possible. Working Groups are often reluctant to make substantive changes to a mature document, particularly if this would cause significant compatibility problems due to existing implementation. Working Groups should record substantive or interesting proposals raised by reviews but not incorporated into a current specification.

6.2.2.1. 広範囲にわたる審査
Wide Review

広範囲にわたる審査は, W3C手続き文書では正確には定義していません. この審査の目的は, ウェブ界隈の利害関係者全体が, 一般社会を含めて, (例えば, public-review-announce@w3.orgへと公表された周知を通して)作業部会の経過を十分に周知され, 仕様書を審査したり, 仕様書に意見を提供したりできることを, 確かなものにすることです. 2番目の目的は, 意見や提案された変更を分別よく, 審査者への返答にまだ組み込める十分早い段階で, 部会に審査を依頼するよう促すことです. 遷移を承認する前に, ディレクターは, 誰が文書の審査をするのに無理のない時期にはっきりと依頼していたか, 誰が意見を提供していたか, 審査者, 特にW3Cの対等な部会 [憲章]と, 憲章で依存関係が特定されている部会または連絡体制 [連絡体制]が特定されている部会からの依頼と返答の記録を考慮し, 適切な時期に一般社会と明確に情報交換を行ったか, どの内容が審査され, そのような審査者が実際に存在するかどうか, 証拠を求めるでしょう.

The requirements for wide review are not precisely defined by the W3C Process. The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have had adequate notice of the progress of the Working Group (for example through notices posted to public-review-announce@w3.org) and were able to actually perform reviews of and provide comments on the specification. A second objective is to encourage groups to request reviews early enough that comments and suggested changes can still be reasonably incorporated in response to the review. Before approving transitions, the Director will consider who has been explicitly offered a reasonable opportunity to review the document, who has provided comments, the record of requests to and responses from reviewers, especially W3C Horizontal Groups [CHARTER] and groups identified as dependencies in the charter or identified as liaisons [LIAISON], and seek evidence of clear communication to the general public about appropriate times and which content to review and whether such reviews actually occurred.

例えば, 草案の中で発行された, 新しい, または著しく改訂された節への審査意見を求めることや, それらの意見や作業部会の返答を記録することは, 広範囲にわたる審査の明確な証拠とたびたび見なされるだろう良い例です. 作業部会は, W3Cの対等な部会の審査の手続きに従うべきで, 他のW3Cの作業部会や同様に一般社会, 特にその仕様書によって影響を受ける団体に, 提案が勧告候補になったことを(例えば, およそ28日間にわたって)知らせるべきです. 対照的に, いつでも審査を依頼するという文書の文言は, 部会が広範囲にわたる審査を要求した十分な証拠とは見なされないでしょう.

For example, inviting review of new or significantly revised sections published in Working Drafts, and tracking those comments and the Working Group's responses, is generally a good practice which would often be considered positive evidence of wide review. Working Groups should follow the W3C Horizontal Groups’ review processes, and should announce to other W3C Working Groups as well as the general public, especially those affected by this specification, a proposal to enter Candidate Recommendation (for example in approximately 28 days). By contrast a generic statement in a document requesting review at any time is likely not to be considered as sufficient evidence that the group has solicited wide review.

作業部会は, 広範囲にわたる審査を受け取った証拠を, 教唆を考慮せずに示すことができます. ただし, 詳細な審査意見は, 関連する利害関係者界隈の一部分からの意見を示すだけでも良いので, たくさんのそのような意見を受け取ることは, 広範囲にわたる審査と必ずしも同じではないことに注意することが重要です.

A Working Group could present evidence that wide review has been received, irrespective of solicitation. But it is important to note that receiving many detailed reviews is not necessarily the same as wide review, since they might only represent comment from a small segment of the relevant stakeholder community.

6.2.3. 変更の種類
Classes of Changes

この文書は, 仕様書への変更を次の5種類に区分しています. 最初の2種類の変更は編集上の変更, 次の2種類は実質的な変更, 最後の1種類はデータ一覧変更です.

This document distinguishes the following 5 classes of changes to a specification. The first two classes of change are considered editorial changes, the next two substantive changes, and the last one registry changes.

1. 文章の内容に変更無し

   No changes to text content

この変更は, 壊れたリンク, スタイルシート, 無効なマークアップの修正を含んでいます.

These changes include fixing broken links, style sheets or invalid markup.

2. 適合に影響しない訂正

   Corrections that do not affect conformance

分別のある実装者が, 技術体系上または相互運用上の更新, もしくは自分達の実装を変更しないと解釈するであろう変更. 仕様書のあいまいさを解消する変更は, (明確化によって)実装の要件を変更すると見なされ, この種類には分類されません.

Changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) the implementation requirements and do not fall into this class.

この種類の変更の例には, 正規の要件とはっきり矛盾するコードである非正規のコードの例を訂正すること, 有益な使用方法または標準でない文章を明確化すること, 修正しても実装の要件を変更しない印刷上または文法上の誤りを訂正することが含まれます. 要件が変更されるかどうかといった何らかの疑いや不同意がある場合, そのような変更は, この種類に分類されません.

Examples of changes in this class include correcting non-normative code examples where the code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or disagreement as to whether requirements are changed, such changes do not fall into this class.

3. 新しい機能を追加しない訂正

   Corrections that do not add new features

この変更は, 仕様書の適合に影響を与えてもよいです. 適合に影響を与える変更は, 次のものがあります.

These changes may affect conformance to the specification. A change that affects conformance is one that:

• 適合しているデータ, 処理プログラム, 他の適合しているプログラムを, 新しいバージョンによって不適合にするもの.
  makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or
• 不適合なデータ, 処理プログラム, 他の不適合なプログラムを, 適合しているものにするもの.
  makes non-conforming data, processors, or other agents become conforming, or
• 適合が不明瞭だったデータ, 処理プログラム, 他のプログラムが, 明確に適合しているか不適合かのどちらかになるような方法で, 仕様書のあいまいな部分, または解釈が一意でない部分を明確にするもの.
  clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.

4. 新しい機能

   New features

新しい機能, 要素などを加える変更.

Changes that add a new functionality, element, etc.

5. データ一覧表の中身の変更

   Changes to the contents of a registry table

データ一覧表の中のデータ一覧登録データを追加, 削除, 改変する変更.

Changes that add, remove, or alter registry entries in a registry table.

6.2.4. 正誤表の管理
Errata Management

誤りを記録することは, 作業部会の技術報告書の継続している配慮の重要な部分です. この理由から, 作業部会憲章の範囲は, 一般に勧告の発行後の作業時間を認めています. この手続き文書において“正誤表”(訳注:原文の英語では単数形の“erratum”と複数形の“errata”について述べていますが, どちらも正誤表に当たります.)という用語は, § 6.2.3 変更の種類の節の種類1-3の1つ以上の変更で解消できる何らかの誤りを参照しています.

Tracking errors is an important part of a Working Group's ongoing care of a technical report; for this reason, the scope of a Working Group charter generally allows time for work after publication of a Recommendation. In this Process Document, the term “erratum” (plural “errata”) refers to any error that can be resolved by one or more changes in classes 1-3 of section § 6.2.3 Classes of Changes.

作業部会は, 勧告に対して読者や実装者から報告された誤りの公開の記録を維持しなければなりません. そのような誤りの報告は, 3ヵ月に1度以上の頻度で編集されるべきです.

Working Groups must keep a public record of errors that are reported by readers and implementers for Recommendations. Such error reports should be compiled no less frequently than quarterly.

作業部会は, どのように正誤表を文書化するか決めます. そのような文書は, 影響を受ける技術報告書の文章を特定し, 誤りについて述べなければなりません. その文書は, 何らかの可能な解決策について述べてもよいです. 技術報告書の読者は, 自分達が連想する試験と一緒に, その技術報告書に適用される正誤表を簡単に見つけたり参照したりできるべきです. 正誤表は, 分割された正誤表のページまたは記録システムで文書化されてもよいです. 正誤表は, 追加で, または代わりに, 影響される技術報告書の文章のそば, もしくは最も関係する文節の始まりまたは終わりの, 行中に注釈を付けてもよいです.

Working Groups decide how to document errata. Such documentation must identify the affected technical report text and describe the error; it may also describe some possible solution(s). Readers of the technical report should be able easily to find and see the errata that apply to that specific technical report with their associated tests. Errata may be documented in a separate errata page or tracking system. They may, in addition or alternatively, be annotated inline alongside the affected technical report text or at the start or end of the most relevant section(s).

6.2.5. 改正候補
Candidate Amendments

正誤表は, 作業部会の合意によって承認された, 有益な訂正候補に加えられてもよいです. 行中で注釈として付けられたとき, 正誤表は, 訂正候補を含めて, 相応に記述され, 種類2の変更として扱われ, 状況に応じて公開されなければなりません.

An erratum may be accompanied by an informative, candidate correction approved by the consensus of the Working Group. When annotated inline, errata—including their candidate corrections—must be marked as such, are treated as class 2 changes, and are published accordingly.

注意:この方法で注釈として付けられた変更は, 勧告や勧告候補といったより熟慮された文書を, 例え, 改正候補が重要な審査意見や適切に仕様書に標準的に組み入れる実装の実績がまだだったとしても, 作業部会の最新のものと一緒に早急に更新することを認めています.

Note: Annotating changes in this way allows more mature documents such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, even when the candidate amendments have not yet received sufficient review or implementation experience to be normatively incorporated into the specification proper.

追加候補は, 誤りの訂正でなく新しい機能を提案していることを除いて, 訂正候補と類似しています.

A candidate addition is similar to a candidate correction, except that it proposes a new feature rather than an error correction.

どの部会も技術報告書を維持管理するよう憲章に書いていない場合は, 事務局がその文書の正誤表や関連した訂正候補を維持管理してもよいです. そのような訂正は, 事務局訂正として示されなければなりませんし, 特許指針[特許指針]で定義された勧告の規範的な部分の一部をなしません(すなわち, それらの訂正は特許指針によって保護されません). 事務局は, 生み出した事務局訂正において広範囲にわたる審査を要求しなければなりません.

If there is no group chartered to maintain a technical report, the Team may maintain its errata and associated candidate corrections. Such corrections must be marked as Team correction, and do not constitute a normative portion of the Recommendation, as defined in the Patent Policy [PATENT-POLICY] (i.e. they are not covered by the Patent Policy). The Team must solicit wide review on Team corrections that it produces.

訂正候補と追加候補は, 合わせて改正候補として知られています.

Candidate corrections and candidate additions are collectively known as candidate amendments.

それらの変更の成熟レベルに加えて, 改正候補と一緒に発行された勧告工程の文書は, W3C特許指針[特許指針]の目的のために, それらの標準として扱われる改正候補と一緒に草案とみなされます.

In addition to their actual maturity level, published REC Track documents with candidate amendments are also considered, for the purpose of the W3C Patent Policy [PATENT-POLICY], to be Working Drafts with those candidate amendments treated as normative.

6.2.6. 参加者以外からのライセンス承認
License Grants from Non-Participants

特許指針にまだ縛られていない団体から, この手続き文書下の技術報告書に(§ 6.2.3 変更の種類で述べた)種類3または4の変更の提案があった場合, 事務局は, 記録されたロイヤリティフリー特許の言質を依頼しなければなりません. そのような言質は, W3C特許指針[特許指針]の“W3Cロイヤリティフリー(RF)ライセンス要件”の節で指定された条件において, 少なくとも, 提案の中の団体の本質的な主張(訳注:当該日本語訳では"Essential Claim"の日本語訳に"本質的主張"を当てていますが, "Essential Claim"という用語はW3C特許指針で定義された用語です.), その時点で存在している草案に提案を組み込んだ結果として本質的な主張になるもの両方を網羅すべきです.

When a party who is not already obligated under the Patent Policy offers a change in class 3 or 4 (as described in § 6.2.3 Classes of Changes) to a technical report under this process the Team must request a recorded royalty-free patent commitment; for a change in class 4, the Team must secure such commitment. Such commitment should cover, at a minimum, all the party’s Essential Claims both in the contribution, and that become Essential Claims as a result of incorporating the contribution into the draft that existed at the time of the contribution, on the terms specified in the “W3C Royalty-Free (RF) Licensing Requirements” section of the W3C Patent Policy [PATENT-POLICY].

6.3. W3C勧告工程
The W3C Recommendation Track

作業部会は, 作業部会の憲章によって予想された作業の範囲を完成させるために, 仕様書や手引きを作成します. これらの技術報告書は, W3C勧告の状態に進展するように, 改訂や審査を繰り返します. 広範囲にわたる審査を含め, 一度, 作業部会が新しい標準としての要件を処理したことを, 審査が示したなら, 勧告候補の段階は, 仕様書が実際に機能することを証明するために, 作業部会に実装の実績を正式に集めることを認めます. 手続きの最後に, 諮問委員会は熟慮された技術報告書を審査し, W3C会員の支持があるなら, W3Cはその文書を勧告として発行します.

Working Groups create specifications and guidelines to complete the scope of work envisioned by a Working Group's charter. These technical reports undergo cycles of revision and review as they advance towards W3C Recommendation status. Once review suggests the Working Group has met their requirements for a new standard, including wide review, a Candidate Recommendation phase allows the Working Group to formally collect implementation experience to demonstrate that the specification works in practice. At the end of the process, the Advisory Committee reviews the mature technical report, and if there is support from its Membership, W3C publishes it as a Recommendation.

要約すると, W3C勧告工程は, 次のものから構成されます.

In summary, the W3C Recommendation Track consists of:

1. 初期草案の発行.
   Publication of the First Public Working Draft.
2. 0回以上の改訂された草案の発行.
   Publication of zero or more revised Working Drafts.
3. 1回以上の勧告候補の発行.
   Publication of one or more Candidate Recommendations.
4. 勧告案の発行.
   Publication of a Proposed Recommendation.
5. W3C勧告の発行.
   Publication as a W3C Recommendation.

この手続き文書は, 特許審査草案として最新の勧告工程の発行物を定義しています. (2017年に更新された)2004年の特許指針[特許指針2004]の下で, それらは, 特許指針での“最終草案”に相当しています. それらは, 2020年の特許指針[特許指針2020]から始まった, 特許指針[特許指針]での“特許審査草案”に相当しています.

This Process defines certain Recommendation Track publications as Patent Review Drafts. Under the 2004 Patent Policy (and its 2017 update) [PATENT-POLICY-2004], these correspond to “Last Call Working Draft” in the Patent Policy; Starting from the 2020 Patent Policy [PATENT-POLICY-2020], these correspond to “Patent Review Draft” in the Patent Policy [PATENT-POLICY].

W3Cは, いつでも技術報告書の作業を終了してよいです.

W3C may end work on a technical report at any time.

ディレクターは, 作業部会に更なる作業を要求する場合, 成熟レベルを進展させる依頼を拒否してもよいです. また, 仕様書をより下位の成熟レベルに戻すよう要求してもよいです. 事務局は, 作業部会による仕様書に対して成熟レベルを進展させる依頼を拒否し, その仕様書が更なる作業のために作業部会に戻される場合, 諮問委員会と作業部会の議長に通知しなければなりません.

The Director may decline a request to advance in maturity level, requiring a Working Group to conduct further work, and may require the specification to return to a lower maturity level. The Team must inform the Advisory Committee and Working Group Chairs when a Working Group's request for a specification to advance in maturity level is declined and the specification is returned to a Working Group for further work.

6.3.1. 勧告工程における成熟レベル
Maturity Levels on the Recommendation Track

草案 (WD)
Working Draft (WD)

草案は, (W3C会員を含めた)関係者, 一般社会, 他の技術団体の審査のためや, 単に履歴の参照のために, W3CがW3Cの技術報告書のページ [TR]で発行した文書です. 全てではありませんが, 草案の中には, 勧告へ進展するつもりであるものもあります. 作業部会の将来の見込みについて, 草案の文書の位置付けの節を参照して下さい. 草案は, その内容に関して作業部会の合意の結果である必要はなく, 技術の一般的な分野での作業への同意以上のW3CやW3C会員による何らかの支援を意図しておりません. それでも作業部会は, 採用時点の作業状況に基づいて, 草案の採用を決定します. 草案は, 成熟レベルの次の段階に進むために重要な広範囲にわたる審査の意見を集めるのに適しています.

A Working Draft is a document that W3C has published on the W3C’s Technical Reports page [TR] for review by the community (including W3C Members), the public, and other technical organizations, and for simple historical reference. Some, but not all, Working Drafts are meant to advance to Recommendation; see the document status section of a Working Draft for the group’s expectations. Working Drafts do not necessarily represent a consensus of the Working Group with respect to their content, and do not imply any endorsement by W3C or its members beyond agreement to work on a general area of technology. Nevertheless the Working Group decided to adopt the Working Draft as the basis for their work at the time of adoption. A Working Draft is suitable for gathering wide review prior to advancing to the next stage of maturity.

全ての草案に対して, 作業部会は次のようです.

For all Working Drafts a Working Group:

• 目立った課題や, 作業部会で合意を得られていない文書の部分を明文化すべきです.
  should document outstanding issues, and parts of the document on which the Working Group does not have consensus, and
• 草案の内容が不安定と見なされ, 全ての作業部会での要件を満たしていなかったとしても, 草案の発行を依頼してもよいです.
  may request publication of a Working Draft even if its content is considered unstable and does not meet all Working Group requirements.

技術報告書の最初の草案は, 初期草案 (FPWD)と呼ばれ, W3C特許指針[特許指針]で定義されたとおり特許に関連しています.

The first Working Draft of a technical report is called the First Public Working Draft (FPWD), and has patent implications as defined in the W3C Patent Policy [PATENT-POLICY].

勧告候補 (CR)
Candidate Recommendation (CR)

勧告候補は, 文書を生み出した作業部会の技術的な要件や依存関係を満たす, 既に広範囲にわたる審査意見を受け取っている文書です. W3Cは, 次のために勧告候補を発行します.

A Candidate Recommendation is a document that satisfies the technical requirements of the Working Group that produced it and their dependencies, and has already received wide review. W3C publishes a Candidate Recommendation to

• 最終的な審査を行う時期にある, より広範囲の関係者に合図するため.
  signal to the wider community that it is time to do a final review
• 実装の実績を集めるため.
  gather implementation experience

注意:勧告候補への進展は, その文書が完璧と見なされ, 目的に合致していること, また, 何も追加の実装の実績や試験無しに文書への更なる改善が期待されていないことを意図しています. ただし, 後の改訂で追加の機能が期待されてもよいです. 勧告候補は, しっかり書かれ, 詳細で, 自己矛盾の無い, 勧告として技術的に完璧なことを期待され, 更なる進展の必要性に直面しても満足できるものです.

Note: Advancing to Candidate Recommendation indicates that the document is considered complete and fit for purpose, and that no further refinement to the text is expected without additional implementation experience and testing; additional features in a later revision may however be expected. A Candidate Recommendation is expected to be as well-written, detailed, self-consistent, and technically complete as a Recommendation, and acceptable as such if and when the requirements for further advancement are met.

勧告候補の発行は, 次の2つの形式のうち1つとなります.

Candidate Recommendation publications take one of two forms:

勧告候補全体版
Candidate Recommendation Snapshot

勧告候補全体版は, W3C特許指針[特許指針]で使われている特許審査草案に合致します. 特許審査草案の公開は, W3C特許指針における“W3C RFライセンス要件からの除外”を通して, 除外の要請のきっかけとなります.

A Candidate Recommendation Snapshot corresponds to a Patent Review Draft as used in the W3C Patent Policy [PATENT-POLICY]. Publishing a Patent Review Draft triggers a Call for Exclusions, per “Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy.

勧告候補全体版としての公開には, (他の成熟レベルから最初の勧告候補の公開となる)遷移要求か, (勧告候補全体版の次のものとなる)更新要求, どちらかの要求の承認が必要です.

Publication as a Candidate Recommendation Snapshot requires approval of either a Transition Request (for the first Candidate Recommendation publication from another maturity level) or an Update Request (for subsequent Candidate Recommendation Snapshots).

勧告候補草案版
Candidate Recommendation Draft

勧告候補草案版は, 作業部会がすぐ次の勧告候補全体版に含めることを意図している, 前の勧告候補全体版からの変更をまとめるために, W3Cの技術報告書のページ [TR]に公開されます. このことは, 変更の広範囲にわたる審査を可能にし, まとまった仕様書への参照を簡単にしています.

A Candidate Recommendation Draft is published on the W3C’s Technical Reports page [TR] to integrate changes from the previous Candidate Recommendation Snapshot that the Working Group intends to include in a subsequent Candidate Recommendation Snapshot. This allows for wider review of the changes and for ease of reference to the integrated specification.

勧告候補草案版で直接公開されたどの変更も, 勧告候補全体版と同じ水準であるべきです. ただし, 手続きの要件は最低限とされており, そのため, 作業部会は, 簡単に仕様書を最新に保つことができます.

Any changes published directly into a Candidate Recommendation Draft should be at the same level of quality as a Candidate Recommendation Snapshot. However, the process requirements are minimized so that the Working Group can easily keep the specification up to date.

勧告候補草案版は, その代わり, 除外機会を提供せず, W3C特許指針 [特許指針]の目的のための草案と見なされます.

A Candidate Recommendation Draft does not provide an exclusion opportunity; instead, it is considered a Working Draft for the purpose of the W3C Patent Policy [PATENT-POLICY].

廃止勧告候補は, 例えば, 実装に影響して解決できないやっかいな特許の主張によって(W3C特許指針[特許指針]と特に“PAG決定”(訳注:PAGは"Patent Advisory Group"(特許助言部会)の略)の中を参照), W3Cが支持できない, または作業を継続できない重大な問題が見つかった勧告候補です. 廃止勧告候補に対して何も復活の道筋はありません. 特許ライセンス義務における実装に対しては, W3C特許指針[特許指針]の“W3Cロイヤリティフリー(RF)ライセンス要件”を参照して下さい.

A Rescinded Candidate Recommendation is a Candidate Recommendation in which significant problems have been discovered such that W3C cannot endorse it or continue work on it, for example due to burdensome patent claims that affect implementers and cannot be resolved (see the W3C Patent Policy [PATENT-POLICY] and in particular “PAG Conclusion”). There is no path to restoration for a Rescinded Candidate Recommendation. See “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY] for implication on patent licensing obligations.

勧告案 (PR)
Proposed Recommendation (PR)

勧告案は, W3CによってW3C勧告となるのに十分な品質のものとして承認された文書です. この段階は, 文書をW3C勧告として発行すること, または, 更なる作業のために作業部会に差し戻すこと, 断念することを推奨してもよい諮問委員会による公式な審査のきっかけとなります. 実質的な変更は, 新しい草案または勧告候補を発行することを除いて, 勧告案に対して行ってはなりません.

A Proposed Recommendation is a document that has been accepted by W3C as of sufficient quality to become a W3C Recommendation. This phase triggers formal review by the Advisory Committee, who may recommend that the document be published as a W3C Recommendation, returned to the Working Group for further work, or abandoned. Substantive changes must not be made to a Proposed Recommendation except by publishing a new Working Draft or Candidate Recommendation.

W3C勧告 (REC)
W3C Recommendation (REC)

W3C勧告は, 広範囲にわたる合意形成の後, W3Cとその会員から支持を得た, 仕様書, もしくは手引きまたは要件の集合です. W3Cは, ウェブの標準として勧告の広範囲にわたる展開を推奨しています. W3C特許指針[特許指針]の下で認められているW3CロイヤリティフリーIPRライセンスが, W3C勧告に適用されます. 技術の発展に従って, W3C勧告は次のようになるかもしれません.

A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of W3C and its Members. W3C recommends the wide deployment of its Recommendations as standards for the Web. The W3C Royalty-Free IPR licenses granted under the W3C Patent Policy [PATENT-POLICY] apply to W3C Recommendations. As technology evolves, a W3C Recommendation may become:

置換済勧告
A Superseded Recommendation

置換済勧告は, W3Cが新しく採用するように推奨している, より新しいバージョンによって置き換えられた仕様書です. 旧式または置換済の仕様書は, 特許指針の下で認められているW3CロイヤリティフリーIPRライセンスに関して, W3C勧告と同じ位置付けを持ちます.

A Superseded Recommendation is a specification that has been replaced by a newer version that W3C recommends for new adoption. An Obsolete or Superseded specification has the same status as a W3C Recommendation with regards to W3C Royalty-Free IPR Licenses granted under the Patent Policy.

注意:勧告として以前に発行されていた技術報告書が, その文書を改訂するのに必要な工程に従って勧告として再度発行されたとき, 最新のバージョンは, § 6.3.12.3 W3C勧告の断念の工程を実施する必要無しに以前のものを置き換えます. その文書は, 更新された同じ文書です. 文書が置換されたと明確に宣言し, § 6.3.12.3 W3C勧告の断念で文書化された工程を用いることは, 勧告が分割された技術報告書(またはW3C以外に管理された文書)によって置き換えられる状況を意味しています.

Note: When a Technical Report which had previously been published as a Recommendation is again published as a Recommendation after following the necessary steps to revise it, the latest version replaces the previous one, without the need to invoke the steps of § 6.3.12.3 Abandoning a W3C Recommendation: it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in § 6.3.12.3 Abandoning a W3C Recommendation, is intended for cases where a Recommendation is superseded by a separate Technical Report (or by a document managed outside of W3C).

旧式勧告
An Obsolete Recommendation

旧式勧告は, 実装するための推奨を継続する十分な市場性を欠いているとW3Cが判断したが, 廃止する必要があるほどの根本的な問題を持たない仕様書です. 旧式の仕様書が十分な市場性を得た場合, W3Cは, その文書を勧告の状態に戻すことを決定してもよいです.

An Obsolete Recommendation is a specification that W3C has determined lacks sufficient market relevance to continue recommending it for implementation, but which does not have fundamental problems that would require it to be Rescinded. If an Obsolete specification gains sufficient market relevance, W3C may decide to restore it to Recommendation status.

廃止勧告
Rescinded Recommendation

廃止勧告は, W3Cがもはや支持しておらず, 絶対に勧告の状態に戻される見込みがないと考えている勧告全体です. W3C特許指針[特許指針]の“W3Cロイヤリティフリー(RF)ライセンス要件”を参照して下さい.

A Rescinded Recommendation is an entire Recommendation that W3C no longer endorses, and believes is unlikely to ever be restored to Recommendation status. See also “W3C Royalty-Free (RF) Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY].

中止草案
Discontinued Draft

作業が中止された時点の勧告工程の文書の状態を表す技術報告書. § 6.3.12.1 完了していない勧告の断念を参照して下さい.

A technical report representing the state of a Recommendation-track document at the point at which work on it was discontinued. See § 6.3.12.1 Abandoning an Unfinished Recommendation.

十分に技術的な成熟レベルにある作業のみ進展されるべきです.

Only sufficiently technically mature work should be advanced.

注意:予定を考慮したより早い進展が望まれるべきときは, 技術報告書の適用範囲を十分に熟慮された部分へと縮小したり, 若干安定的でない機能を他の技術仕様書に任せることで達成できます.

Note: Should faster advancement to meet scheduling considerations be desired, this can be achieved by reducing the scope of the technical report to a subset that is adequately mature and deferring less stable features to other technical reports.

既存の勧告候補または勧告の更新版を発行するとき, 技術報告書は, その状態の下で初めて発行されたときと同じ成熟レベルの基準で扱われることが期待されます. しかしながら, 古くなった文書を改善したもので迅速に置き換える観点において, 発行文書が遅れずに周知されることを却下するには十分現実的でないだろうCRまたはRECとしての最初の発行後に, 不備が技術報告書に見つかった場合, 例え, 不備の一部だけが満足のいくように処理されるとしても, 通常の手続きに従って更新されたCRまたはRECを発行することは差し支えないでしょう.

When publishing an updated version of an existing Candidate Recommendation or Recommendation, technical reports are expected to meet the same maturity criteria as when they are first published under that status. However, in the interest of replacing stale documents with improved ones in a timely manner, if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, it is also permissible to publish an updated CR or REC following the usual process, even if only some of these flaws have been satisfactorily addressed.

作業部会と関連部会は, 利用可能な編集者草案を作成してもよいです. 編集者草案 (ED)は, 何ら公式な状態は持っておらず, 作業部会または関連部会の合意は必ずしも意味せず, W3Cから何ら支持された内容でもないです.

Working Groups and Interest Groups may make available Editor’s drafts. Editor’s drafts (ED) have no official standing whatsoever, and do not necessarily imply consensus of a Working Group or Interest Group, nor are their contents endorsed in any way by W3C.

6.3.2. 実装の実績
Implementation Experience

実装の実績は, 仕様書が十分に明瞭で, 完璧で, 市場の要望に関連しているかを示すために, また, 仕様書の各機能の独立した相互運用可能な実装が達成されるであろうことを確かなものにするために必要です. 網羅的な要件の一覧が提供されない限り, 十分な実装の実績があるか判断するとき, ディレクターは, 次のことを(ただし, これらに限らず)考慮します.

Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized. While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the Director will consider (though not be limited to):

• 最新の仕様書の各機能は実装されているか, また, どのようにそのことを証明しているか?
  is each feature of the current specification implemented, and how is this demonstrated?
• 最新の仕様書の独立した相互運用可能な実装があるか?
  are there independent interoperable implementations of the current specification?
• 仕様書の著者以外の人々によって作られた実装があるか?
  are there implementations created by people other than the authors of the specification?
• 実装は公然と展開されているか?
  are implementations publicly deployed?
• 仕様書の各段階の実装システム(編集, 利用, 配布など)で実装の実績があるか?
  is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)?
• 実装に伴う困難な点または問題点の報告があるか?
  are there reports of difficulties or problems with implementation?

(相互運用可能な)実装の証明を計画し成し遂げることは, たくさんの時間を費やすことになるでしょう. 部会は, 開発手続きの早いうちに, どのように相互運用可能な実装を証明するか計画すれば, より効果的に作業できます. 例えば, 実装の努力と協力して開発テストを行うことです.

Planning and accomplishing a demonstration of (interoperable) implementations can be very time consuming. Groups are often able to work more effectively if they plan how they will demonstrate interoperable implementations early in the development process; for example, developing tests in concert with implementation efforts.

6.3.3. 勧告工程における進展
Advancement on the Recommendation Track

仕様書を新しい成熟レベルに進展させる(遷移要求と呼ばれる)全ての要求に当たって, 作業部会は次のとおりです.

For all requests to advance a specification to a new maturity level (called Transition Requests), the Working Group:

• 進展を要求する部会決定を記録しなければなりません.
  must record the group’s decision to request advancement.
• ディレクターの承認を得なければなりません.
  must obtain Director approval.
• 前回の公開以降の技術報告書に対する全ての新しい機能(種類4の変更)を公然と文書化しなければなりません.
  must publicly document all new features (class 4 changes) to the technical report since the previous publication.
• 他の実質的な変更(種類3の変更)が行われたかどうか公然と文書化しなければならず, そのような変更の詳細について文書化すべきです.
  must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
• 編集上の変更が行われたかどうか公然と文書化すべきで, そのような変更の詳細について文書化してもよいです.
  should publicly document if editorial changes have been made, and may document the details of such changes.
• 以前の成熟レベル以降に文書に挙げられた課題を正式に取り組まなければなりません.
  must formally address all issues raised about the document since the previous maturity level.
• どの正式な異議の公開の文書も提供しなければなりません.
  must provide public documentation of any Formal Objections.
• もし, 前回の段階以降に, その文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• 他の部会との依存関係における変更があれば報告すべきです.
  should report any changes in dependencies with other groups.
• 作業部会が知っている実装についての情報を提供すべきです.
  should provide information about implementations known to the Working Group.

初期草案に対して何も“以前の成熟レベル”は無いので, 多くの要件は適用されず, 承認は, 通常かなり自動的です. 後の段階では, 特に勧告候補または勧告案への遷移においては, 通常, 承認が下りる前に, 要件が満たされていることを確かなものにする正式な審査の会議があります.

For a First Public Working Draft there is no “previous maturity level”, so many requirements do not apply, and approval is normally fairly automatic. For later stages, especially transition to Candidate or Proposed Recommendation, there is usually a formal review meeting to ensure the requirements have been met before approval is given.

初期草案または勧告候補への遷移要求は, 作業部会の憲章が諮問委員会の審査における決定を受ける途中や待っている間は, 通常承認されません.

Transition Requests to First Public Working Draft or Candidate Recommendation will not normally be approved while a Working Group's charter is undergoing or awaiting a decision on an Advisory Committee Review.

6.3.4. 勧告工程における同じ成熟レベルの発行物の更新
Updating Mature Publications on the Recommendation Track

仕様書を現在の成熟レベルの中で再発行する(更新要求と呼ばれる)特定の要求は, ディレクターの承認が必要です. そのような更新要求に当たって, 作業部会は次のとおりです.

Certain requests to re-publish a specification within its current maturity level (called Update Requests) require Director approval. For such update requests, the Working Group:

• 更新を要求する部会決定を記録しなければなりません.
  must record the group’s decision to request the update.
• 変更が広範囲にわたる審査を受けていたことを示さなければなりません.
  must show that the changes have received wide review.
• ディレクターの承認を得るか, § 6.3.4.1 合理化された発行承認の基準を満たさなければなりません.
  must obtain Director approval, or fulfill the criteria for § 6.3.4.1 Streamlined Publication Approval.
• どの正式な異議の公開の文書も提供しなければなりません.
  must provide public documentation of any Formal Objections.
• 前回の公開以降の技術報告書に対する全ての新しい機能(種類4の変更)を公然と文書化しなければなりません.
  must publicly document of all new features (class 4 changes) to the technical report since the previous publication.
• 他の実質的な変更(種類3の変更)が行われたかどうか公然と文書化しなければならず, そのような変更の詳細について文書化すべきです.
  must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
• 編集上の変更が行われたかどうか公然と文書化すべきで, そのような変更の詳細について文書化してもよいです.
  should publicly document if editorial changes changes have been made, and may document the details of such changes.
• 改訂された仕様書が作業部会の要求するものを全て処理したことを示すか, その要求するものが変更されたか延期されていることを説明しなければなりません.
  must show that the revised specification meets all Working Group requirements, or explain why the requirements have changed or been deferred,
• もし, 前回の段階以降に, その文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
• 他の部会との依存関係における変更があれば報告すべきです.
  should report any changes in dependencies with other groups.
• 作業部会が知っている実装についての情報を提供すべきです.
  should provide information about implementations known to the Working Group.

通常, ディレクターの承認が下りる前に, 要件が満たされていることを確かなものにする正式な審査の会議があります.

There is usually a formal review meeting to ensure the requirements have been met before Director's approval is given.

注意: 更新要求の承認は, 遷移要求の承認を得るのと比べて, 相当単純であることが期待されています.

Note: Update request approval is expected to be fairly simple compared to getting approval for a transition request.

事務局は, 改訂された仕様書の公開をW3Cの他の部会や一般社会に周知しなければなりません.

The Team must announce the publication of the revised specification to other W3C groups and the Public.

6.3.4.1. 合理化された発行承認
Streamlined Publication Approval

注意:これらの基準は, 故意に更新要求に対する一般的な要件より厳格にされています. このことは, あいまいさや専門家の判断の必要性を最小限とし, 自己評価を現実的なものにするためです.

Note: These criteria are intentionally stricter than the general requirements for an update request. This is in order to minimize ambiguities and the need for expert judgment, and to make self-evaluation practical.

議論の余地のない場合の発行手続きを合理化するために, 更新要求の承認は, 次の示す追加の基準が満たされているとき, 正式な審査無しに認められます.

In order to streamline the publication process in non-controversial cases, approval to an update request is automatically granted without formal review when the following additional criteria are fulfilled:

• その文書について作業部会の要求するものに何も変更があってはなりません.
  There must have been no changes to Working Group requirements about this document.
• それぞれのW3Cの対等な部会 [憲章]に対して, 対等な審査を行う部会が審査が必要ない状況での一通りの基準を認めているのであれば, 作業部会は, それらの基準が満たされていることを文書化しなければなりません. そうでなければ, 作業部会は, そららの部会からの審査を要求し受領しなければなりません.
  For each of the W3C Horizontal Groups [CHARTER], if the Horizontal Review Group has made available a set criteria under which their review is not necessary, the Working Group must document that these criteria have been fulfilled. Otherwise, the Working Group must show that review from that group has been solicited and received.
• 正式な異議が, 文書に対して何も示されていません.
  No Formal Objection has been registered against the document.
• 作業部会は, 次のことに正式に取り組まなければなりません.
  The Working Group must have formally addressed:

  • 前回の発行以降の変更によって生じた, 文書に対して挙げられた全ての課題

    all issues raised against the document that resulted in changes since the previous publication

  • 前回の発行以降の変更に対して挙げられた全ての課題

    all issues raised against changes since the previous publication

  • 前回の発行以降に, 何も変更無しにまとめられた文書に対して挙げられた全ての課題

    all issues raised against the document that were closed since the previous publication with no change to the document

  これらの各課題に対する回答は, その課題を挙げた人を満足するものでなければなりません. そららの提案が受け入れられるか, 折衷案が見つかけられるか, 提案を却下した作業部会の根拠を提案した人が受け入れるかです.

  The response to each of these issues must be to the satisfaction of the person who raised it: their proposal has been accepted, or a compromise has been found, or they accepted the Working Group’s rationale for rejecting it.

  注意:これらは, 一般的な遷移要求の基準より厳格です.

  Note: This is stricter than the general Transition Request criteria.

加えて, 実質的な変更または新しい機能を伴って勧告を更新する場合, 次の基準が満たされているときに, 認められます.

Additionally, for updates to Recommendations with substantive changes or with new features:

• 文書への変更が, 訂正案審査の最終要請に含まれている訂正案か, 場合によっては種類1または2の変更を組合わせたもの, または(新しい機能を認めている勧告の場合に)追加案審査の最終要請に含まれている追加案に限られていなければなりません.
  Changes to the document are limited to proposed corrections that were included in a Last Call for Review of Proposed Corrections possibly combined with class 1 or 2 changes, and/or (in the case of a Recommendation that allows new features) proposed additions that were included in a Last Call for Review of Proposed Additions.
• 作業部会は, 全ての変更が少なくとも2つの別個の実装者による2つの別個の製品で実装されていることを示さなければなりません. 変更を広範囲にわたって対応するテストツールによる試験を通ること, または, 作業部会憲章で述べられている代替の合理化され認められた実装要件を取り扱うことによって, 立証しなければなりません.
  The Working Group must show that all changes have been implemented in at least 2 distinct products by 2 different implementers, as evidenced by passing tests of a test suite providing extensive coverage of the changes, or an alternative streamlined approval implementation requirement described in the working Group charter has been met.

  注意:これらは一般的な十分な実装の実績の基準より厳格です.

  Note: This is stricter than the general criteria for adequate implementation experience.

作業部会は, これらの主張に対する文書化された証拠を提供しなければならず, 事務局は, その回答を公に永久に利用できるようにしねければなりません.

The Working Group must provide written evidence for these claims, and the Team must make these answers publicly and permanently available.

発行した後, ACの委員または事務局メンバーは, 示された証拠が主張に対応していることに疑義がある場合, 実際に後で正式な審査の会議が開かれることを要求してもよいです. 要件が満たされていることを, その審査が見つけたのであれば, 事務局は, 元に戻されたことを示す状態の節をきちんと更新することや, 技術報告書の以前に承認されたバージョンを再発行することによって, 変更を元に戻してもよいです.

After publication, if an AC Representative or Team member doubts that the evidence presented supports the claims, they may request that a formal review meeting be convened post facto. If that review finds that the requirements were not fulfilled, the Team may revert the changes by updating in place the status section to indicate that it has been reverted, and by republishing the previously approved version of the technical report.

6.3.5. 初期草案の発行
Publishing a First Public Working Draft

文書の初期草案を発行するために, 作業部会は, 適用できる進展の要件を満たさなければなりません.

To publish the First Public Working Draft of a document, a Working Group must meet the applicable requirements for advancement.

事務局は, 初期草案の発行をW3Cの他の部会や一般社会に周知しなければなりません.

The Team must announce the publication of a First Public Working Draft to other W3C groups and to the public.

6.3.6. 草案の改訂
Revising a Working Draft

作業部会は, 以前に発行された文書に, 作業部会を超えた審査によってより良いものとなる重大な変更があったとき, 草案をW3C技術報告書のページに発行すべきです.

A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

仕様書に重大な変更が無いまま6ヵ月経過した場合, 作業部会は, 状態の節に変更の無い理由を示した改訂された草案を発行すべきです.

If 6 months elapse without significant changes to a specification, a Working Group should publish a revised Working Draft, whose status section should indicate reasons for the lack of change.

草案の改訂版を発行するに当たって, 作業部会は次のとおりです.

To publish a revision of a Working draft, a Working Group:

• 発行を要求した部会決定を記録しなければなりません. これは手続き上の段階で, 合意は必須ではありません.
  must record the group’s decision to request publication. Consensus is not required, as this is a procedural step,
• 以前の草案以降の技術報告書に対する実質的な変更の公開の文書を提供しなければなりません.
  must provide public documentation of substantive changes to the technical report since the previous Working Draft,
• 前回の段階以降の技術報告書に対する重大な編集上の変更の公開の文書を提供すべきです.
  should provide public documentation of significant editorial changes to the technical report since the previous step,
• もし前回の段階以降に, その文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group’s requirements for this document have changed since the previous step,
• 他の部会との依存関係に変更があれば報告すべきです.
  should report any changes in dependencies with other groups,

可能性のある草案の次の段階は, 次のとおりです.

Possible next steps for any Working Draft:

• 改訂された草案
  Revised Working Draft
• 勧告候補
  Candidate Recommendation
• 中止草案
  Discontinued Draft

6.3.7. 勧告候補への遷移
Transitioning to Candidate Recommendation

勧告候補を発行するに当たって, 遷移の要件を処理することに加え, 作業部会は, 次のとおりです.

To publish a Candidate Recommendation, in addition to meeting the requirements for advancement a Working Group:

• 仕様書が作業部会の要件全てを処理していることを示すか, その要件が変更されているか延期されていることを説明しなければなりません.
  must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,
• 仕様書の開発の間に起こった依存関係への変更を文書化しなければなりません.
  must document changes to dependencies during the development of the specification,
• どのように十分な実装の実績を証明するか文書化しなければなりません.
  must document how adequate implementation experience will be demonstrated,
• 意見の締切を指定しなければなりません. 締切は, 少なくとも発行後28日間空けなければならず, 複雑な文書ではもっと長く空けるべきです.
  must specify the deadline for comments, which must be at least 28 days after publication, and should be longer for complex documents,
• 仕様書が広範囲にわたる審査を受けたことを示さなければなりません.
  must show that the specification has received wide review, and
• 文書の中で潜在的な問題をはらんでいる機能を特定してもよいです. それらの機能は, 勧告案に進展する際に, 新しい勧告候補を発行する必要無しに削除されてもよいです.
  may identify features in the document as at risk. These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

遷移要求の承認後の最初の勧告候補は, 常に勧告候補全体版です. 事務局は, 勧告候補全体版の発行をW3Cの他の部会や一般社会に周知しなければなりません.

The first Candidate Recommendation publication after approval of a Transition Request is always a Candidate Recommendation Snapshot. The Team must announce the publication of the Candidate Recommendation Snapshot to other W3C groups and to the public.

可能性のある勧告候補全体版の次の段階は, 次のとおりです.

Possible next steps after a Candidate Recommendation Snapshot:

• 草案への差戻し
  Return to Working Draft
• 改訂された勧告候補全体版
  A revised Candidate Recommendation Snapshot
• 改訂された勧告候補草案版
  A revised Candidate Recommendation Draft
• 勧告案
  Proposed Recommendation
• 中止草案
  Discontinued Draft

諮問委員会の委員は, 技術報告書の進展の決定に対し, 諮問委員会の抗議を提出してもよいです.

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

6.3.8. 勧告候補の改訂
Revising a Candidate Recommendation

6.3.8.1. 勧告候補全体版の発行
Publishing a Candidate Recommendation Snapshot

以前の勧告候補全体版から, 潜在的な問題をはらんでいるとはっきり示された機能を削除する以外の, 勧告候補への何か実質的な変更があった場合, 作業部会は, 再発行するために更新要求の要件を満たさなければなりません.

If there are any substantive changes made to a Candidate Recommendation since the previous Candidate Recommendation Snapshot other than to remove features explicitly identified as at risk, the Working Group must meet the requirements of an update request in order to republish.

加えて, 作業部会は次のとおりです.

In addition the Working Group:

• 意見の締切を指定なければなりません. 締切は, 少なくとも発行後28日間空けなければならず, 複雑な文書ではもっと長く空けるべきです.
  must specify the deadline for further comments, which must be at least 28 days after publication, and should be longer for complex documents,
• 文書の中で潜在的な問題をはらんでいる機能を特定してもよいです. それらの機能は, 勧告案に進展する際に, 新しい勧告候補を発行する必要無しに削除されてもよいです.
  may identify features in the document as at risk. These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

事務局は, 改訂された勧告候補全体版の発行をW3Cの他の部会や一般社会に周知しなければなりません.

The Team must announce the publication of a revised Candidate Recommendation Snapshot to other W3C groups and to the public.

素早い更新と特許の保護を提供するために, 勧告候補全体版は, 作業部会が実質的な変更に対する提案を受けてから24ヵ月以内に(できる限り早く)発行されるべきです. 審査の計画を簡単にするために, 勧告候補全体版は, おおよそ6ヵ月に1回より多い頻度で発行されるべきではありません.

To provide timely updates and patent protection, a Candidate Recommendation Snapshot should be published within 24 months of the Working Group accepting any proposal for a substantive change (and preferably sooner). To make scheduling reviews easier, a Candidate Recommendation Snapshot should not be published more often than approximately once every 6 months.

注意: 実質的な変更 は, W3C特許指針[特許指針]の“W3C RFライセンス要件からの除外”を通して, 新しい除外機会のきっかけとなります.

Note: Substantive changes trigger a new Exclusion Opportunity per “Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY].

6.3.8.2. 勧告候補草案版の発行
Publishing a Candidate Recommendation Draft

作業部会は, 以前に発行された文書に, 作業部会を超えた審査によってより良いものとなる重大な変更があったとき, 更新された勧告候補草案版をW3C技術報告書のページに発行すべきです.

A Working Group should publish an Update Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

勧告候補草案版の改訂版を発行するに当たって, 作業部会は次のとおりです.

To publish a revision of a Candidate Recommendation Draft, a Working Group:

• 発行を要求した部会決定を記録しなければなりません.
  must record the group’s decision to request publication,
• 以前の勧告候補全体版以降の技術報告書に対する実質的な変更の公開の文書を提供しなければなりません.
  must provide public documentation of substantive changes to the technical report since the previous Candidate Recommendation Snapshot,
• 以前の勧告候補全体版以降の技術報告書に対する重大な編集上の変更の公開の文書を提供すべきです.
  should provide public documentation of significant editorial changes to the technical report since the previous Candidate Recommendation Snapshot,
• 目立った課題や, 作業部会で合意を得られていない文書の部分を明文化すべきです.
  should document outstanding issues, and parts of the document on which the Working Group does not have consensus,
• もし前回の段階以降に, その文書に対する作業部会の要求するもので変わったものがあるのならば, その内容を報告すべきです.
  should report which, if any, of the Working Group’s requirements for this document have changed since the previous step,
• 他の部会との依存関係に変更があれば報告すべきです.
  should report any changes in dependencies with other groups.

注意:作業部会は, 勧告候補草案版を発行するために, 勧告候補全体版の更新要求の要件を満たす必要はありません.

Note: A Working Group does not need to meet the requirements of a Candidate Recommendation Snapshot update request in order to publish a Candidate Recommendation Draft.

可能性のある勧告候補草案版の次の段階は, 次のとおりです.

Possible next steps after a Candidate Recommendation Draft:

• 草案への差戻し
  Return to Working Draft
• 改訂された勧告候補全体版
  A revised Candidate Recommendation Snapshot
• 改訂された勧告候補草案版
  A revised Candidate Recommendation Draft
• 潜在的な問題をはらんでいる機能を落とすこと以外の実質的な変更が何も無いのであれば, 勧告案
  Proposed Recommendation, if there are no substantive change other than dropping at risk features
• 中止草案
  Discontinued Draft

6.3.9. 勧告案への遷移
Transitioning to Proposed Recommendation

進展の要件を満たすことに加えて, 次のとおりです.

In addition to meeting the requirements for advancement,

• 状態の情報は, 諮問委員会の審査の締切を指定しなければなりません. 締切は, 勧告案の発行後少なくとも28日間空けなければならず, W3C特許指針[特許指針]の”W3C RFライセンス要件からの除外”を通して, 最後の除外機会の終了から少なくとも10日間空けるべきです.
  The status information must specify the deadline for Advisory Committee review, which must be at least 28 days after the publication of the Proposed Recommendation and should be at least 10 days after the end of the last Exclusion Opportunity per ”Exclusion From W3C RF Licensing Requirements” in the W3C Patent Policy [PATENT-POLICY].

作業部会は, 次のとおりです.

A Working Group:

• ディレクターによって認められた例外を除いて, 十分な実装の実績を示さなければなりません.
  must show adequate implementation experience except where an exception is approved by the Director,
• 文書が広範囲にわたる審査を受けたことを示さなければなりません.
  must show that the document has received wide review,
• 正式な諮問委員会の委員の役割を担っているACの委員からのもの以外の, 勧告候補の審査期間に挙げられた全ての課題が, 正式に取り組まれていたことを示さなければなりません.
  must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed,
• 勧告候補の審査期間が終わった後に挙げられた実質的な課題を特定しなければなりません.
  must identify any substantive issues raised since the close of the Candidate Recommendation review period,
• 潜在的な問題をはらんでいるとされた機能を落とす以外の, 最も直近の勧告候補全体版以降の, 文書に対する何か実質的な変更を行ってはなりません.
  must not have made any substantive changes to the document since the most recent Candidate Recommendation Snapshot, other than dropping features identified at risk.
• 仕様書を勧告候補全体版として再発行することなく, 勧告候補全体版の文書の中で潜在的な問題をはらんでいると特定された機能を削除してもよいです.
  may have removed features identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification as a Candidate Recommendation Snapshot.

ディレクターは, 次のとおりです.

The Director:

• 勧告案の発行を諮問委員会に周知しなければなりません. また, 仕様書がW3C勧告として発行するのにふさわしいかどうかの問いについての諮問委員会の審査を始めなければなりません.
  must announce the publication of a Proposed Recommendation to the Advisory Committee, and must begin an Advisory Committee Review on the question of whether the specification is appropriate to publish as a W3C Recommendation.
• 無理やり承認する理由があるのであれば, 勧告案を最小限の実装の実績で承認してもよいです. そのような場合, ディレクターは, その決定の理由を説明すべきです.
  may approve a Proposed Recommendation with minimal implementation experience where there is a compelling reason to do so. In such a case, the Director should explain the reasons for that decision.

W3C勧告は, 元となった勧告案から何か実質的な変更を含んではならないことから, 勧告案に何か実質的な変更を行うために, 作業部会は, 仕様書を勧告候補または草案に戻さなければなりません.

Since a W3C Recommendation must not include any substantive changes from the Proposed Recommendation it is based on, to make any substantive change to a Proposed Recommendation the Working Group must return the specification to Candidate Recommendation or Working Draft.

勧告案は, § 6.3.11.4 勧告の改訂:新しい機能で述べられているように, 勧告として最初に発行した後に(種類4の変更に当たる)新しい機能を認めることを示しているものとして自身を特定してもよいです. そのような承認は, そのような変更を認めていない勧告を発行する前に, 技術報告書に加えることはできません.

A Proposed Recommendation may identify itself as intending to allow new features (class 4 changes) after its initial publication as a Recommendation, as described in § 6.3.11.4 Revising a Recommendation: New Features. Such an allowance cannot be added to a technical report previously published as a Recommendation that did not allow such changes.

可能性のある次の段階は次のとおりです.

Possible Next Steps:

• 草案への差戻し
  Return to Working Draft
• 勧告候補への差戻し
  Return to Candidate Recommendation
• 勧告の状態, (期待される次の段階)
  Recommendation status, (the expected next step).
• 中止草案
  Discontinued Draft

諮問委員会の委員は, 技術報告書を進展させる決定に対して, 諮問委員会の抗議を提出してもよいです.

Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to advance the technical report.

6.3.10. W3C勧告への遷移
Transitioning to W3C Recommendation

文書を勧告に進展させることは, W3C決定です.

The decision to advance a document to Recommendation is a W3C Decision.

進展の要件を満たすことに加えて, 次のとおりです.

In addition to meeting the requirements for advancement,

• 勧告は, どこで正誤表が記録されているか特定しなければなりません.
  A Recommendation must identify where errata are tracked, and
• 勧告は元となった勧告案から何か実質的な変更を含んではなりません.
  A Recommendation must not include any substantive changes from the Proposed Recommendation on which it is based.
• 諮問委員会の審査で何らかの異議があったなら, ディレクターは, 異議の実質的な中身を, W3Cや一般社会に公表しなければならず, W3C勧告として発行する14日前までにその意見を正式に処理しなければなりません.
  If there was any dissent in Advisory Committee reviews, the Director must publish the substantive content of the dissent to W3C and the general public, and must formally address the comment at least 14 days before publication as a W3C Recommendation.
• 諮問委員会の委員は, W3C決定に対して, 諮問委員会の抗議を提出してもよいです.
  Advisory Committee representatives may initiate an Advisory Committee Appeal of the W3C decision
• 事務局は, W3C勧告の発行を, 諮問委員会, W3Cの他の部会, 一般社会に周知しなければなりません.
  The Team must announce the publication of a W3C Recommendation to Advisory Committee, other W3C groups and to the public.

可能性のある次の段階について, W3C勧告はその状態を無期限に保持しますが, 次のようになってもよいです.

Possible next steps: A W3C Recommendation normally retains its status indefinitely. However it may be:

• 改訂勧告として再発行される.
  republished as a revised Recommendation, or
• 改訂勧告に向けて開発される勧告候補として再発行される.
  republished as a Candidate Recommendation to be developed towards a revised Recommendation, or
• 置換済または旧式と宣言される.
  declared superseded or obsolete, or
• 廃止される.
  rescinded.

6.3.11. W3C勧告の改訂
Revising a W3C Recommendation

この節は, 勧告に変更を加えるための手続きについて詳細に述べています.

This section details the process for making changes to a Recommendation.

6.3.11.1. 勧告の改訂:マークアップの変更
Revising a Recommendation: Markup Changes

仕様書の文章に何も変更を与えない結果となる訂正を行うのに, 作業部会は , 勧告の再発行を要求してもよいです. (種類1の変更を参照して下さい.)

A Working group may request republication of a Recommendation to make corrections that do not result in any changes to the text of the specification. (See class 1 changes.)

どの作業部会も勧告を維持管理するよう憲章に書いていない場合は, そのような変更を組み入れた勧告を事務局が再発行してもよいです.

If there is no Working Group chartered to maintain a Recommendation, the Team may republish the Recommendation with such changes incorporated.

6.3.11.2. 勧告の改訂:編集上の変更
Revising a Recommendation: Editorial Changes

勧告に対する編集上の変更は, 示された変更の技術的な審査を何も必要としていません. 作業部会は, 発行する決定に当たって何も投票をしていなければ, これらの変更を行うために低い段階の成熟レベルを通すことなく, 勧告の発行を要求してもよいです. (種類2の変更を参照して下さい.)

Editorial changes to a Recommendation require no technical review of the intended changes. A Working Group, provided there are no votes against the decision to publish, may request publication of a Recommendation to make this class of change without passing through earlier maturity levels. (See class 2 changes.)

どの作業部会も勧告を維持管理することを憲章に書いていない場合は, 事務局が, 正誤表や事務局訂正を含むそれらの変更を組み入れた勧告を再発行してもよいです.

If there is no Working Group chartered to maintain a Recommendation, the Team may republish the Recommendation with such changes incorporated, including errata and Team corrections.

6.3.11.3. 勧告の改訂:実質的な変更
Revising a Recommendation: Substantive Changes

訂正候補は, 改正候補が技術上かつ編集上十分なことを確かなものにするために, 関係者の審査を含め, 勧告の残りの部分と同じ基準を1度全て満足したのならば, 標準にすることができ, 勧告の主要な文章に織り交ぜることができます. その訂正が有効か確認するために, 作業部会は, 更新要求に従って改正案審査の最終要請を要求しなければなりません. § 6.3.11.5 改正候補の組み入れを参照して下さい.

A candidate correction can be made normative and be folded into the main text of the Recommendation, once it has satisfied all the same criteria as the rest of the Recommendation, including review by the community to ensure the technical and editorial soundness of the candidate amendments. To validate this, the Working Group must request a Last Call for Review of Proposed Amendments, followed by an update request. See § 6.3.11.5 Incorporating Candidate Amendments.

代わりに, 作業部会は, その変更を組み入れ, 勧告候補を発行し, その状態から仕様書を進展させてもよいです. (種類3の変更を参照して下さい.)

Alternatively, a Working Group may incorporate the changes and publish as a Candidate Recommendation, and advance the specification from that state. (See class 3 changes.)

注意:どの作業部会も勧告を維持管理することを憲章に書いていない場合は, 事務局は, 実質的な変更を行ったり, 勧告を再発行できません. ただし, 事務局は, 正誤表や訂正候補を用いて, 課題や望ましい変更を有益なように強調したり, 前の節で述べたように再発行できます.

Note: If there is no Working Group chartered to maintain a Recommendation the Team cannot make substantive changes and republish the Recommendation. It can, however, informatively highlight problems and desirable changes using errata and candidate corrections and republish as described in the previous section.

6.3.11.4. 勧告の改訂:新しい機能
Revising a Recommendation: New Features

新しい機能(種類4の変更参照)は, 追加候補を用いて新しい機能を認めているとはっきり指定されている勧告に組み込まれてもよいです. 追加候補は, § 6.3.11.3 勧告の改訂:実質的な変更で述べられている改正候補に対するものと同じ手続きを用いて, 標準にすることができ, 勧告の主要な文章に織り交ぜることができます.

New features (see class 4 changes) may be incorporated into a Recommendation explicitly identified as allowing new features using candidate additions. A candidate addition can be made normative and be folded into the main text of the Recommendation using the same process as for candidate amendments, as detailed in § 6.3.11.3 Revising a Recommendation: Substantive Changes.

注意:この新しい機能の禁止は, はっきり認められていない限り, この手続き文書の2020改訂版を優先することで, 第3者が安定した機能群を持つ勧告に依存することを可能にします.

Note: This prohibition against new features unless explicitly allowed enables third parties to depend on Recommendations having a stable feature-set, as they have prior to the 2020 revision of this Process.

新しい機能を受け入れるために進展されなかった勧告に, 新しい機能を導入する変更を行うために, W3Cは, 新しい初期草案から始まる技術報告書を勧告に進展させる手続きに従って, 新しい技術報告書を作らなければなりません.

To make changes which introduce a new feature to a Recommendation that was not approved for accepting new features, W3C must create a new technical report, following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

6.3.11.5. 改正候補の組み入れ
Incorporating Candidate Amendments

改正案審査の最終要請は, AC審査と特許除外機会を組合せることで, 改正候補のW3C関係者による承諾を確認します.

A Last Call for Review of Proposed Amendments verifies acceptance by the W3C community of candidate amendments by combining an AC Review with a patent exclusion opportunity.

改正案審査の最終要請は, W3Cの他の部会, 一般社会, 諮問委員会に周知しなければなりません. 周知は, 次のとおりでなければなりません.

The Last Call for Review of Proposed Amendments must be announced to other W3C groups, the public, and the Advisory Committee. The announcement must:

• 訂正案審査の最終要請, 追加案審査の最終要請, 訂正案審査および追加案審査の最終要請のいずれであるか特定しなければなりません.
  Identify whether this is a Last Call for Review of Proposed Corrections, Last Call for Review of Proposed Additions, or Last Call for Review of Proposed Corrections and Additions.
• 改正案(訂正案/追加案)としての審査の下で, 改正候補を特定しなければなりません.
  Identify the specific candidate amendments under review as proposed amendments (proposed corrections/proposed additions).
• 審査意見の締切を指定しなければなりません. 締切は, 審査の要請から60日以上空けなければなりません.
  Specify the deadline for review comments, which must not be any sooner than 60 days from the Call for Review.
• 審査と, まだなのであれば実装の実績を要求しなければなりません.
  Solicit review and, if it does not already have it, implementation experience.

既存の勧告と改正案審査の最終要請に含まれた改正案を組合せたものは, 特許指針[特許指針]の意図する特許審査草案と見なされます. また, 改正案審査の最終要請によって発議された審査は, 諮問委員会の審査です.

The combination of the existing Recommendation with the proposed amendments included in the Last Call for Review of Proposed Amendments is considered a Patent Review Draft for the purposes of the Patent Policy [PATENT-POLICY]. Also, the review initiated by the Last Call for Review of Proposed Amendments is an Advisory Committee Review.

注意: 追加案審査の最終要請ならびに訂正案審査および追加案審査の最終要請は, 新しい機能を認めている勧告にのみ発せられます.

Note: Last Call for Review of Proposed Additions and Last Call for Review of Proposed Corrections and Additions can only be issued for Recommendations that allow new features.

作業部会は, 複数の改正案を単独の改正案審査の最終要請にまとめて処理してもよいです. 審査を促すため, 与えられた仕様書における改正案審査の最終要請は, おおよそ6ヵ月に1回より多い頻度で発せられるべきではありません.

A Working Group may batch multiple proposed amendments into a single Last Call for Review of Proposed Amendments. To facilitate review, a Last Call for Review of Proposed Amendments on a given specification should not be issued more frequently than approximately once every 6 months.

改正案審査の最終要請の最後に, W3C決定は, 改正案を却下するか, 進展のために改正案を取り除くか, 審査の下で変更に寄せられた意見を正式に取り組む要求と一緒に提案を作業部会に戻すかのいずれかでしょう. 作業部会が審査の反応に対する回答の中で改正案を改正する必要があるのならば, 作業部会は, 変更が主要な文章に組み入れられる前に, 他の改訂された変更に対する改正案審査の最終要請を発しなければなりません.

At the end of the Last Call for Review of Proposed Amendments, the W3C Decision may either be to reject the proposed amendment, or to clear the proposed amendment for advancement as is, or to return the proposal to the Working Group with a request to formally address comments made on the changes under review. If the Working Group needs to amend a proposed amendment in response to review feedback it must issue another Last Call for Review of Proposed Amendments on the revised change before it can be incorporated into the main text.

改正案における全ての意見が正式に取り組まれている限り, 作業部会が十分な実装の実績と他の全ての勧告文書の要件の実現を示した後, 作業部会は, 更新された勧告の発行に対する更新要求を発することで, 改正案を標準である勧告に組み入れてもよいです.

Once all comments on a proposed amendment have been formally addressed, and after the Working Group can show adequate implementation experience and the fulfillment of all other requirements of Recommendation text, it may incorporate the proposed amendment into the normative Recommendation by issuing an update request for publication of the updated Recommendation.

改正案を組合せることに対する十分な審査を確かなものにするために, 最も直近の改正案審査の最終要請に含まれている改正案のみが, 標準の勧告の文章に組み入れられます. (よって, 改正案の組み入れが延期された場合, その変更は, 複数の改正案審査の最終要請に含まれる必要があるでしょう.)

To ensure adequate review of proposed amendment combinations, only proposed amendments included in the most recent Last Call for Review of Proposed Amendments can be incorporated into the normative Recommendation text. (Thus if incorporation of a proposed amendment is postponed, it may need to be included in multiple Last Calls for Review of Proposed Amendments.)

6.3.12. 勧告工程の文書の断念
Retiring Recommendation Track Documents

技術報告書の作業は, いつでも辞めてもよいです. 作業は, W3Cまたは作業部会がそれ以上に作業を生産的に進めることができないと判断した場合に辞めるべきです.

Work on a technical report may cease at any time. Work should cease if W3C or a Working Group determines that it cannot productively carry the work any further.

6.3.12.1. 完了していない勧告の断念
Abandoning an Unfinished Recommendation

何らかの勧告工程にある技術報告書が, もはや進展されたり維持管理されたりすることを意図されておらず, 廃止もされていないのなら, 前回の発行と比べて何も実質的な変更無しに, 中止草案として発行されるべきです. このことは, 作業部会がその報告書の作業を断念することを決めた場合, または, ディレクターが, 完了する前にその技術報告書の作業を作業部会に中止するよう要求した場合に起こります. 作業部会が終了することになった場合, W3Cは, 勧告工程にあるどの完了していない技術報告書も中止草案として再発行しなければなりません.

Any Recommendation-track technical report no longer intended to advance or to be maintained, and that is not being rescinded, should be published as a Discontinued Draft, with no substantive change compared to the previous publication. This can happen if the Working Group decided to abandon work on the report, or the Director required the Working Group to discontinue work on the technical report before completion. If a Working Group is made to close, W3C must re-publish any unfinished technical report on the Recommendation track as Discontinued Draft.

そのような文書は, どうして中止されたかについての説明を, 位置付けの節に含むべきです.

Such a document should include in its status section an explanation of why it was discontinued.

作業部会は, いつでも憲章の範囲内で草案として再発行することで, そのような技術報告書の作業を再開してもよいです.

A Working Group may resume work on such a technical report within the scope of its charter at any time, by re-publishing it as a Working Draft.

6.3.12.2. 勧告候補の廃止
Rescinding a Candidate Recommendation

勧告候補を廃止する手続きは, 勧告を廃止する場合と一緒です.

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

6.3.12.3. W3C勧告の断念
Abandoning a W3C Recommendation

W3Cが, 特定の勧告を実装することがもはや推奨されないと決めることは可能です. そのような仕様書に対し, W3Cがその仕様書の更なる利用について与えようとしている助言に応じて選ばれた, 3つの状態があります.

It is possible that W3C decides that implementing a particular Recommendation is no longer recommended. There are three designations for such specifications, chosen depending on the advice W3C wishes to give about further use of the specification.

例えば, W3C関係者が, その勧告がもはや最適な慣行を表していないか, 採用されていないうえに明らかに採用されそうにないと決めた場合, W3Cは, 勧告を旧式としてもよいです. 旧式勧告は, 例えば, 旧式とされたにも関わらず, 後で仕様書がより幅広く採用された場合, 通常の勧告に復活させてもよいです.

W3C may obsolete a Recommendation, for example if the W3C Community decides that the Recommendation no longer represents best practices, or is not adopted and is not apparently likely to be adopted. An Obsolete Recommendation may be restored to normal Recommendation, for example because despite marking it Obsolete the specification is later more broadly adopted.

W3Cが新たに採用するよう推奨する新しいバージョンが存在する場合, W3Cは勧告が置換済であると宣言してもよいです. 勧告が置換済であると宣言する手続きは, 後で示す勧告が旧式と宣言する手続きと一緒です.

W3C may declare a Recommendation Superseded if a newer version exists which W3C recommends for new adoption. The process for declaring a Recommendation Superseded is the same as for declaring it Obsolete, below; only the name and explanation change.

例えば, 実装者に影響し, 解決できない厄介な特許の主張のために, W3Cが復活させる筋の通った見込みが何もないと考える場合, W3Cは勧告を廃止してもよいです. W3C特許指針[特許指針], 特に“W3Cロイヤリティフリー(RF)ライセンス要件”と“PAG決定”を参照して下さい.

W3C may rescind a Recommendation if W3C believes there is no reasonable prospect of it being restored for example due to burdensome patent claims that affect implementers and cannot be resolved; see the W3C Patent Policy [PATENT-POLICY] and in particular “W3C Royalty-Free (RF) Licensing Requirements” and “PAG Conclusion”.

W3Cは, 勧告全体をまとめて廃止したり, 置換済にしたり, 旧式としたりします. 勧告は, 置換済にされ, 同時に旧式とされることがあります. 勧告の一部を廃止したり, 置換済にしたり, 旧式としたりするには, W3Cは勧告を修正する手続きに従います.

W3C only rescinds, supersedes, or obsoletes entire Recommendations. A Recommendation can be both superseded and obsolete. To rescind, supersede, or obsolete some part of a Recommendation, W3C follows the process for modifying a Recommendation.

注意:W3C特許指針[特許指針]の意図することろでは, 旧式勧告または置換済勧告は, 将来の実装が推奨されないにも関わらず, 有効な勧告の状態を持ちます. 廃止勧告は有効ではなくなり, 何も新しいライセンスは, 特許指針の下で認められません.

Note: For the purposes of the W3C Patent Policy [PATENT-POLICY] an Obsolete or Superseded Recommendation has the status of an active Recommendation, although it is not recommended for future implementation; a Rescinded Recommendation ceases to be in effect and no new licenses are granted under the Patent Policy.

6.3.12.4. 勧告の廃止, 旧式化, 置換, 復活の手続き
Process for Rescinding, Obsoleting, Superseding, Restoring a Recommendation

勧告を廃止したり, 旧式としたり, 置換済としたり, 復活させたりする手続きは, ディレクターからの要求によってか, または次のいずれかからの要求を通して発議されます.

The process of rescinding, obsoleting, superseding, or restoring a Recommendation can be initiated either by a request from the Director or via a request from any of the following:

• 勧告を生み出したか, 維持管理すると憲章に書いている作業部会
  The Working Group who produced, or is chartered to maintain, the Recommendation
• そのような作業部会が無い場合, TAG
  The TAG, if there is no such Working Group
• 上で述べた関連する作業部会に, またはそのような作業部会が存在しな場合はTAGに, 勧告を旧式としたり, 廃止したり, 置換済としたり, 復活させたりする要求を行った, 90日以内に回答を得られなかった個人
  Any individual who made a request to the relevant Working Group as described above, or the TAG if such a group does not exist, to obsolete, rescind, supersede, or restore a Recommendation, where the request was not answered within 90 days
• 諮問委員会のメンバーの5%
  5% of the members of the Advisory Committee

その後, 事務局は, 諮問委員会に審査の要求を提出しなければなりません. 勧告を廃止したり, 旧式としたり, 置換済としたり, 復活させたりする提案への何らかの諮問委員会の審査に対して, ディレクターは, 次のとおりしなければなりません.

The Team must then submit the request to the Advisory Committee for review. For any Advisory Committee review of a proposal to rescind, obsolete, supersede, or restore a Recommendation the Director must:

• 提案を全ての作業部会の議長, 一般社会, 諮問委員会に周知しなければなりません.
  announce the proposal to all Working Group Chairs, and to the Public, as well as to the Advisory Committee
• 提案が, 勧告を廃止したり, 旧式としたり, 置換済にしたり, 復活させたりするものであることを適切に示さなければなりません.
  indicate that this is a proposal to Rescind, Obsolete, Supersede, or restore, a Recommendation as appropriate
• URLによって勧告を特定しなければなりません.
  identify the Recommendation by URL
• 提案の根拠を公開しなければなりません.
  publish a rationale for the proposal
• 分かっている依存関係を特定し, 全ての依存している作業部会に審査を要求しなければなりません.
  identify known dependencies and solicit review from all dependent Working Groups
• 一般社会の審査を要求しなければなりません.
  solicit public review
• 審査意見の締切を指定しなければなりません. 締切は, 周知から少なくとも28日後でなければなりません.
  specify the deadline for review comments, which must be at least 28 days after the announcement

また, 次のとおりすべきです.

and should

• 分かっている実装を特定すべきです.
  identify known implementations.

諮問委員会の審査において何らかの不同意があった場合, ディレクターは, 不同意の実質的な意見をW3Cと一般社会に公表しなければならず, 旧式勧告または廃止勧告として遅くとも14日前までに不同意に正式に取り組まなければなりません.

If there was any dissent in the Advisory Committee review, the Director must publish the substantive content of the dissent to W3C and the public, and must formally address the dissent at least 14 days before publication as an Obsolete or Rescinded Recommendation.

諮問委員会は, ディレクターの決定に諮問委員会の抗議を提出してもよいです.

The Advisory Committee may initiate an Advisory Committee Appeal of the Director's decision.

W3Cは, 旧式勧告または廃止勧告を最新の状態と一緒に発行しなければなりません. 更新版は, 文書の主要部分を取り除いてもよいです. その文書の状態の節は, W3C仕様書の旧式化と廃止 [旧式-廃止]の説明を適切にリンクすべきです.

W3C must publish an Obsolete or Rescinded Recommendation with up to date status. The updated version may remove the main body of the document. The Status of this Document section should link to the explanation of Obsoleting and Rescinding W3C Specifications [OBS-RESC] as appropriate.

一度W3Cが廃止勧告を発行すると, 将来のW3C技術報告書は, その技術報告書を標準の参考文献として含むことはできません.

Once W3C has published a Rescinded Recommendation, future W3C technical reports must not include normative references to that technical report.

注意: W3Cは, 全ての技術報告書がそれら自身のバージョン特有のURLで利用可能であり続けることを, 確かなものにしようと努力します.

Note: W3C strives to ensure that all Technical Reports will continue to be available at their version-specific URL.

6.4. メモ工程(メモと声明)
The Note Track (Notes and Statements)

6.4.1. 部会メモ
Group Notes

部会メモ(メモ)は, 正式な標準となることを意図していない, 役に立つ文書の安定した参照を提供するために発行されます.

A Group Note (NOTE) is published to provide a stable reference for a useful document that is not intended to be a formal standard.

作業部会, 関連部会, TAG, ABは, メモとして作業を公表してもよいです. 例えば次のものを含みます.

Working Groups, Interest Groups, the TAG and the AB may publish work as Notes. Examples include:

• 設計原理または利用事例と要件の説明といった, 仕様書を支援する文書.
  supporting documentation for a specification, such as explanations of design principles or use cases and requirements
• 良い慣行についての標準でない手引き.
  non-normative guides to good practices

メモの中には, ほとんどのものは直接メモとして発行される一方で, 完全なメモとして発行される前に, 連続する草案メモを通して開発されるものもあります. 文書をメモまたは草案メモとして発行する若干の正当な要件があり, それらの文書は, W3Cの勧告の状態ではなく, 履歴の参照のために単に保存される文書です.

Some Notes are developed through successive Draft Notes before publication as a full Notes, while others are published directly as a Note. There are few formal requirements to publish a document as a Note or Draft Note, and they have no standing as a recommendation of W3C but are simply documents preserved for historical reference.

注意:W3C特許指針[特許指針]は, メモまたは草案メモに対して, 何らかのライセンス要件や義務は指定しません.

Note: The W3C Patent Policy [PATENT-POLICY] does not apply any licensing requirements or commitments for Notes or Draft Notes.

6.4.2. メモの発行
Publishing Notes

メモまたは草案メモを発行するに当たって, 部会は次のとおりです.

In order to publish a Note or Draft Note, the group:

• メモまたは草案メモとして発行を要求した部会決定を記録しなければなりません.
  must record their decision to request publication as a Note or Draft Note, and
• 何らかの以前の発行以降の, 技術報告書への重大な変更を文書化したものを公表すべきです.
  should publish documentation of significant changes to the technical report since any previous publication.

メモと 草案メモの両方は, メモまたは草案メモとして再発行することで更新できます. 技術報告書は, 永続的にメモのままでもよいです.

Both Notes and Draft Notes can be updated by republishing as a Note or Draft Note. A technical report may remain a Note indefinitely.

憲章を持つ部会によって生み出されたメモがもはやどの部会の範囲でもない場合, 事務局は, 種類1の変更を組み入れたメモや 付加された正誤表や事務局訂正を再発行してもよいです.

If a Note produced by a chartered group is no longer in scope for any group, the Team may republish the Note with class 1 changes incorporated, as well as with errata and Team corrections annotated.

6.4.3. 部会メモのW3C声明への昇進
Elevating Group Notes to W3C Statement status

W3C声明は, W3C全体から支持されているメモです. メモをW3C声明の状態に昇進させるには, 部会は, 次のとおりしなければなりません.

A W3C Statement is a Note that has been endorsed by W3C as a whole. In order to elevate a Note to W3C Statement status, A group must:

• 文書が広範囲にわたる審査を受けたことを示さなければなりません.
  show that the document has received wide review.
• W3C声明として発行を要求した部会決定を記録しなければなりません.
  record the group’s decision to request publication as a W3C Statement.
• メモとして最小に発行して以降, 文書に対して挙げられた全ての課題が正式に取り組まれていたことを示さなければなりません.
  show that all issues raised against the document since its first publication as a Note have been formally addressed.
• どの正式な異議の公開の文書も提供しなければなりません.
  provide public documentation of any Formal Objections.

実装可能な技術を指定しているメモは, W3C声明の状態に昇進させるべきではありません. 昇進させる場合, 声明として発行する要求は, なぜ昇進させるべきなのか, そして, なぜ勧告工程でないのか根拠を含まなければなりません.

A Note specifying implementable technology should not be elevated to W3C Statement status; if it does, the request to publish as a Statement must include rationale for why it should be elevated, and why it is not on the Recommendation track.

一度, これらの条件を満たしたのなら, 事務局は, その文書がW3C声明として発行することが適切かどうかを問う諮問委員会の審査を始めなければなりません. 審査の期間中, そのメモは更新されてはなりません.

Once these conditions are fulfilled, the Team must then begin an Advisory Committee Review on the question of whether the document is appropriate to publish as a W3C Statement. During this review period, the Note must not be updated.

文書をW3C声明に進展させる決定は, W3C決定です. 諮問委員会の委員は, 決定に対して諮問委員会の抗議を提出してもよいです.

The decision to advance a document to W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

事務局は, W3C声明の発行を, 諮問委員会, W3Cの他の部会, 一般社会に周知しなければなりません.

The Team must announce the publication of a W3C Statement to the Advisory Committee, other W3C groups, and the public.

6.4.4. W3C声明の改訂
Revising W3C Statements

改正候補を含め, 編集上の変更と一緒にW3C声明の発行を要求することは, 記録された部会決定が行われたなら, 何らかの手続き無しに可能です.

Given a recorded group decision to do so, groups can request publication of a W3C Statement with editorial changes—including candidate amendment—without any additional process.

改正候補は, 改正候補の実施的な堅実性および編集上の堅実性を確かなものにするための関係者の審査を含め, 声明の残りの部分と同じ基準を1度全て満足したのならば, W3C声明の主要な文章に織り交ぜることができます. その改正が有効か確認するために, 部会は, 組み込まれようとしてる変更の諮問委員会の審査を要求しなければなりません. 審査下の指定された改正候補は, 訂正案の審査の最終要請の中で, 簡単に改正案として特定されなければなりません.

A candidate amendment can be folded into the main text of the W3C Statement, once it has satisfied all the same criteria as the rest of the Statement, including review by the community to ensure the substantive and editorial soundness of the candidate amendments. To validate this, the group must request an Advisory Committee review of the changes it wishes to incorporate. The specific candidate amendments under review must be identified as proposed amendments just as in a Last Call for Review of Proposed Corrections.

改正案をW3C声明に組み入れる決定は, W3C決定です. 諮問委員会の委員は, 決定に対して諮問委員会の抗議を提出してもよいです.

The decision to incorporate proposed amendments into W3C Statement is a W3C Decision. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision.

6.5. データ一覧工程
The Registry Track

データ一覧文書は, 1つ以上の関連付けられたデータ一覧表から構成される一連のデータで, 各表は, 論理的で独立した, 一貫した構造のデータ一覧登録データを更新可能な一覧にまとめたものを表します. データ一覧は, 3つの関連付けられた部分を持ちます.

A registry documents a data set consisting of one or more associated registry tables, each table representing an updatable collection of logically independent, consistently-structured registry entries. A registry has three associated components:

• どのようにデータ一覧表が構成され維持管理されるかを定義した, データ一覧定義
  the registry definition, defining how the registry tables are structured and maintained
• データ一覧 (データ一覧データ)により表される一連のデータを保持する, 1つ以上のデータ一覧表
  one or more registry tables, holding the data set represented by the registry (the registry data)
• データ一覧の利用方法を構成する, 1つ以上の仕様書への参照
  one or more referencing specifications, which make use of the registry

データ一覧を維持管理する目的は, 次のことを含んでいるでしょう.

The purposes of maintaining a registry can include:

衝突回避
non-collision

異なった意味を持つ同じ値の2つの登録データの問題を避けること.

Avoiding the problem of two entities using the same value with different semantics.

二重回避
non-duplication

同じ意味で使用される, 2つ以上の異なった値を持つ問題を避けること.

Avoiding the problem of having two or more different values in use with the same semantics.

情報
information

値が何を意味しているか, また, その正式な定義は何か(そして, その定義はどこにあるのか)を誰でも見つけ出せるように, 主要な索引を提供すること.

Providing a central index where anyone can find out what a value means and what its formal definition is (and where it is).

提案
submission

管理組織と無関係な利害関係者からを含む, 新しい事項の追加の容易さ.

Ease of adding new terms, including by stakeholders external to the custodian organization.

合意
consensus

条項に対する関係者の明瞭な合意を証明すること.

Promoting a clear consensus of the community on the terms.

W3C手続き文書のこの節は, このようなデータ一覧表, 特に, W3C勧告に必要とされるか, 密接に関係するデータ一覧の発行や維持管理を手助けする特別な手続きを提供します.

This section of the W3C Process provides a specialized process facilitating the publication and maintenance of such registry tables, particularly those required by or closely related to W3C Recommendations.

注意:仕様書の全ての表が, 潜在的なデータ一覧ではありません. 意図や効果が, 仕様書の著者が期待または予想した可能性をその表が全て列挙することであるなら, 表はそれ自体で十分です. 同様に, その表が「作業部会によって維持管理され, 更新された仕様書の一部として更新されるのであれば, データ一覧の維持管理の複雑さは不要です.

Note: Not every table in a specification is a potential registry. If the intent or effect is that the table enumerates all the possibilities the authors of the specification expect or envisage, then the table by itself is enough. Similarly, if the table is managed by the Working Group and only updated as part of specification update, then the complexities of registry management are not needed.

6.5.1. データ一覧定義
Registry Definitions

データ一覧定義は, 各 データ一覧表が何をどのように維持管理するのか定義します. データ一覧定義は, 次のとおりでなければなりません.

A registry definition defines what each registry table is and how it is maintained. It must:

• 各データ一覧表の範囲と目的を定義しなければなりません.
  Define the scope and purpose of each registry table.
• 各データ一覧表の領域と制限を定義しなければなりません. (例えば, 値は, 定義された一覧から選ばれなければならないか, 独自の値でなければならないか, 公開された利用可能な資源のみを参照しなければならないかなど.)
  Define the fields of each registry table and their constraints (e.g. values must be drawn from a defined set, or be unique, or only reference publicly available resources, etc.)
• 既存の登録データを変更する指針を定義しなければなりません. 例えば, 次のようです.
  Define the policy for changes to existing entries, such as
  • 登録データを削除できる, または非推奨とできるかどうか.
    whether entries can be deleted or deprecated
  • 登録データを発行後に変更できるかどうか, どんな種類の変更が認められるかどうか.
    whether entries can be changed after being published, and what kinds of changes are allowed
  • 以前に削除された一意性の識別子を再利用できるか, 永続的に取っておくかどうか.
    whether previously-deleted unique identifiers can be re-used, or are reserved indefinitely
• 変更が提案され, 承認され, 組み入れられる方法と基準を定義しなければなりません. (例えば, データ一覧は, データ一覧登録データへの変更が, 特定のウェブフォームやメールアドレスを用いて提案されるように定義するでしょう. それらの手段は, 確かな背景となる情報により生じなければならず, また, 特定の作業部会の参加者によって提案される必要があってもなくてもよいです.)
  Define the method and criteria by which changes are proposed, approved, and incorporated. (For example, a registry could define that changes to registry entries can be proposed using a particular web form or email address, that they must be accompanied by certain background information, or that they do or do not need to be approved by any member of a particular Working Group.)
• データ一覧表の管理者を認定しなければなりません. データ一覧変更の依頼は, その管理者に送られなければならず, データ一覧定義で定義した基準をその依頼が満たしているかどうかを評価する責任が, その管理者にあります.
  Identify the custodian of the registry table: the entity to which requests for registry changes must be sent, and which is responsible for evaluating whether such requests satisfy the criteria defined in the registry definition.

  管理者は, 作業部会, 事務局, 代理の組織のどれかでよいです. 単独のデータ一覧の中の全てのデータ一覧表に対する管理者は, 一般に同じ組織であるべきです.

  The custodian may be the Working Group, the Team, or a delegated entity. The custodian for all registry tables in a single registry should generally be the same entity.

6.5.2. データ一覧の発行
Publishing Registries

データ一覧は, データ一覧報告書と呼ばれるデータ一覧工程の独立した技術報告書として発行されるか, またはデータ一覧節として勧告の一部に組み込まれるかのどちらかです.

Registries can be published either as a stand-alone technical report on the Registry Track called a registry report, or incorporated as part of a Recommendation as a registry section.

データ一覧報告書またはデータ一覧節は, 単に文書の提供であって, W3C特許指針は前提としておらず, 何らかの実装の要件を含んではなりません. 特許指針[特許指針]の目的から言って, どの勧告工程の文書のデータ一覧節も, 仕様書の規範的な部分ではありません.

A registry report or registry section is purely documentational, is not subject to the W3C Patent Policy, and must not contain any requirements on implementations. For the purposes of the Patent Policy [PATENT-POLICY], any registry section in a Recommendation track document is not a normative portion of that specification.

データ一覧報告書またはデータ一覧節は, 次のとおりでなければなりません.

The registry report or registry section must:

• データ一覧報告書/データ一覧節, その一覧表, データ一覧定義を明確に分類し, この手続き文書の§ 6.5 データ一覧工程へのリンクを含まなければなりません.
  Clearly label the registry report/section, its tables, and its registry definitions as such, including a link to § 6.5 The Registry Track in this Process.
• データ一覧表それぞれに対してデータ一覧定義を含まなければなりません.
  Include the registry definition for each of its registry tables.
• 次のどちらかの方法でデータ一覧データが提供されなければなりません.
  Provide the registry data by either:
  • 各データ一覧表の全体の内容を含むこと. 報告書の文章内(例えば, 表, 一覧, 他の適切な表現で体裁を整えたもの), 技術報告書の一部として発行される機械判読可能なファイルの中, もしくは(可能であれば)その両方.
    Including the entire contents of each registry table, either inline in the report (e.g. formatted as a table, or list, or other appropriate representation), or in a machine-readable file published as part of the technical report, or (preferably) both.
  • 人が読める形式, 機械判読可能な形式, または(可能であれば)両方の形式のデータ一覧表を含む1つ以上の独立したデータ一覧報告書をリンクすること.
    Linking to one or more standalone Registry Data Reports containing the registry tables in human-readable form, machine-readable form, or (preferably) both.
• データ一覧表が機械判読可能なファイルで提供された場合, それらのファイルの書式の定義を含まなければなりません.
  Include, if the registry table is provided in a machine-readable file, a definition of the format of that file.

事務局は, 興味を持った団体に対してデータ一覧表の更新を通知する方法を利用できるようにしなければなりません.

The Team must make available a means for interested parties to be notified of any updates to a registry table.

注意:手続き文書は, データ一覧定義が課した要件以外の, データ一覧表の中身の変更における要件を課していないことから, 管理者としてのデータ一覧変更案への同意や, 前回の発行以降のデータ一覧変更のみを含む更新されたデータ一覧報告書の発行は, 上記の決まりが実現されたことが自動的に確かめられたなら, 自動的に行われます.

Note: Since the Process does not impose requirements on changes to the contents of a registry table other than those imposed by the registry definition, acceptance of proposed registry changes on behalf of the custodian and publication of an updated registry report that contains only registry changes since the previous publication can be automated if satisfaction of those rules can be automatically verified.

データ一覧工程における発行や進展に対する決まりは, 次に示す例外を除いて, 勧告工程のものと同じです.

Rules for publication and advancement on the Registry Track are identical to that of the Recommendation Track with the following exceptions:

• データ一覧報告書は, [特許指針]を前提としておらず, そのため, どの発行物も, 初期草案, 草案, [特許指針]の意図する特許除外草案に相当しません.
  Registry reports are not subject to the [PATENT-POLICY], and therefore none of their publications correspond, to First Public Working Draft, Working Draft, or Patent Review Draft for the purposes of the [PATENT-POLICY].
• 同じ理由から, データ一覧に対して廃止勧告や廃止勧告候補に相当するものは, 何もありません.
  For the same reason, there is no equivalent to Rescinded Recommendation nor to Rescinded Candidate Recommendation for Registries.
• 草案に相当するものは, 草案データ一覧と呼ばれます.
  The equivalent of Working Draft is called Draft Registry.
• 勧告候補に相当するものは, データ一覧候補と呼ばれ, 勧告候補全体版と勧告候補草案版に相当するものは, データ一覧候補全体版とデータ一覧候補草案版です.
  The equivalent of Candidate Recommendation is called Candidate Registry, with Candidate Recommendation Snapshot and Candidate Recommendation Draft corresponding to Candidate Registry Snapshot and Candidate Registry Draft.
• W3C勧告に相当するものは, W3Cデータ一覧と呼ばれ, 旧式勧告と置換済勧告に相当するものは, 旧式データ一覧と置換済データ一覧です.
  The equivalent of W3C Recommendation is called W3C Registry; Obsolete Recommendation and Superseded Recommendation correspond to Obsolete Registry and Superseded Registry.
• 勧告案の段階に相当するものは, 何もありません. その代わり, 諮問委員会の審査は, 各データ一覧全体版の発行から始まります.
  There is no equivalent to the Proposed Recommendation phase. Instead, an Advisory Committee Review is started upon publication of each Candidate Registry Snapshot.
• 新しい機能を加える変更(すなわち, 種類4の変更)は, それらの変更が認められることを明確に示す必要なく, 全てのW3Cデータ一覧で認めれられています.
  Changes that add new features (i.e. class 4 changes) are allowed in all W3C Registries, without needing the to explicitly indicate that this is allowed.

6.5.3. データ一覧表の更新
Updating Registry Tables

データ一覧定義と調和したデータ一覧表の中身への変更(すなわち, 種類5の変更)は, 影響を受ける一覧表を含む技術報告書を再発行することで, 他の発行の要件を満たすことなく(データ一覧定義で必要とされている場合を除いて, 作業部会の合意さえ無く)反映されます. そのようなデータ一覧変更は, 新たな諮問委員会の審査や除外機会のきっかけとならず, 規範的に期待される成熟レベルにある技術報告書に対してさえ, 更新要求を経由しての承認を必要としません. そのような発行は, データ一覧を維持管理すると憲章に書いた作業部会が無く, 管理者が別の機関である場合さえ, 行われます.

Changes to the contents of a registry table that are in accordance with the registry definition, (i.e. Class 5 changes) can be made by re-publishing the technical report that contains the affected table, without needing to satisfy any other requirements for the publication (not even Working Group consensus, unless this is required by the registry definition). Such registry changes do not trigger new Advisory Committee Reviews, nor Exclusion Opportunities, and do not require approval via an update request, even for technical reports at maturities where this would normally be expected. Such publications can be made even in the absence of a Working Group chartered to maintain the registry when the custodian is another entity.

注意:管理者は, データ一覧変更を行う権限のみを与えられています. データ一覧を確立した作業部会が, 個々の登録データに解説を加える権限を管理者に与えた場合, そのことをデータ一覧表の定義の一部をする必要があります. 他の変更が要望された場合, それらの変更は, 作業部会の責任, もしくは作業部会が無いのであれば, 事務局の責任です.

Note: The custodian is only empowered to make registry changes. If the Working Group establishing the registry wishes to empower the custodian to add commentary on individual entries, this needs to be part of the registry table’s defintion. If other changes are desired, they must be requested of the responsible Working Group—or in the absence of a Working Group, of the Team.

未改正のデータ一覧定義により認められていない, データ一覧定義への改正候補や改正案と調和したデータ一覧表への変更は, そのようであると特定されなければなりません.

Changes to the registry tables made in accordance with candidate or proposed amendments to the registry definition which would not be allowed by the unamended registry definition must be identified as such.

6.5.4. データ一覧報告書
Registry Data Reports

データ一覧データが, データ一覧定義から分割された技術報告書として発行したとき, その報告書は, データ一覧報告書と呼ばれます. その技術報告書は, 次の通りです.

When the registry data is published in a separate technical report from its registry definition, that report is called a Registry Data Report. This technical report:

• 技術報告書が含んでいるデータ一覧表を確立しているデータ一覧定義をリンクしなければなりません.
  Must link to the registry definition establishing the registry tables that it contain.
• 有益な前置きの文章, 例, 技術報告書が含んでいるデータ一覧表と登録データについての注意を含んでもよいです. (これらの部分への変更は, 編集上の変更と思われます).
  May contain informative introductory text, examples, and notes about the registry tables and entries that it contains. (Changes to these parts are deemed to be editorial changes).

データ一覧報告書は, それらの中にそれら自体の成熟レベルを持ちません. その報告書が記録しているデータのデータ一覧の成熟レベルは, データ一覧定義を保持している技術報告書のものです.

Registry Data Reports do not have maturity levels in and of themselves; The maturity level of the registry whose data they record is that of the technical report holding the registry definition.

データ一覧定義に変更を行う場合はいつでも, 作業部会は, それらの変更と文書を調和させるために, 相当するデータ一覧表を保持する何らかの文書を更新し再発行しなければなりません.

Anytime a change is made to a registry definition, the Working Group must update and republish any document holding the corresponding registry tables to make it consistent with these changes.

作業部会は, 編集上の変更を組み入れるためにデータ一覧報告書を再発行する, 記録された部会決定を行ったなら, 再発行してもよいです. データ一覧を維持管理すると憲章に書いた作業部会が無い場合, 代わりに事務局が行ってもよいです.

Given a recorded group decision to do so, the Working Group may republish the Registry Data Report to incorporate editorial changes. If there is no Working Group chartered to maintain this registry, the Team may do so instead.

6.5.5. データ一覧を参照する仕様書
Specifications that Reference Registries

データ一覧は重要性を文書化しますが, その重要性に関連する技術体系上の, または相互運用性の要件を定義しません. データ一覧登録データに付随する技術体系上の, または相互運用性の全ての要件は, データ一覧を参照している技術報告書に含まれなければならず, そのため, それらの参照している技術報告書に適用される(承認や知的財産権の規定を含む)手続きを前提とします.

Registries document values, they do not define any architectural or interoperability requirements related to those values. All architectural and interoperability requirements pertaining to registry entries must be contained in the specifications that reference the registry, and are therefore subject to the processes (including approval and intellectual property provisions) applicable to those referencing specifications.

定義されなければならない登録データ, またはそのような制限がある場合, それらは, データ一覧に依存することなく, 参照している仕様書の中で定義されるか, 文書化されるかしなければなりません.

If there are entries that must be implemented, or any other such restrictions, they must be defined or documented in the referencing specification without dependency on the registry.

6.6. 工程の切り替え
Switching Tracks

次に示す制限の下で, 作業部会は, 技術報告書を今開発されているのとは異なる工程で, 再発行すると部会決定したなら, そのようにできます.

Given a Group decision to do so, Working Groups can republish a technical report on a different track than the one it is on, under the following restrictions:

• W3C勧告, W3C声明, 特許審査草案であるか, 過去にそうであった技術報告書は, 工程を切り替えられません.
  A technical report that is or was a W3C Recommendation, W3C Statement, or Patent Review Draft cannot switch tracks.
• 技術報告書は, 作業部会がそれを後で勧告工程に戻す見込みが考えられる場合, 特許に関連する正当な考慮やW3Cの法的な協議の承認無しで, 勧告工程からそれ以外に切り替えるべきではありません.
  A technical report should not switch away from the Recommendation Track without due consideration of the Patent Policy implications and approval of the W3C’s legal counsel if the Working Group envisions a likelihood of returning to it later.

工程を切り替えた技術報告書は, 何らかの確立された特性(url, 略称等)を保持していたとしても, 新しい工程の最初の熟度レベルから始まります.

Technical reports that switch tracks start at their new track’s initial maturity level, while retaining any established identity (url, shortname, etc.).

6.7. より踏み込んだ見解
Further reading

様々な段階の審査と周知のための準備に関する実用的な情報は, 合意の要領 [案内]の中の"どのように勧告工程の遷移を系統立てるか" [遷移], また, 早く勧告を得るに当たっての情報 [勧告情報]を参照して下さい. また, W3C技術報告書の修正に対する要件 [再発行]も参照して下さい.

Refer to "How to Organize a Recommendation Track Transition" [TRANSITION] in the Art of Consensus [GUIDE] for practical information about preparing for the reviews and announcements of the various steps, and tips on getting to Recommendation faster [REC-TIPS]. Please see also the Requirements for modification of W3C Technical Reports [REPUBLISHING].

7. 普及指針
Dissemination Policies

7.1. 一般社会への情報伝達
Public Communication

事務局は, W3Cの中や一般社会への情報伝達(例えば, ニュースの配信, 公式発表, ウェブサイトの管理や特典の利用, カレンダーの管理)に対して責任があります. 会員は, W3Cの中の自分達の仕事について, 発行された公式発表より重要な, 事務局による審査を要求すべきです.

The Team is responsible for managing communication within W3C and with the general public (e.g., news services, press releases, managing the Web site and access privileges, and managing calendars). Members should solicit review by the Team prior to issuing press releases about their work within W3C.

事務局は, 次の公開情報が持続的で利用可能であることを確かなものにするために, あらゆる努力を行います.

The Team makes every effort to ensure the persistence and availability of the following public information:

• 発行を承認されたW3C技術報告書. 会員規約を通して, W3C技術報告書(とソフトウェア)は, 一般社会で使用料無しに利用できます(W3C文書ライセンス [文書ライセンス]を参照して下さい).
  W3C technical reports whose publication has been approved. Per the Membership Agreement, W3C technical reports (and software) are available free of charge to the general public; (refer to the W3C Document License [DOC-LICENSE]).
• W3Cの目的と使命, 会員への鍵となる恩恵, W3Cの組織構成を説明した活動理念 [理念].
  A mission statement [MISSION] that explains the purpose and mission of W3C, the key benefits for Members, and the organizational structure of W3C.
• 会員規約 [会員規約]や, W3Cが他の団体と交わした何らかの法的債務の文書を含む, 法的文書.
  Legal documents, including the Membership Agreement [MEMBER-AGREEMENT] and documentation of any legal commitments W3C has with other entities.
• 手続き文書.
  The Process Document.
• W3Cの活動とワークショップの結果の公開.
  Public results of W3C activities and Workshops.

W3Cの会議, ワークショップ, 審査の締切と並行して会員を維持するために, 事務局は定期的な(例えば, 毎週の)ニュースの配信を会員に提供したり, W3Cの公式行事のカレンダー [カレンダー]を管理します. 会員は, そのカレンダーに入れ込むために, 事務局に予定や行事の情報を送ることを促されています.

To keep the Members abreast of W3C meetings, Workshops, and review deadlines, the Team provides them with a regular (e.g., weekly) news service and maintains a calendar [CALENDAR] of official W3C events. Members are encouraged to send schedule and event information to the Team for inclusion on this calendar.

7.2. 機密レベル
Confidentiality Levels

(W3Cのウェブサイトや, W3Cの会議などで)W3Cの情報を利用する3つの主な機密レベルがあります. 公開, 会員限定, 事務局限定です.

There are three principal levels of access to W3C information (on the W3C Web site, in W3C meetings, etc.): public, Member-only, and Team-only.

W3Cによって利用可能にされる多数の情報は公開である一方, “会員限定”の情報は, 会員組織の代表者, 外部の専門家, 諮問会議, TAG, 事務局を含む, 認定された関係者のみ利用可能です. 例えば, 作業部会の憲章の中には, 部会の進捗状況に対して, 会員限定の機密レベルを指定してもよいです.

While much information made available by W3C is public, “Member-only” information is available to authorized parties only, including representatives of Member organizations, Invited Experts, the Advisory Board, the TAG, and the Team. For example, the charter of some Working Groups may specify a Member-only confidentiality level for group proceedings.

“事務局限定”の情報は, 事務局と事務局以外の認定された関係者が利用可能です.

“Team-only” information is available to the Team and other authorized parties.

会員限定や事務局限定の情報を利用するために認定された関係者は次のようにしなければなりません.

Those authorized to access Member-only and Team-only information:

• W3Cの中で機密として情報を扱わなければなりません.
  must treat the information as confidential within W3C,
• 機密の望ましいレベルを管理するための理性的な努力を働かせなければなりません.
  must use reasonable efforts to maintain the proper level of confidentiality, and
• それらの情報を一般社会や報道に公開してはなりません.
  must not release this information to the general public or press.

事務局は, 会員限定の情報の機密を保護する仕組みを提供しなければならず, 認定された関係者がその情報を望ましく利用できることを確実にしなければなりません. 文書は, 会員限定の機密レベルが必要かどうか, 明確に示すべきです. 情報の断片の機密レベルに確信がない人物は, 事務局に連絡すべきです.

The Team must provide mechanisms to protect the confidentiality of Member-only information and ensure that authorized parties have proper access to this information. Documents should clearly indicate whether they require Member-only confidentiality. Individuals uncertain of the confidentiality level of a piece of information should contact the Team.

諮問委員会の委員は, 会員の代表者や, 受領者として適切だと考えられる会員の他の従業員に, 会員限定の利用を認定してもよいです. 例えば, 会員限定のニュースの通知を自分達の組織の中のみの内部利用のために配布するかどうかは, 諮問委員会の委員, 他の従業員, 組織の公式な代表者の責任です. 会員メーリングリストについての情報は, 新会員オリエンテーション [導入]で確認できます.

Advisory Committee representatives may authorize Member-only access to Member representatives and other individuals employed by the Member who are considered appropriate recipients. For instance, it is the responsibility of the Advisory Committee representative and other employees and official representatives of the organization to ensure that Member-only news announcements are distributed for internal use only within their organization. Information about Member mailing lists is available in the New Member Orientation [INTRO].

7.3. 機密レベルの変更
Changing Confidentiality Level

会員の恩恵として, W3Cは, 確かな形の情報伝達のために, 事務局限定や会員限定の経路をいくつか提供しています. 例えば, 諮問委員会の委員は, 事務局限定の経路に審査意見を送ることができます. しかしながら, 技術報告書の開発手続きといった, 重要な公開の成果のW3C手続きにおいて, 意思決定に影響する情報としては, 公に利用可能なことも重要です. 事務局は, 事務局限定の情報を作業部会や一般とやり取りする必要があるかもしれません. 同様に, 部会の進捗状況が会員限定の作業部会は, 技術報告書の開発手続きに属する公開の情報を出さなければなりません.

As a benefit of membership, W3C provides some Team-only and Member-only channels for certain types of communication. For example, Advisory Committee representatives can send reviews to a Team-only channel. However, for W3C processes with a significant public component, such as the technical report development process, it is also important for information that affects decision-making to be publicly available. The Team may need to communicate Team-only information to a Working Group or the public. Similarly, a Working Group whose proceedings are Member-only must make public information pertinent to the technical report development process.

この文書は, どの情報が会員または一般に利用可能でなければならないかを, 例え, その情報が最初は事務局限定または会員限定の経路でやりとりしていたとしても, 明確に示します. 事務局と事務局に認定された関係者のみが, それらの情報の機密レベルを変更してもよいです. その場合, 次のように行います.

This document clearly indicates which information must be available to Members or the public, even though that information was initially communicated on Team-only or Member-only channels. Only the Team and parties authorized by the Team may change the level of confidentiality of this information. When doing so:

1. 事務局は, 著者によって新しい機密レベルのものとして明確に提供されたバージョンの情報を使用しなければなりません. 審査の要請や他の似た情報伝達において, 事務局は, 受領者にそのどのバージョンを提供したか念を押すべきです.
   The Team must use a version of the information that was expressly provided by the author for the new confidentiality level. In Calls for Review and other similar messages, the Team should remind recipients to provide such alternatives.
2. 事務局は, 著者の同意無しに, 新しい機密レベルのバージョンを著者のものであると考えてはいけません.
   The Team must not attribute the version for the new confidentiality level to the author without the author’s consent.
3. 著者が, 他の機密レベルに適したバージョンを事務局に伝えなかった場合, 事務局は, 元々の機密レベルを尊重しながら, 元々の著者のせいにすることなく, 必要な内容を分別よく情報伝達できるバージョンを利用可能にしてもよいです.
   If the author has not conveyed to the Team a version that is suitable for another confidentiality level, the Team may make available a version that reasonably communicates what is required, while respecting the original level of confidentiality, and without attribution to the original author.

8. ワークショップとシンポジウム
Workshops and Symposia

事務局は, W3Cの活動の開発における, 会員や一般社会からの早くからの関わり合いを促すために, ワークショップとシンポジウムを開催します.

The Team organizes Workshops and Symposia to promote early involvement in the development of W3C activities from Members and the public.

ワークショップの目的は, 通常, 技術や方針についての意見交換のために, 専門家や他の興味を持っている団体を招待すること, もしくは, W3C会員の強く求めている関心に対応することです. 最初の形式のワークショップの開催者は, ワークショップのプログラムについての方針説明書を要求してもよいですし, それらの資料を出席者や発表者を選ぶのに利用してもよいです.

The goal of a Workshop is usually either to convene experts and other interested parties for an exchange of ideas about a technology or policy, or to address the pressing concerns of W3C Members. Organizers of the first type of Workshop may solicit position papers for the Workshop program and may use those papers to choose attendees and/or presenters.

シンポジウムの目標は, 通常, 特定の題目について興味を持っている団体に情報を提供することです.

The goal of a Symposium is usually to educate interested parties about a particular subject.

ワークショップまたはシンポジウムの参加の要請は, 参加の要件または範囲, 期待される成果(例えば, 報告書や議事録)を示してもよいです. それらの催しの主催者は, 特定の題目におけるW3Cによる更なる投資は保証しませんが, 新しい活動や部会の提案を先導してもよいです.

The Call for Participation in a Workshop or Symposium may indicate participation requirements or limits, and expected deliverables (e.g., reports and minutes). Organization of an event does not guarantee further investment by W3C in a particular topic, but may lead to proposals for new activities or groups.

ワークショップとシンポジウムは, 通常, 1日から3日間続きます. ワークショップが会員の表明した関心に焦点を当てるために開催されるならば, 事務局は, ワークショップの開催予定日の6週間前までに参加の要請を発しなければなりません. 他のワークショップやシンポジウムに対しては, 事務局は, 催しの開始予定日の8週間前までに参加の要請を発しなければなりません. このことは, 方針説明書や講演の準備を行う十分な時間を, 講演者や著者が持つことを確実にすることを助けます.

Workshops and Symposia generally last one to three days. If a Workshop is being organized to address the pressing concerns of Members, the Team must issue the Call for Participation no later than six weeks prior to the Workshop’s scheduled start date. For other Workshops and Symposia, the Team must issue a Call for Participation no later than eight weeks prior to the meeting’s scheduled start date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks.

9. 連絡体制
Liaisons

W3Cは, 連絡体制という用語を, (例えば, 他の組織から個人がW3C作業部会に参加するか, もしくは単に作業を追跡するといった)とても簡略なものから, 相互に会員であること, さらにより正確な契約といったもものまで及ぶ, 様々な組織との活動の調整を表すのに用います. 連絡体制は, W3Cとの会員関係の代わりになるものを意味しません.

W3C uses the term liaison to refer to coordination of activities with a variety of organizations, through a number of mechanisms ranging from very informal (e.g., an individual from another organization participates in a W3C Working Group, or just follows its work) to mutual membership, to even more formal agreements. Liaisons are not meant to substitute for W3C membership.

全ての連絡体制は, 一般の意思疎通, 特許, 著作権, 他のIPR方針に対する必要性, 機密契約, 相互会員契約に応じて, 事務局によって調整されなければなりません.

All liaisons must be coordinated by the Team due to requirements for public communication; patent, copyright, and other IPR policies; confidentiality agreements; and mutual membership agreements.

W3Cディレクターは, 他の組織と覚書を結んでもよいです. W3C手続き文書の目的のために, 覚書(MoU)は, 各団体の他者に対する権利と義務を指定した正式な契約, もしくは, W3Cと他の団体との間の契約上の類似した枠組みです. なお, 会員関係を意図するホスト機関 の間, もしくはホスト機関とW3C会員組織の間の契約, W3Cを運営する目的の業務の通常の規定に関係した契約以外です. 覚書の権利と義務は, 共同の成果, しかるべき調整と一緒の技術的な責任の同意の上の分散, 機密と特定のIPRに対する調整を含みます. その契約は, “覚書”以外の名前で呼ばれるかもしれませんし, “覚書”と呼ばれるものが手続き文書の意図するMoUでないかもしれません.

The W3C Director may negotiate a Memorandum of Understanding with another organization. For the purposes of the W3C Process a Memorandum of Understanding (MoU) is a formal agreement or similar contractual framework between W3C and another party or parties, other than agreements between the Hosts or between Hosts and W3C members for the purposes of membership and agreements related to the ordinary provision of services for the purposes of running W3C, that specifies rights and obligations of each party toward the others. These rights and obligations may include joint deliverables, an agreed share of technical responsibilities with due coordination, and/or considerations for confidentiality and specific IPR. The agreement may be called something other than a “Memorandum of Understanding”, and something called a “Memorandum of Understanding” may not be an MoU for the purposes of the Process.

MoUに署名する前に, 事務局は, 諮問委員会に署名の意思を通知し, MoUを諮問委員会の審査が可能な状態にしなければなりません. 諮問委員会の委員は, MoUへの署名の決定に対し諮問委員会の抗議を提出してもよいです. 抗議がMoUに署名する提案を却下しない限り, ディレクターは, W3Cを代表してMoUに署名してもよいです. 署名された覚書は公開されるべきです.

Before signing the MoU, the Team must inform the Advisory Committee of the intent to sign and make the MoU available for Advisory Committee review; Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the MoU. Unless an appeal rejects the proposal to sign an MoU, the Director may sign the MoU on behalf of W3C. A signed Memorandum of Understanding should be made public.

他の組織とのW3C連絡体制 [連絡体制]についての情報, また, 連絡体制を構築するときにW3Cが従う手続きは, ウェブで利用可能です.

Information about W3C liaisons with other organizations [LIAISON] and the guidelines W3C follows when creating a liaison is available on the Web.

10. 会員提案手続き
Member Submission Process

会員提案手続きは, 事務局による考察を受ける技術や意見を提案することを, 会員に認めています. 審査の後, 事務局は, その内容をW3Cのウェブサイトで利用できるようにしてもよいです. 正式な手続きは, その貢献の記録を会員に提供し, 事務局と(IPRの主張を含めて)詳細な意見交換を開示するための仕組みを会員に提供します. 事務局は, 提案された内容に対する審査意見もW3C会員, 一般社会, 報道機関に利用できるようにします.

The Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the Team may make the material available at the W3C Web site. The formal process affords Members a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Team (including IPR claims). The Team also makes review comments on the Submitted materials available for W3C Members, the public, and the media.

会員提案は次のものから構成されます.

A Member Submission consists of:

• W3C手続きの外部で開発された1つ以上の文書.
  One or more documents developed outside of the W3C process, and
• 提案者から提供された, 文書についての情報.
  Information about the documents, provided by the Submitter.

(提案者と呼ばれる)1つ以上の会員は, 会員提案に参加してもよいです. W3C会員のみが提案者として一覧にされてよいです.

One or more Members (called the Submitter(s)) may participate in a Member Submission. Only W3C Members may be listed as Submitters.

提案手続きは, 次の段階から構成されます.

The Submission process consists of the following steps:

1. 提案者の1つが, 事務局に提案要求を承認するよう要求を送ります. 事務局と提案者は, 会員提案が完全なものであることを確実にするためにやり取りするでしょう.
   One of the Submitters sends a request to the Team to acknowledge the Submission request. The Team and Submitter(s) communicate to ensure that the Member Submission is complete.
2. 事務局の審査の後, ディレクターは, 提案要求を承認するか却下するかしなければなりません.
   After Team review, the Director must either acknowledge or reject the Submission request.
   • 承認された場合, 事務局は, 会員提案についての事務局の意見を加えて, 会員提案を公開されているW3Cのウェブサイトで利用できるようにしなければなりません.
     If acknowledged, the Team must make the Member Submission available at the public W3C Web site, in addition to Team comments about the Member Submission.
   • 却下された場合, 提案者は, 提案の抗議を, TAGまたは諮問会議のどちらかに提出してもよいです.
     If rejected, the Submitter(s) may initiate a Submission Appeal to either the TAG or the Advisory Board.

会員提案をW3Cのウェブサイトで利用できるようにすることは, W3C事務局または会員を含めた, W3Cからの支持を意味しません. 提案要求の承認は, 何らかの活動がW3Cによって行われることを意図しません. この承認は, 単に提案要求が提案者によって行われたことを公開の場で記録するだけです. W3Cにより利用可能になった会員提案は, W3Cの“進展中の作業”として参照されてはなりません.

Making a Member Submission available at the W3C Web site does not imply endorsement by W3C, including the W3C Team or Members. The acknowledgment of a Submission request does not imply that any action will be taken by W3C. It merely records publicly that the Submission request has been made by the Submitter. A Member Submission made available by W3C must not be referred to as “work in progress” of W3C.

承認された会員提案の一覧[提案一覧]は, W3Cのウェブサイトで利用できます.

The list of acknowledged Member Submissions [SUBMISSION-LIST] is available at the W3C Web site.

10.1. 提案者の権利と義務
Submitter Rights and Obligations

複数の会員が一緒に提案要求に参加している場合, 1つの会員のみが要求を送ります. その会員は, 他の参加している会員それぞれの諮問委員会の委員に, 要求の写しを送らなければならず, それぞれのその諮問委員会の委員は, (事務局にメールで)提案要求に参加していることをはっきりと言わなければなりません.

When more than one Member jointly participates in a Submission request, only one Member formally sends in the request. That Member must copy each of the Advisory Committee representatives of the other participating Members, and each of those Advisory Committee representatives must confirm (by email to the Team) their participation in the Submission request.

承認の前ならいつでも, どの提案者も, ("どのように提案要求を送るのか" [提案要求]で述べられている)提案要求の支持を撤回してもよいです. 提案要求は, どの提案者も提案を支持していなくなったら“撤回”されます. 事務局は, 提案要求の撤回について意見してはなりません.

At any time prior to acknowledgment, any Submitter may withdraw support for a Submission request (described in "How to send a Submission request" [SUBMISSION-REQ]). A Submission request is “withdrawn” when no Submitter(s) support it. The Team must not make statements about withdrawn Submission requests.

承認の前に, 提案者は. どんな状況でも, 文書を“ワールド・ワイド・ウェブ・コンソーシアムに提出された”または“W3Cによる考察の下にある”ものとして, もしくは, 一般社会または会員間のやりとりにおける何らかの同じような表現を参照してはなりません. 提案者は, 一般社会または会員間のやり取りでW3Cが(提案者と)会員提案の内容について作業していることを示してはなりません. 提案者は, 会員提案の文書を, 承認の前に(提案要求を参照すること無しに)一般社会に公開してもよいです.

Prior to acknowledgment, the Submitter(s) must not, under any circumstances, refer to a document as “submitted to the World Wide Web Consortium” or “under consideration by W3C” or any similar phrase either in public or Member communication. The Submitter(s) must not imply in public or Member communication that W3C is working (with the Submitter(s)) on the material in the Member Submission. The Submitter(s) may release the documents in the Member Submission to the public prior to acknowledgment (without reference to the Submission request).

承認の後, 提案者は, どんな状況でも, 会員提案において, その内容がW3C作業部会の成果として採用されない限り, 採用されるまでW3Cの投資を必要としてはなりません.

After acknowledgment, the Submitter(s) must not, under any circumstances, imply W3C investment in the Member Submission until, and unless, the material has been adopted as a deliverable of a W3C Working Group.

10.1.1. 会員提案の範囲
Scope of Member Submissions

技術が, 憲章を持つ作業部会の作業の範囲と重複する場合, 会員は作業部会に参加し, 会員提案手続きを通じた公開を要求するのではなく, 技術を部会の手続きに寄付すべきです. 作業部会は, 寄付された技術を成果に組み入れてもよいです. 作業部会が技術を組み入れない場合, 作業部会のメモは部会への提供ではなく部会の成果を表しているので, 作業部会は, 寄付された文書を作業部会のメモとして公開すべきではありません.

When a technology overlaps in scope with the work of a chartered Working Group, Members should participate in the Working Group and contribute the technology to the group’s process rather than seek publication through the Member Submission process. The Working Group may incorporate the contributed technology into its deliverables. If the Working Group does not incorporate the technology, it should not publish the contributed documents as Working Group Notes since Working Group Notes represent group output, not input to the group.

一方で, W3Cが憲章を開発する初期の段階の間, 会員は, 提案手続きを新しい作業に対する具体的な提案への合意形成のために利用すべきです.

On the other hand, while W3C is in the early stages of developing a charter, Members should use the Submission process to build consensus around concrete proposals for new work.

会員は, W3Cの活動理念 [理念]の範囲外の題目を相当含む内容を提案すべきではありません.

Members should not submit materials covering topics well outside the scope of W3C’s mission [MISSION].

10.1.2. 提案要求に必要な情報
Information Required in a Submission Request

提案者と提案された内容の何らかの他の著者は, 要求が承認されたならば, 会員提案の中の文書がW3C文書ライセンス [文書ライセンス]の下に置かれ, そのライセンスへの参照を含むことに同意しなければなりません. 提案者は, 会員提案の中の文書の著作権を保持してもよいです.

The Submitter(s) and any other authors of the submitted material must agree that, if the request is acknowledged, the documents in the Member Submission will be subject to the W3C Document License [DOC-LICENSE] and will include a reference to it. The Submitter(s) may hold the copyright for the documents in a Member Submission.

要求は, W3C特許指針[特許指針]の中の“W3C提案におけるライセンス義務”の会員提案ライセンスを満たさなければなりません.

The request must satisfy the Member Submission licensing commitments in “Licensing Commitments in W3C Submissions” in the W3C Patent Policy [PATENT-POLICY].

提案者は, 次の情報を含めなければなりません.

The Submitter(s) must include the following information:

• 提案した全ての会員の一覧.
  The list of all submitting Members.
• (提案者によって集められた)提案した全ての会員からの意見表明報告書. 意見表明報告書は, 分割された文書全てに現れなければなりません.
  Position statements from all submitting Members (gathered by the Submitter). All position statements must appear in a separate document.
• 考察のために提案された文書の完全な電子的コピー(例えば, 技術仕様書, 方針説明書など). 提案要求が承認された場合, それらの文書は, W3Cによって利用可能な状態にされ, その結果, 事務局の発行の決まり [発行の決まり]を満たさなければなりません. 提案者は, それらの文書に含まれている内容に対する著作権を保持してもよいですが, W3Cによって利用可能な状態にされた場合, それらの文書は, W3C文書ライセンス [文書ライセンス]の規定に従わなければなりません.
  Complete electronic copies of any documents submitted for consideration (e.g., a technical specification, a position paper, etc.) If the Submission request is acknowledged, these documents will be made available by W3C and therefore must satisfy the Team’s Publication Rules [PUBRULES]. Submitters may hold the copyright for the material contained in these documents, but when made available by W3C, these documents must be subject to the provisions of the W3C Document License [DOC-LICENSE].

要求は, 次の質問にも答えなければなりません.

The request must also answer the following questions.

• 何の所有する技術が, 要求が取り組む分野を実装するのに必要か, また, 何の条件がその利用に関連するのか? たくさんの回答が可能ですが, 特定の回答は, 事務局の決定に影響します.
  What proprietary technology is required to implement the areas addressed by the request, and what terms are associated with its use? Again, many answers are possible, but the specific answer will affect the Team’s decision.
• W3Cが提案を承認したら, もしあれば, 何の資源を, 提案者は利用可能にするつもりか, また, 何の資源で提案に取り掛かるのか?
  What resources, if any, does the Submitter intend to make available if W3C acknowledges the Submission request and takes action on it?
• 提案要求が承認されたら, 何の活動を提案者はW3Cに行ってほしいか?
  What action would the Submitter like W3C to take if the Submission request is acknowledged?
• 何の仕組みが, 提案された仕様書に変更を行うためにあるのか? このことは, 要求が承認された場合, 変更の制御がどこに備わっているかを述べることを, それに限らず含みます.
  What mechanisms are there to make changes to the specification being submitted? This includes, but is not limited to, stating where change control will reside if the request is acknowledged.

提案要求に関係する他の運営上の要件については, “どのように提案要求を送るか” [会員提案]を参照して下さい.

For other administrative requirements related to Submission requests, see “How to send a Submission request” [MEMBER-SUB].

10.2. 事務局の権利と義務
Team Rights and Obligations

会員提案の文書は, 技術報告書ではないにも関わらず, 事務局の発行の決まり [発行の決まり]を含め, 事務局によって制定された要件を満たさなければなりません.

Although they are not technical reports, the documents in a Member Submission must fulfil the requirements established by the Team, including the Team’s Publication Rules [PUBRULES].

事務局が提案要求を審査し, 一旦, 完全で正確であると判断したならば, 事務局は, 提案者に有効かどうかの通知を送ります.

The Team sends a validation notice to the Submitter(s) once the Team has reviewed a Submission request and judged it complete and correct.

要求を承認するか却下するか決める前は, 要求は事務局限定で, 事務局は, 要求を最も厳格な機密レベルにして置かなければなりません. 特に, 事務局は, 提案要求について報道機関に述べてはなりません.

Prior to a decision to acknowledge or reject the request, the request is Team-only, and the Team must hold it in the strictest confidentiality. In particular, the Team must not comment to the media about the Submission request.

10.3. 提案要求の承認
Acknowledgment of a Submission Request

事務局は, 諮問委員会に通知を送ることによって, 提案要求を承認します. 通知は, いつでも行ってよいですが, 提案者は, 有効かどうかの通知の後4から6週間の間に通知があることを期待できます. 事務局は, 提案者にいつごろ通知が行われそうか知らせ続けなければなりません.

The Team acknowledges a Submission request by sending an announcement to the Advisory Committee. Though the announcement may be made at any time, the Submitter(s) can expect an announcement between four to six weeks after the validation notice. The Team must keep the Submitter(s) informed of when an announcement is likely to be made.

提案要求が1度承認されたならば, 事務局は, 次のとおりしなければなりません.

Once a Submission request has been acknowledged, the Team must:

• 会員提案をW3Cのウェブサイトで利用できるようにしなければなりません.
  Make the Member Submission available at the W3C Web site.
• 会員提案についての事務局の意見をW3Cのウェブサイトで利用できるようにしなければなりません.
  Make the Team comments about the Submission request available at the W3C Web site.

提案者が, 承認の結果として利用可能な状態になった文書を修正しようとする場合, 提案者は, 単に編集上の変更を修正するだけであったとしても, 最初から提案手続きを始めなければなりません.

If the Submitter(s) wishes to modify a document made available as the result of acknowledgment, the Submitter(s) must start the Submission process from the beginning, even just to correct editorial changes.

10.4. 提案要求の却下, 提案の抗議
Rejection of a Submission Request, and Submission Appeals

ディレクターは, 次のいずれかを含む様々な理由で, 提案要求を却下してもよいです.

The Director may reject a Submission request for a variety of reasons, including any of the following:

• 要求で表現されている着想が, 憲章のある作業部会の作業と範囲が被っており, また, 承認が部会の進展を危険にさらすかもしれない場合.
  The ideas expressed in the request overlap in scope with the work of a chartered Working Group, and acknowledgment might jeopardize the progress of the group.
• 提案者によって作られたIPRの声明が, W3C特許指針[特許指針], 特に“W3C提案のライセンス義務”, 文書ライセンス [文書ライセンス], 他のIPR指針と矛盾する場合.
  The IPR statement made by the Submitter(s) is inconsistent with the W3C’s Patent Policy [PATENT-POLICY] and in particular the “Licensing Commitments in W3C Submissions”, Document License [DOC-LICENSE], or other IPR policies.
• 要求で表現されている着想が, 粗末か, ウェブに損害を与えるか, W3Cの活動理念 [理念]と逆方向に進んでいるかする場合.
  The ideas expressed in the request are poor, might harm the Web, or run counter to W3C’s mission [MISSION].
• 要求で表現されている着想が, W3Cの活動理念の大分外側に位置する場合.
  The ideas expressed in the request lie well outside the scope of W3C’s mission.

却下された場合, 事務局は, 提案者の諮問委員会の委員に通知しなければなりません. 提案者から要求された場合, 事務局は, 提案者に却下についての根拠を提供しなければなりません. 提案者以外には, 事務局は, なぜ提案要求が却下されたのかについて意見を述べてはなりません.

In case of a rejection, the Team must inform the Advisory Committee representative(s) of the Submitter(s). If requested by the Submitter(s), the Team must provide rationale to the Submitter(s) about the rejection. Other than to the Submitter(s), the Team must not make statements about why a Submission request was rejected.

提案者の諮問委員会の委員は, 事務局の決定に対する提案の抗議を, 理由がウェブ技術体系に関係するものならTAGへ, 要求が他の理由で却下されたのなら諮問会議へ提出してもよいです. その場合, 事務局は, 却下の根拠を適切な形で利用できるようにすべきです. 事務局は, 適切な機密レベルを確かにした, そのような抗議に対する手続きを立ち上げるでしょう.

The Advisory Committee representative(s) of the Submitters(s) may initiate a Submission Appeal of the Team’s Decision to the TAG if the reasons are related to Web architecture, or to the Advisory Board if the request is rejected for other reasons. In this case the Team should make available its rationale for the rejection to the appropriate body. The Team will establish a process for such appeals that ensures the appropriate level of confidentiality.

11. 手続き文書の発展
Process Evolution

W3C手続き文書および関連する文書(下記参照)の改訂は, 作業部会をまとめる働きをしている諮問会議によって, 技術報告書に対するものと似た合意形成手続きを経ます. それらの文書は, ABによって開発されるか, もしくはABに開発を委任された他の部会によって開発されてよいです. 審査は, W3C関係者から, 特に事務局から要求された内容を含みます.

Revision of the W3C Process and related documents (see below) undergoes similar consensus-building processes as for technical reports, with the Advisory Board—acting as the sponsoring Working Group. The documents may be developed by the AB or by another group to whom the AB has delegated development. Review includes soliciting input from the W3C community, and in particular the Team.

この節で対象とされる文書は, 次のとおりです.

The documents covered by this section are:

• W3C手続き文書(この文書)

  the W3C Process (this document)

• W3C特許指針[特許指針]

  the W3C Patent Policy [PATENT-POLICY]

• W3C倫理規定および職業行為規定[CEPC]

  the W3C Code of Ethics and Professional Conduct [CEPC]

• W3C文書ライセンス [文書ライセンス]

  The W3C Document License [DOC-LICENSE]

諮問会議は, 次のとおり審査を発議します.

The Advisory Board initiates review as follows:

1. 事務局が, 審査の要請を諮問委員会とW3Cの他の部会に送ります.
   The Team sends a Call for Review to the Advisory Committee and other W3C groups.
2. 意見が正式に取り組まれ, 場合によっては文書が修正された後, 事務局は, 諮問委員会の審査を発議することで, 会員からの支持を得ようとします. 審査の期間は, 少なくとも28日以上としなければなりません.
   After comments have been formally addressed and the document possibly modified, the Team seeks endorsement from the Members by initiating an Advisory Committee review. The review period must last at least 28 days.
3. 諮問委員会の審査の後, 文書を採用するW3C決定に従って, 事務局は文書を採用し, 諮問委員会に通知を送ります. 諮問委員会の委員は, W3Cに諮問委員会の抗議を提出してもよいです.
   After the Advisory Committee review, following a W3C decision to adopt the document(s), the Team does so and sends an announcement to the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal to W3C.

注意:2020年7月時点で, 特許指針は特許および標準関連部会で, W3C倫理規定および職業行為規定は積極的作業環境共同部会で, 手続き文書はW3C手続き共同部会で開発されています.

Note: As of June 2020, the Patent Policy is developed in the Patents and Standards Interest Group, the Code of Ethics and Professional Conduct in the Positive Work Environment Community Group, and the Process in the W3C Process Community Group.

12. 謝辞
Acknowledgments

この節は規範ではありません.

This section is non-normative.

編集者は, 改訂された手続き文書の提案に寄与した次に示す方々に, 関係した個人と所属を一覧にして感謝します. Brian Kardell, Carine Bournez (W3C), Charles McCathie Nevile (ConsenSys), Chris Wilson (Google), David Singer (Apple), Delfi Ramirez, Dominique Hazael-Massieux (W3C), Elika J. Etemad aka fantasai, Fuqiao Xue (W3C), Jeff Jaffe (W3C), Kevin Fleming (ブルームバーグ), Leonie Watson (The Paciello Group), Michael Champion (マイクロソフト), Nigel Megitt (BBC), Philippe Le Hegaret (W3C), Ralph Swick (W3C), Samuel Weiler (W3C), Sandro Hawke (W3C), Shawn Lawton Henry, Tantek Celik (Mozilla), Virginia Fournier (Apple), Wendy Seltzer (W3C), Yves Lafon (W3C).

The editors are grateful to the following people, who as interested individuals and/or with the affiliation(s) listed, have contributed to this proposal for a revised Process: Brian Kardell, Carine Bournez (W3C), Charles McCathie Nevile (ConsenSys), Chris Wilson (Google), David Singer (Apple), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Elika J. Etemad aka fantasai, Fuqiao Xue (W3C), Jeff Jaffe (W3C), Kevin Fleming (Bloomberg), Léonie Watson (The Paciello Group), Michael Champion (Microsoft), Nigel Megitt (BBC), Philippe Le Hégaret (W3C), Ralph Swick (W3C), Samuel Weiler (W3C), Sandro Hawke (W3C), Shawn Lawton Henry, Tantek Çelik (Mozilla), Virginia Fournier (Apple), Wendy Seltzer (W3C), Yves Lafon (W3C).

編集者が誰かの名前を忘れていたら申し訳ありません. また, この文書についての対話を, さらに追加の必要を感じることなく根気よく聞いて頂いた方々に感謝します.

The editors are sorry for forgetting any names, and grateful to those who have listened patiently to conversations about this document without feeling a need to add more.

次の方々は, 手続き文書の以前のバージョンの開発に寄与しました. Alex Russell (Google), Andreas Tai (Institut fuer Rundfunktechnik), Andrew Betts (Fastly), Ann Bassetti (ボーイング社), Anne van Kesteren, Art Barstow (ノキア, 独立), Bede McCall (MITRE), Ben Wilson, Brad Hill (Facebook), Brian Kardell (JQuery), Carine Bournez (W3C), Carl Cargill (ネットスケープ, サン・マイクロシステムズ, アドビ), Chris Lilley (W3C), Chris Wilson (Google), Claus von Riegen (SAP AG), Coralie Mercier (W3C), Cullen Jennings (シスコ), Dan Appelquist (テレフォニカ, サムスン), Dan Connolly (W3C), Daniel Dardailler (W3C), Daniel Glazman (Disruptive Innovations), David Baron (Mozilla), David Fallside (IBM), David Singer (Apple), David Singer (IBM), Delfi Ramirez, Dominique Hazael-Massieux (W3C), Don Brutzman (Web3D), Don Deutsch (オラクル), Eduardo Gutentag (サン・マイクロシステムズ), Elika J. Etemad aka fantasai, Florian Rivoal, Fuqiao Xue (W3C), Geoffrey Creighton (マイクロソフト), Geoffrey Snedden, Giri Mandyam (クアルコム), Gregg Kellogg, Hadley Beeman, Helene Workman (Apple), Henri Sivonen (Mozilla), Hakon Wium Lie (オペラソフトウェア), Ian Hickson (Google), Ian Jacobs (W3C), Ivan Herman (W3C), J Alan Bird (W3C), Jay Kishigami 岸上順一 (NTT), Jean-Charles Verdie (MStar), Jean-Francois Abramatic (IBM, ILOG, W3C), Jeff Jaffe (W3C), Jim Bell (HP), Jim Miller (W3C), Joe Hall (CDT), John Klensin (MCI), Josh Soref (BlackBerry, 独立), Judy Brewer (W3C), Judy Zhu 朱红儒 (アリババ), Kari Laihonen (エリクソン), Karl Dubost (Mozilla), Ken Laskey (MITRE), Kevin Fleming (ブルームバーグ), Klaus Birkenbihl (フランホーファー研究機構), Larry Masinter (アドビシステムズ), Lauren Wood (独立), Liam Quin (W3C), Leonie Watson (The Paciello Group), Marcos Caceres (Mozilla), Maria Courtemanche (IBM), Mark Crawford (SAP), Mark Nottingham, Michael Champion (マイクロソフト), Michael Geldblum (オラクル), Mike West (Google), Mitch Stoltz (EFF), Natasha Rooney (GSMA), Nigel Megitt (BBC), Olle Olsson (SICS), Ora Lassila (ノキア), Paul Cotton (マイクロソフト), Paul Grosso (Arbortext), Peter Linss, Peter Patel-Schneider, Philippe Le Hegaret (W3C), Qiuling Pan (ファーウェイ), Ralph Swick (W3C), Renato Iannella (IPR Systems), Rigo Wenning (W3C), Rob Sanderson (ゲティ財団), Robin Berjon (W3C), Sally Khudairi (W3C), Sam Ruby (IBM), Sandro Hawke (W3C), Sangwhan Moon (Odd Concepts), Scott Peterson (Google), Steve Holbrook (IBM), Steve Zilles (アドビシステムズ) Steven Pemberton (CWI), TV Raman (Google), Tantek Celik (Mozilla), Terence Eden (英国政府), Thomas Reardon (マイクロソフト), Tim Berners-Lee (W3C), Tim Krauskopf (Spyglass), Travis Leithead (マイクロソフト), Virginia Fournier (Apple), Virginie Galindo (ジェムアルト), Wayne Carr (インテル), Wendy Fong (ヒューレッドパッカード), Wendy Seltzer (W3C), Yves Lafon (W3C).

The following individuals contributed to the development of earlier versions of the Process: Alex Russell (Google), Andreas Tai (Institut fuer Rundfunktechnik), Andrew Betts (Fastly), Ann Bassetti (The Boeing Company), Anne van Kesteren, Art Barstow (Nokia, unaffiliated), Bede McCall (MITRE), Ben Wilson, Brad Hill (Facebook), Brian Kardell (JQuery), Carine Bournez (W3C), Carl Cargill (Netscape, Sun Microsystems, Adobe), Chris Lilley (W3C), Chris Wilson (Google), Claus von Riegen (SAP AG), Coralie Mercier (W3C), Cullen Jennings (Cisco), Dan Appelquist (Telefonica, Samsung), Dan Connolly (W3C), Daniel Dardailler (W3C), Daniel Glazman (Disruptive Innovations), David Baron (Mozilla), David Fallside (IBM), David Singer (Apple), David Singer (IBM), Delfí Ramírez, Dominique Hazaël-Massieux (W3C), Don Brutzman (Web3D), Don Deutsch (Oracle), Eduardo Gutentag (Sun Microsystems), Elika J. Etemad aka fantasai, Florian Rivoal, Fuqiao Xue (W3C), Geoffrey Creighton (Microsoft), Geoffrey Snedden, Giri Mandyam (Qualcomm), Gregg Kellogg, Hadley Beeman, Helene Workman (Apple), Henri Sivonen (Mozilla), Håkon Wium Lie (Opera Software), Ian Hickson (Google), Ian Jacobs (W3C), Ivan Herman (W3C), J Alan Bird (W3C), Jay Kishigami 岸上順一 (NTT), Jean-Charles Verdié (MStar), Jean-François Abramatic (IBM, ILOG, W3C), Jeff Jaffe (W3C), Jim Bell (HP), Jim Miller (W3C), Joe Hall (CDT), John Klensin (MCI), Josh Soref (BlackBerry, unaffiliated), Judy Brewer (W3C), Judy Zhu 朱红儒 (Alibaba), Kari Laihonen (Ericsson), Karl Dubost (Mozilla), Ken Laskey (MITRE), Kevin Fleming (Bloomberg), Klaus Birkenbihl (Fraunhofer Gesellschaft), Larry Masinter (Adobe Systems), Lauren Wood (unaffiliated), Liam Quin (W3C), Léonie Watson (The Paciello Group), Marcos Cáceres (Mozilla), Maria Courtemanche (IBM), Mark Crawford (SAP), Mark Nottingham, Michael Champion (Microsoft), Michael Geldblum (Oracle), Mike West (Google), Mitch Stoltz (EFF), Natasha Rooney (GSMA), Nigel Megitt (BBC), Olle Olsson (SICS), Ora Lassila (Nokia), Paul Cotton (Microsoft), Paul Grosso (Arbortext), Peter Linss, Peter Patel-Schneider, Philippe Le Hégaret (W3C), Qiuling Pan (Huawei), Ralph Swick (W3C), Renato Iannella (IPR Systems), Rigo Wenning (W3C), Rob Sanderson (J Paul Getty Trust), Robin Berjon (W3C), Sally Khudairi (W3C), Sam Ruby (IBM), Sandro Hawke (W3C), Sangwhan Moon (Odd Concepts), Scott Peterson (Google), Steve Holbrook (IBM), Steve Zilles (Adobe Systems) Steven Pemberton (CWI), TV Raman (Google), Tantek Çelik (Mozilla), Terence Eden (Her Majesty’s Government), Thomas Reardon (Microsoft), Tim Berners-Lee (W3C), Tim Krauskopf (Spyglass), Travis Leithead (Microsoft), Virginia Fournier (Apple), Virginie Galindo (Gemalto), Wayne Carr (Intel), Wendy Fong (Hewlett-Packard), Wendy Seltzer (W3C), Yves Lafon (W3C).

13. 変更点
Changes

この節は規範ではありません.

This section is non-normative.

2020年9月15日版の手続き文書からの変更点
Changes since the 15 September 2020 Process

この文書は, 2020年9月15日版の手続き文書を基にしています. 処理された課題の一覧, また同様にそれ以降の全ての変更の詳細な記録が利用できます. 従前のものとの差分も参照して下さい.

This document is based on the 15 September 2020 Process. A list of issues addressed, as well as a detailed log of all changes since then are available. See below for diffs.

次に示すものは, 主な相違点の要約です.

The following is a summary of the main differences:

データ一覧工程
Registries Track

データ一覧と呼ばれる技術報告書の新しい種類を導入しました. この報告書は, 何も規範的な実装の要件を持たず, 更新するのに特定の執行できる決まりを必要とする, 値または他のデータを一覧にまとめたものについて述べた文書です.

Introduced a new class of technical reports called registries, for documents that describe collections of values or other data that have no normative implementation requirements, yet need specific and enforceable rules about how they are updated.

勧告工程
Recommendation Track

勧告工程に対し, 少しの明確化と重要でない単純化を行いました.

Made a small clarifications and minor simplifications to the Recommendation Track:

• 修正勧告を廃止しました. この手続きは, 使用されたことは無く, 事務局に, 文書を維持管理するために作業部会が無くなった場合の規範的な変更を伴う勧告の更新を認めていました. このことを改正候補を通じて実施できるようにしました.
  Retired Amended RECs: this process, which had never been used, allowed the Team to do update a REC with normative changes in the absence of a Working Group, in order to maintain the document. This ability is now provided through candidate amendments.
• “追加候補”の間違った利用方法が, 同じ意味の“変更候補”に訂正されました.
  An incorrect use of “Proposed Additions” has been corrected to the intended “Proposed Changes”.
• § 6.3.11.4 勧告の改訂:新しい機能の文章の一部が, 規範的な変更無しに他の節との冗長性を減らすよう書き換えられました.
  Some text in section § 6.3.11.4 Revising a Recommendation: New Features has been rewritten to reduce redundancy with other sections, with no normative change.
• “変更”候補と “変更” 案は, 改正候補と改正案に名前が変更されました.
  Candidate and proposed “changes” have been renamed into candidate and proposed amendments.
• 断念された完了していない技術報告書の位置付けの節に, 何が起こったか想像できるよう編集上明確化しました.
  Added an editorial clarification to what is supposed to happen to the status section of unfinished technical reports that get abandoned.

メモ工程
Note Track

勧告工程からメモ工程を切り離し, 若干の将来性を加えました.

Disentangled the Note Track from the Recommendation Track, and added a few capabilities:

• 中止された勧告工程に, その状態を示すためにメモを使用する代わりに, 公式の状態(中止草案)を新たに作成しました.
  Created dedicated status (Discontinued Draft) for discontinued REC Track documents, instead of using Notes for that purpose.
• (メモと異なり, 特許指針によって保護され, 関連部会によって発行することができない)勧告工程の草案の代わりに, その状態に対して草案メモを作りました.
  Made Draft Note into its own status, instead of using REC Track Working Draft (which, unlike Notes, is covered by the Patent Policy, and cannot be published by Interest Groups) for that purpose.
• TAGと ABにメモを発行することを認めました(TAGに対してこのことは実態として既に認められていましたが, 手続き文書の決まりと矛盾していました).
  Allowed TAG and AB to publish Notes (for the TAG, this was already an allowed practice, inconsistent with the letter of the Process).
• ACの審査を通して, W3C全体から支持されたメモであるW3C声明を新たに作成しました.
  Created W3C Statements, which are Notes endorsed by the W3C as a whole, through an AC Review.
• どのように技術報告書が(コピー・貼り付けではなく)工程を切り替えるか定義しました.
  Defined how technical reports can switch tracks (other than by copy & paste).
• 事務局が, 管理者のいないメモの限定的な維持管理をできるようにしました.
  Enabled the Team to do limited maintenance on orphaned Notes.

管理と運用
Governance and Operations

• ACの委員に代理人を指名することを認めました.
  Allowed AC representatives to designate an alternate.
• 会議の録音等, 議事録, 決議の要件を定義しました.
  Defined requirements for recording of meetings, minutes, and resolutions.
• W3Cの発行物の永続的な利用を確かなものにし, 利用と効果的な参照を誰からでも可能にするために, 発行と協同のために使用するツールの手引きを定義しました.
  Defined guidelines for any tooling used for publication and collaboration in order to ensure long-lived access to W3C publications, and to enable access and effective participation by anyone.
• どのようにABが議長を選ぶのかを変更し, CEOが議長でない場合であってもABの会議に招待されることを確実にしました.
  Changed how the AB selects its chair, and made sure the CEO is invited to AB meetings even if they are not the chair.
• § 4.1 憲章の開発の提案と§ 4.3 憲章の諮問委員会による審査で, 憲章への意見のための公開の経路の存在を承認しました.
  Acknowledged existence of public channels for charter comments in § 4.1 Initiating Charter Development and § 4.3 Advisory Committee Review of a Charter.
• 単に憲章が再開された部会の従前の参加者で, 正式に再度参加していない参加者に参加の要請から45日の間に開催される会議に出席し続けることを認めている特許指針のFAQの文言と統一しました.
  Integrated language from the Patent Policy FAQ allowing prior participants of a group that was just rechartered and who have not yet formally rejoined to continue to attend meetings held within a 45-day window of the call for participation.
• 会員の要件について手続き文書の規範的な参照が, 変更することができないか, 更新に対する正式な会員の承認を通さなければならない, 文書への(日付付きの)参照を通して行われることを確実なものにします.
  Make sure that normative references of the Process with requirements on members are either made through (dated) references to documents that cannot change or must go through formal member approval for updates.

多種多様な編集上の微調整, 明確化, 単純化
Miscellaneous editorial tweaks, clarifications, and simplifications

若干の植字および文法のおかしな箇所が処理され, 単純化または明確化する試みの中で, 場所によっては言い換えられました. 特に次のところです.

A few typos and grammatical oddities have been addressed, and some parts have been rephrased or adjusted in an attempt to simplify or clarify. Notably:

• 懲戒について述べた文書の様々な部分が, 単独の節§ 3.1.1.1 期待と懲戒に統合されました.
  The various parts of the document that talked about discipline have been consolidated into a single section, § 3.1.1.1 Expectations and Discipline.
• 選挙で選ぶ場合に登場する“短い任期”と“未完了の任期”への参照が, “未完了の任期”に統合されました.
  References to “short terms” and “incomplete terms” for serving on elected bodies have been unified to “incomplete terms”.
• 手続き文書で本質的な効果を持たないディレクターの名前を挙げている箇所が削除されました.
  Mentions of the Director which had no material effects on the Process have been removed.
• あいまいな“他の憲章”という言葉を“除外された草案の憲章”で置き換えました.
  Replaced the vague “Other Charter” term with “Exclusion Draft Charter”.
• 古い投票システムについての外れた文を削除しました.
  Removed a stray sentence about the old voting system.
• しばらくの間放置されてきたこの文書の導入が, 導入としての役割を満たすように更新・再編成されました.
  The introduction to the document, which had been neglected for some time, has been updated and reorganized to better fulfill its role as an introduction.
• 対等な審査部会がどのように作業するのか詳しく述べた外部文書への参照を§ 6.2.2.1 広範囲にわたる審査に加えました.
  A reference to an external document detailing how to work with Horizontal Review groups has been added to § 6.2.2.1 Wide Review.

主要な編集上の再編成
Major editorial reorganization

上で詳しく述べた個々の変更に加えて, 今回の更新は, 文書の構成の大規模な編集上の再編成を含んでいます. 今回の更新は, 長年にわたる内容のゆるやかな増大によって仕上がったものより, 理解しやすく行き来しやすい目次を作成するため, 既存の文章の様々な部分を再整理しました.

In addition to the individual changes detailed above, this update includes a large editorial reorganization of the structure of the document. It rearranges various parts of the existing text in order to create a more easily understandable and navigable table of contents than the one we had ended up with through many years of gradual accretion of content.

この再編成の詳細に興味を持った方には, ソースコードの差分を提供することに加えて, 細かい水準での変更の概要を示しているGitHubの対応するプルリクエストを調べることをお勧めします.

Anyone interested in the details of this reorganization is invited to consult the corresponding pull request in GitHub, which outlines the changes at a high level in addition to providing a source diff.

編集上の再編成は, 手続きCGにより, 幅広い関係者による最終審査の前に, 工程の最後の変更として溶け込みました. 結果として生じる文書は, 一般社会に読んで審査してもらいたい一方, 重要なたくさんの文章を変更することは, 完全な2020年版の手続き文書とこの最新版との差分が大き過ぎて使用に適さないことを意味します. そこで, 再編成は別とした変更の詳細な審査が可能なように, 再編成する前の2021版の手続き文書草案の最後の状態および2020年版の手続き文書と再編成する前の状態の文書との差分が利用可能です.

The editorial reorganization was merged by the Process CG as the last change in the cycle, prior to final review by the broader community. Although this resulting document is the preferred one to read and review in general, moving significant amounts of text around means that the full diff from Process 2020 to this latest version is largely unusable. Therefore the last state of the Process 2021 Draft prior to the reorganization, as well as a diff between Process 2020 and the pre-reorg state of the document are also available, to enable detailed review of the changes aside from the reorganization.

従前のバージョンからの変更点
Changes since earlier versions

手続き文書の従前のバージョンからの変更点は, 手続き文書の従前のバージョンの変更点の節で詳細に述べています.

Changes since earlier versions of the Process are detailed in the changes section of the previous version of the Process.