W3C手続き文書
W3C Process Document

特許指針やその他の指針に対する手続き文書の関係
Relation of Process Document to Patent Policy and Other Policies

W3C会員が考慮すべきことは, 手続き文書の規定が, 会員規約 [会員規約]を通して会員を拘束するという事実によるものです. 手続き文書の一部として標準の参考文献によって組み込まれているW3C特許指針[特許指針]やその他の指針は, 手続き文書同様に拘束します.

W3C Members' attention is called to the fact that provisions of the Process Document are binding on Members per the Membership Agreement [MEMBER-AGREEMENT]. The W3C Patent Policy [PATENT-POLICY] and other policies incorporated by normative reference as a part of the Process Document are equally binding.

特許指針やCEPCは, W3Cの会員, 事務局, 他の参加者に追加の義務を付しています. 手続き文書は, それら必要なことを言い直していませんが, 参照を含んでいます. 手続き文書, 特許指針, CEPCは, それぞれ独立して効力があるように設計されています.

The Patent Policy and CEPC place additional obligations on Members, Team, and other participants in W3C. The Process Document does not restate those requirements but includes references to them. The Process Document, Patent Policy, and CEPC have been designed to allow each to evolve independently.

手続き文書において, “参加者”という用語は, 個人を指しており, 団体を指していません.

In the Process Document, the term “participant” refers to an individual, not an organization.

適合と特別な用語
Conformance and specialized terms

用語しなければなりません(must), してはなりません(must not), すべきです(should), すべきではありません(should not), 必須です(required), してもよいです(may)は, RFC 2119と一致するように用いられています. 用語必須ではありません(not required)は, RFC2119 [RFC2119]で定義されている用語してもよいです(may)と等価です. (訳注:英語の助動詞などの意味合いを定義しているものですが, 日本語訳では文脈などから自然な日本語となるよう100%一致させているわけではありません.)

The terms must, must not, should, should not, required, and may are used in accordance with RFC 2119. The term not required is equivalent to the term may as defined in RFC2119 [RFC2119].

用語の中には, それらの用語がW3Cの手続きに特別に関係する存在であることを示すために, この文書(や他のW3Cの資料)で大文字で書かれているものもあります. それらの用語はこの文書で定義されており, 読者は, 通常の言葉の定義では, この文書を理解するために不十分であることを覚えておくべきです.

Some terms have been capitalized in this document (and in other W3C materials) to indicate that they are entities with special relevance to the W3C Process. These terms are defined within this document, and readers are reminded that the ordinary English definitions are insufficient for the purpose of understanding this 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 each 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, 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 participates in the Advisory Committee which oversees the work of 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 website [MEMBER-HP].

2.1.2. 会員連合と関連会員
Member Associations and Related Members

2.1.2.1. 会員連合
Membership Associations

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

A “Member Association” 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 Association merely because it has shareholders or stockholders. If it is not clear whether a prospective Member qualifies as a Member Association, the CEO may reasonably make the determination. For a Member Association, the rights and privileges of W3C Membership described in the W3C Process Document extend to the Member Association's paid staff and Advisory Committee representative.

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

Member Associations 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 Associations 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 Associations 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 Association, IPR commitments are made on behalf of the Member Association, 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 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は, この文書で述べられている何らかの自分達の役割について, (一般に事務局内の他の人物に)責任を委任してもよいです. 事務局決定は, それらの決定が他の事務局の人員によって進められているときであっても, CEOの権限に由来しています.

The CEO may delegate responsibility (generally to other individuals in the Team) for any of their roles described in this document. Team Decisions derive from the CEO's authority, even when they are carried out by other members of the Team.

事務局の管理, 予算, 他の業務上の決定は, 手続き文書により直接管理されるのではなく, W3C理事会によって定められます.

Oversight over the Team, budgeting, and other business decisions, is provided by the W3C Board of Directors, rather than managed directly by the Process.

注意:理事会の詳細やW3C全体の管理については, W3C規則を参照して下さい.

Note: See the W3C Bylaws for more details on the Board and overall governance of W3C.

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].

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

The CEO 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の活動の中で多くの代表を務めていることになるであろう恐れがある場合に)新しい議長を指名してもよいです.

e 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 Team 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 a 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.

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

In exceptional circumstances (e.g., situations that might jeopardize the progress of a group or create a conflict of interest), the CEO 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 and Archiving 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によって将来参照できるように保存されなければなりません. 部会で提案された, 部会の作業に関連し, 部会の全てのメンバーから参照できるよう意図された他の持続的な文字での議論も, 同様であるべきです. これらの議論は, メーリングリストを通して行われたもの, また, 課題を記録するサービスや, 何らかの同じような公共の場で行われたものを含みます. 議論から参照される資料や議論を理解するために必要な資料は, 議論の記録より厳格でない機密レベルで, 不変のURLで利用可能であるべきです.
  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. Materials referenced from discussions and necessary to understand them should be available at a stable URL, at a level of confidentiality no stricter than the discussion minutes.

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

  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 W3C at large. It is responsible for:

• 各諮問委員会の会議におけるW3Cの計画の審査.
  reviewing plans for W3C at each Advisory Committee meeting.
• 憲章の提案, 勧告案, 手続き文書案といったW3Cの正式な提案の審査.
  reviewing formal proposals of 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 Team'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 website.

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

諮問会議は, 計画, 管理, 法的問題, 手続き, 利益衝突の解決の課題において, 事務局に継続的な助言を提供しています. 諮問会議は, 諮問委員会で挙げられた課題を追跡したり, そのような課題に会員の意見を求めたり, それらの課題を解決するための活動を提案したりすることで, 会員のために尽くしてもいます. 諮問会議は, 手続き文書の発展を管理しています. W3C評議会の一部として, 諮問会議の委員は, 提案の抗議や正式な異議を聴取し決着をつけます.

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. As part of a W3C Council, members of the Advisory Board hear and adjudicate on Submission Appeals and Formal Objections.

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

The Advisory Board is distinct from the Board of Directors and has no decision-making authority within W3C; its role is strictly advisory.

注意:AB自体は, 決定を行う権限を持っていない一方, 委員がW3C評議会の職に就いているときには権限を持っています.

Note: While the AB as such does not have decision-making authority, its members do when sitting as part of a W3C Council.

諮問会議の詳細(例えば, 諮問会議の委員の一覧, メーリングリストの情報, 諮問会議の議事の要約)は, 諮問会議ホームページ [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の無記名投票による2/3の承認を条件としています. 議長の選定は, 少なくとも毎回の任期の最初に, もしくは, 委員の過半数の要請が有った場合に実施されなければなりません. また, 例えば, 議長が辞任する場合や委員の半分以下から要請があった場合など, 現在の議長または事務局が発議したときに実施してもよいです.

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. Chair selection must be run at least at the start of each regular term, as well as when a majority of the participants request it; and may be run at other times when initiated by the current chairs or the Team, for example if a chair steps down or if a minority of the participants make such a request.

事務局は, § 3.4.1 全ての憲章を持つ部会に対する要件で述べるように, 事務局の連絡員を指名します. CEOと事務局の連絡員は全ての通常の諮問会議の会議に永続的に招待されます.

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.1.4. 諮問会議と理事会の連絡員
Liaisons between the Advisory Board and the Board of Directors

ABと理事会の間の意思疎通を良くし, 運営上, 管理上の一貫性を確実にするために, ABは, 2名の委員を理事会の連絡員として指名してもよいです. そのような指名された者は, 理事会の会議に出席して参加し, 投票しない立会者として理事会の資料を確認することが期待されます. [規則] 指名された者は, 理事会の決定を行う主体を形作らず, 効力のある理事会の手続きと整合を取るために, 参加者から除外されてもよいです.

To ensure good communication between the AB and the Board of Directors and facilitate operational and management consistency, the AB may appoint up to two of its participants as liaisons to the Board. Such appointees are expected to attend and participate in Board meetings and access Board materials as Non-voting Observers. [BYLAWS] They do not form part of the Board's decision-making body, and may be excluded from such participation in accordance with applicable Board procedures.

諮問会議は, 少なくとも毎回の任期の最初に, この役割に誰が指名されるか再評価すべきで, 適切と考えるもっと多い頻度で指名した者を交替させてもよいです.

The Advisory Board should reevaluate who is assigned to this role at least at the beginning of each term, and may swap its appointees more frequently as they deem appropriate.

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.

W3C評議会の一部として, TAGの委員は, 提案の抗議と正式な異議を聴取し決着をつけます.

As part of a W3C Council, the members of the TAG hear and adjudicate on Submission Appeals and Formal Objections.

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;
• 事務局に指名された3名の委員.
  Three participants appointed by the Team;
• 諮問委員会により, AB/TAG 推薦と選挙の手続きに従って選任された8名の委員.
  Eight participants elected by the Advisory Committee following the AB/TAG nomination and election process.

TAGの委員は, 合意により議長または共同議長を選定します. 合意されていない場合, 事務局が, TAGの議長または共同議長を指名します. 議長または共同議長は, TAGの委員から選ばれなければなりません. 議長の選定は, 少なくとも毎回の任期の最初に, もしくは, 委員の過半数の要請が有った場合に実施されなければなりません. また, 例えば, 議長が辞任する場合や委員の半分以下から要請があった場合など, 現在の議長または事務局が発議したときに実施してもよいです.

Participants in the TAG choose by consensus their Chair or co-Chairs; in the absence of consensus, the Team appoints the Chair or co-Chairs of the TAG. The Chair or co-Chairs must be selected from the participants of the TAG. Chair selection must be run at least at the start of each regular term, as well as when a majority of the participants request it; and may be run at other times when initiated by the current chairs or the Team, for example if a chair steps down or if a minority of the participants make such a request.

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

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年間続きます. 任期はずれているので, 隔年で, 4名の選任された委員の任期と, 1名もしくは2名の指名された委員の任期が終了します. 誰か個人が未完了の任期を埋めるために指名されたか選任されたならば, その個人の任期は, その任期の通常の満期に終了します.

The terms of TAG participants last for two years. Terms are staggered so that four elected terms and either one or two appointed terms expire each year. 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.

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 Team 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

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

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 announces appointments after the results of the election are known, and before the start of the term, as described in § 3.3.3.4 Technical Architecture Group Appointments.

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

In the case of regularly scheduled elections of the TAG, the minimum and maximum number of available seats are the same: the 4 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. 技術諮問委員会の指名
Technical Architecture Group Appointments

事務局は, 技術諮問委員会の委員のうち3名を指名する責任があります. この仕組みは, 選挙の手続きを補足します. 事務局は, 技術的な背景, 知識, 技能の多様性を含む, 多様でバランスの取れたTAGを持続するために, 指名を利用すべきです.

The Team is responsible for appointing 3 of the participants to the Technical Architecture Group. This mechanism complements the election process. The Team should use its appointments to support a diverse and well-balanced TAG, including diversity of technical background, knowledge, and skill sets.

事務局は, TAGの指名のために積極的に推薦候補を求めるべきです. また, W3C関係者に対して, 熟慮のために推薦候補を提案する全体としての方法を, 利用できるようにしなければなりません. 特に, 少なくとも現在そして新任のTAGの委員, 諮問委員会, 作業部会の議長から意見を求めなければなりません.

The Team should actively seek candidates for appointment to the TAG, and must make available to the W3C community at large a means to propose candidates for consideration, explicitly soliciting input from at least current and incoming TAG members, the Advisory Committee, and Working Group Chairs.

TAGへの指名の制限は, 指名された人は2回以上連続した任期に指名されてはならない追加の制限がある以外は, 選挙で選ばれた委員の制限(§ 3.3.3.2 選挙で選ばれる部会の委員の制限と§ 3.3.3.3 諮問会議と技術諮問委員会の選挙を参照)と同じです. (退任した席を埋めるために使用された不完全な任期は, この制限には含まれません.)

The constraints for appointment to the TAG are the same as for elected participants (see § 3.3.3.2 Elected Groups Participation Constraints and § 3.3.3.3 Advisory Board and Technical Architecture Group Elections), with the additional constraint that a person must not be appointed for more than two consecutive terms. (Partial terms used to fill a vacated seat do not count towards this limit.)

注意:2回連続して指名された任期の制限に達した個人は, TAGで働き続けることを望むならば自由に選挙に参加してもよいです.

Note: Individuals who have reached the limit of two consecutive appointed terms may freely run for election if they wish to continue serving on the TAG.

指名される人の事務局による選定は, ABとTAG両方の無記名投票による, それぞれの3分の2の賛成による承認を前提としています. 通常の定期的な選挙の場合, この承認におけるTAGの委員は, 次の任期の委員です.

The Team's choice of appointee(s) is subject to ratification by secret ballot by both the AB and the TAG, each requiring a two-thirds approval. In the case of regularly scheduled elections, the TAG participants in this ratification are its members for the upcoming term.

通常の定期的な選挙において, 一旦選挙の結果が周知されると選定が始まり, 事務局は, 遅くとも毎回の任期の開始までに承認された指名を発表すべきです. 指名された席が毎回の任期外で退任された場合, 事務局は, 通常の推薦の要請が2ヵ月以内に予定されていない限り, 代わりの人を指名しようと努めるべきです. また, 事務局は, 遅くとも次の定期的な選挙の推薦の要請までに, 承認された指名を発表しなければなりません.

For regularly scheduled elections, selection begins once the results of the elections are known, and the Team should announce the ratified appointment(s) no later than the start of the regularly scheduled term. When an appointed seat is vacated outside of a regularly scheduled election, the Team should seek to appoint a replacement unless a regular Call for Nominations is scheduled within 2 months, and it must announce the ratified appointment no later than the Call for Nominations of the next scheduled election.

3.3.3.5. 証明可能な無作為選択手続き
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.6. 選挙で選ばれる部会の退任
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
• CEOが§ 3.1.1 個人の参加基準の節に示した基準に抵触する過失を犯した委員を解任した場合.
  the CEO 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 Team appoints a replacement.
• 退任された席が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は8名, 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 (8 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 Team appoints (and re-appoints) Chairs for all groups. The Chair is a Member representative, a Team representative, or an Invited Expert, (invited by the Team). The requirements of this document that apply to those types of participants apply to Chairs as well.

注意:議長の役割 [議長]は, 合意の要領 [案内]で述べられています.

Note: 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.

注意:事務局の連絡員の役割 [事務局の連絡員]は, 合意の要領 [案内]で述べられています.

Note: 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.

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

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 CEO 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
• 議長またはCEOが参加の招待を取り消すまで.
  the Chair or CEO 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 Team 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 Team 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

提案された作業部会や関連部会の憲章を採用するかどうか決めることは, W3C決定です. 参加の要請の前に, 憲章は, § 5.7.2 審査期間の終了後を通じて審査意見によって修正されてもよいです.

Deciding whether to adopt a proposed Working Group or Interest Group charter is a W3C Decision. Charters may be amended based on review comments per § 5.7.2 After the Review Period before the Call for Participation.

決定が部会を認可するものだった場合, 事務局は, 参加の要請を諮問委員会に発しなければなりません. 新しい部会に対して, この要請の発表は, 公式に部会を作ります. その発表は, 憲章への参照, 部会の議長(ら)の名前, 事務局の連絡員(ら)の名前を含まなければなりません.

If the decision is to charter the group, the Team must issue a Call for Participation to the Advisory Committee. 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

事務局は, 何も他の実質的な修正無しに, 作業部会または関連部会の憲章を延長することを決定してもよいです. 事務局は, 諮問委員会にそのような延長を通知しなければなりません. また, その通知は, 新しい期間を示さなければなりません. その通知は, 延長の根拠, 憲章, (部会の議長(ら)の名前, 事務局の連絡員(ら)の名前, 部会に参加する場合の説明を含む)部会のホームページへの参照を含まなければなりません.

The Team may decide to extend a Working Group or Interest Group charter with no other substantive modifications. The Team must announce such extensions 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, and the Group homepage (which includes at least 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 Team 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.

事務局, TAG, ABは, 次のいずれかの状況において, 憲章で指定された期日以外を優先して, 部会を終了することを提案してもよいです.

The Team, the TAG, or the AB may propose to close a group prior to the date specified in the charter in any of the following circumstances:

• W3Cの中で認められた優先順位によって, 憲章に書かれた成果を生み出したり, 部会を管理したりするのに不十分な会員の資源しか無い場合.

  There are insufficient member resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C.

• 特許助言部会が, 作業は終了されるべきだと結論を下した場合.

  A Patent Advisory Group concluded that the work should be terminated.

• TAGまたはABが, 憲章を持つ部会の運営やその作業を続けることが, W3Cやその使命にとって有害だろうと判断した場合.

  The TAG or AB determined that continuing operation of the chartered group or its work would be detrimental to W3C or its mission.

• 部会が憲章に書かれた全ての成果を, 予定よりも早く生み出した場合.

  The group produced all chartered deliverables ahead of schedule.

部会を終了するそのような提案は, 根拠を伴わなければならず, 提案はACの審査によってW3C決定として承認されなければなりません.

Such a proposal to close a group must be accompanied by rationale, and the proposal must be confirmed by an AC Review as a W3C Decision.

作業部会を終了することは, 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”).

この手続き文書に関連して事務局の人員によって行われる決定で, その個人の, または共同での判断に基づくものは, 事務局決定と呼ばれます.

Decisions made by members of the Team in connection with this Process, based on their own individual or collective judgement, are called Team Decisions.

対照的に, W3C決定は, 諮問会議の審査の後にW3C会員の合意を評価し, W3C会員の支持に基づいて事務局が決定します.

In contrast, a W3C decision is determined by the Team on behalf of the W3C community by assessing the 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は, 諮問委員会の中の合意を判断する役割があります.

Note: The CEO has 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 there is no sustained objection from anybody in the set. 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 sustains an objection.

注意: 正式な異議は, 唱え続けられている異議を常に指しますが, (正式なACの審査の状況以外で)異議を表す必要はありません. ただし, 提案された決定に対する異議は, 個人が反対を表明していたとしても, 決定を受け入れようと決心することもできるので, 唱え続けられている異議の水準に常にある訳ではありません.

Note: A Formal Objection always indicates a sustained objection, but isn’t necessary to express it (except in the context of formal AC Reviews). Disagreement with a proposed decision, however, does not always rise to the level of sustained objection, as individuals could be willing to accept a decision while expressing disagreement.

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

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

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

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 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.

注意: 反対者は, 正式な異議を登録することで, 決定に対し唱え続けている異議を強めることもできます.

Note: Dissenters can escalate their sustained objection to a decision by registering a Formal Objection.

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. 正式な異議の登録
Registering Formal Objections

(会員と関連しているかどうかに関係なく)誰でも, 事務局に正式な異議を登録することで(他の抗議の手続きが決まっている場合を除いて)この手続き文書に関連して何らかの決定に抗議してもよいです. 部会の参加者は, 事務局の連絡員もしくは部会の議長に通知すべきです. 事務局の連絡員は, 部会の参加者がしかるべき手続きに懸念を示している場合, CEOに通知しなければなりません.

Any individual (regardless of whether they are associated with a Member) may appeal any decision made in connection with this Process (except those having a different appeal process) by registering a Formal Objection with the Team. Group participants should inform their Team Contact as well as the group’s Chair(s). The Team Contact must inform the CEO when a group participant has also raised concerns about due process.

注意: この文書において, 正式な異議という用語は, 手続き文書との関連を強調するために使用しています. 正式な異議は, 正式な熟慮と正式な回答を受け取ります. 単独で用いられる“異議”という言葉は, 通常の言葉(訳注:原文では英語)の意味を持ちます. § 5.2 合意形成を参照して下さい.

Note: In this document, the term Formal Objection is used to emphasize this process implication: Formal Objections receive formal consideration and a formal response. The word “objection” used alone has its ordinary English connotations. See § 5.2 Consensus Building.

正式な異議は, (技術的または手続き上の)課題の要約, 抗議する決定, 異議の根拠を含まなければなりません. また, 技術的な論点や正式な異議を取り除く変更案を引き合いに出すべきです. それらの案は, あいまいだったり不完全だったりしてもよいです. 本質的な論点や根拠を提供しない正式な異議は, 真剣な考慮を受けられそうにないです. 反対意見, 根拠, 決定も, 記録されるべきです.

A Formal Objection must include a summary of the issue (whether technical or procedural), the decision being appealed, and the rationale for the objection. It 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. Counter-arguments, rationales, and decisions should also be recorded.

公表された文書と考えられる決定に対する各正式な異議の記録は, 公表されなければなりません. 同様に会員のみが見ることのできる決定に対する各正式な異議の記録は, 会員が利用できなければなりません. 諮問委員会に対する審査の要請は, その審査に関係する正式な異議を特定しなければなりません.

A record of each Formal Objection against a decision regarding a publicly-available document must be made publicly available; likewise, a record of each Formal Objection against a Member-visible decision must be made available to Members. A Call for Review to the Advisory Committee must identify any Formal Objections related to that review.

注意: 技術報告書の中身対する正式な異議は, 技術報告書の進展を要求する前に処理する必要があります.

Note: Formal Objections against matter in a technical report are required to be addressed before requesting advancement of the technical report.

諮問委員会の審査の間に提出された正式な異議は, 審査期間が終了するときに登録されると考えられます.

A Formal Objection filed during an Advisory Committee Review is considered registered at the close of the review period.

5.6. 正式な異議の処理
Addressing Formal Objections

5.6.1. 事務局による調査と調停
Investigation and Mediation by the Team

事務局は, 問題や様々な観点がより良く, 可能な限り広範囲に理解されることを確実にし, 推奨される措置に到達するように, 正式な異議を熟慮し, 疑問点を調査し, 関係者と面談するなどします. 正式な異議を提出した人が満足いくように, 事務局が課題を解決したならば, その人は異議を取り下げ, 手続きは終了します.

The Team considers the Formal objection, researches the question, interviews parties, and so on, to make sure the problem and the various viewpoints are well understood, and to the extent possible, to arrive at a recommended disposition. If the Team can resolve the issue to the satisfaction of the individual that filed the Formal Objection, the individual withdraws the objection and the disposition process terminates.

そうでない場合, 合意を見出すことができなかった後, 正式な異議が登録されてから遅くとも90日以内に, 事務局は, W3C評議会の編成を発議しなければなりません. その評議会は, 発議から45日以内に召集されるべきです. 同時に, 事務局は, 合意を見出すために, 事実と試みを文書にした評議会への報告書を準備します.

Otherwise, upon concluding that consensus cannot be found, and no later than 90 days after the Formal Objection being registered, the Team must initiate formation of a W3C Council, which should be convened within 45 days of being initiated. Concurrently, it must prepare a report for the Council documenting its findings and attempts to find consensus.

5.6.2. W3C評議会
W3C Council

W3C評議会は, AB, TAG, 事務局の能力と客観性を組合せることで, 正式な異議を解決しようと召集される組織です. そして, ウェブとW3Cのために, 解決する役割を課されています.

A W3C Council is the body convened to resolve Formal Objections by combining the capabilities and perspectives of the AB, the TAG, and the Team, and is tasked with doing so in the best interests of the Web and W3C.

5.6.2.1. 評議会の構成
Council Composition

毎回のW3C評議会は, (放棄したり解任されたりした場合を除いて)次の人々から構成されます.

Each W3C Council is composed of the following members (excepting any renounced or dismissed):

• CEOまたはCEOが選んだ事務局の代理人

  the CEO or their chosen Team delegate

• 諮問会議の委員

  the members of the Advisory Board

• 技術諮問委員会の委員

  the members of the Technical Architecture Group

W3C評議会の委員は, 対面の会議の出席は必要としてはなりません.

Participation in a W3C Council must not require attendance of face-to-face meetings.

W3C評議会における個々の評議会は, 抗議または反対された決定ごとに召集されます. 毎回の評議会の委員の身分は, 構成時に固定され, 評議会が結論に達する前に実施されたABやTAGの選挙では変更されません. ただし, 評議会の委員が効果的でバランスの取れた審議の妨げとなるようになった場合, W3C評議会の議長は, 評議会を解散し, 新たな委員の召集を要請すべきです.

A distinct instance of the W3C Council is convened for each decision being appealed or objected to. Membership of each Council instance is fixed at formation, and is not changed by any AB or TAG elections occurring before that Council has reached a conclusion. However, if participation in a Council falls so low as to hinder effective and balanced deliberations, the W3C Council Chair should dissolve the Council and call for a new one to be convened.

事務局の人員は, 評議会を手助けし, この手続き文書に対する支持を促進するために, 評議会の事務局の連絡員として行動するために指名されます.

A Team member is assigned to act as the Council Team Contact, to support this Council and to facilitate adherence to this Process.

5.6.2.2. 特別な委任
Extraordinary Delegation

特別な場合において, 評議会が決定を下す機関として適切でないと感じたなら, (特に法的助言においては)事務局の人員は, または何らかの評議会の委員候補は, 特定の正式な異議に対する決定を, W3C理事会, (法的助言については)行政機関幹部, 事務局の1人以上の人員に委任することを提案してもよいです. その場合, 評議会の委員候補は, 内密に議論してもよく、特定の正式な異議に対する決定を委任するかどうか投票で決めなければなりません. 委任する決定は, 3分の2以上の支持(すなわち, 少なくとも支持が反対の倍)を集めなければなりません. こういった場合の委任は, 後で無効にすることはできません.

In extraordinary cases, if they feel a Council would not be the appropriate deciding body, a member of the Team (particularly the Legal Counsel) or any potential Council member may suggest that the decision for that specific Formal Objection be delegated to the W3C Board of Directors, to an officer of its corporation (such as the Legal Counsel), or to one or more specific individuals from the Team. The potential Council members then may confidentially discuss and must vote whether to delegate the decision for that specific Formal Objection. A decision to delegate must be supported by a two-thirds supermajority vote (i.e., at least twice as many votes in favor as against). Delegation in such cases cannot be later revoked.

事務局は, いつ正式な異議が委任されたか, 誰に委任されたか, 諮問委員会に通知しなければなりません.

The Team must inform the Advisory Committee when a Formal Objection has been delegated, and to whom it has been delegated.

5.6.2.3. 評議会の参加, 解任, 放棄
Council Participation, Dismissal, and Renunciation

評議会の委員候補は, 評議会から解任されてもよいです. 一貫した基準を適用するために, 評議会の委員候補らは, 業務に対する何の理由が委員候補を解任するのに十分か団結して決めます. 誰も自動的に解任されず, 個人的な拒否は評議会では行えません. 解任は, 特定の評議会において個人に適用され, 評議会の最大限の多様性を保つために滅多に使用されるべきではありません.

A potential Council member may be dismissed from the Council. In order to apply consistent criteria, the potential Council members decide collectively which reasons against service rise to a sufficient level for a potential member to be dismissed. No-one is automatically dismissed, and individual recusal is not used in the Council. Dismissal applies to an individual person in the context of a specific Council, and should be used rarely in order to preserve the greatest diversity on the Council.

注意:W3C評議会は, ウェブやW3Cのために最善の方法を見つけることを目的とした討議する期間です. 正しいか間違っているかを決めることを課された裁定を下す機関ではありません.

Note: A W3C Council is a deliberative body whose purpose is to find the best way forward for the Web and for W3C. It is not a judicial body tasked with determining right or wrong.

事務局は, 各候補を解任する考えられる理由の注釈を付けて, 評議会の解任候補の一覧を起草しなければなりません. 会員, 事務局, 評議会の委員候補を含むW3Cの関係者は, この一覧に対して考えられる理由を述べる機会を与えられなければなりません. 影響する委員は, 自分自身に対するそれらの意見に返答する機会を与えられなければなりません. 事務局は, 意見を言葉通りに, または, それらの言葉の意図を保つように言い換えて報告してもよいです. また, 適用される法令や[CEPC]に違反するであろう不適切な意見は無視してもよいです.

The Team must draft a list of potential Council members, with annotations of possible reasons for dismissal against each one. The W3C community, including members and team, and potential council members, must be given an opportunity to contribute possible reasons to this list. Affected members must be given an opportunity to respond to such comments about themselves. The Team may report comments verbatim or may paraphrase them while preserving their intent; they may also elide inappropriate comments, such as any that violate applicable laws or the [CEPC].

評議会が形成される前, 事務局は, 委員候補の完全な一覧と, 評議会の委員候補に対して集められた理由と返答を提出します. 委員候補は, 各委員候補に対してその候補の参加が評議会の決定の誠実さを危うくするかどうか熟慮し, 委員候補を解任するかどうか投票します. 誰も, 自身の解任に投票することは認められていません. 各候補は, 棄権を除いて単純に過半数によって決定されます.

Before a Council forms, the Team presents the entire list of potential members and collected reasons and responses to the potential Council members, who then consider for each potential member whether that individual’s participation would compromise the integrity of the Council decision, and vote whether to dismiss that potential member. No one is allowed to vote on their own dismissal; each dismissal is decided by simple majority of those not abstaining.

注意:解任は個別のものなので, 反対されている決定が, 決定の主体として機能するTAGやABによってされた場合, TAG全体やAB全体は, 解任されることが期待されたり必要とされたりしません.

Note: Since dismissal is individual, when the decision being objected to was made by the TAG or AB acting as a body, the entire TAG or AB is not expected or required to be dismissed.

また, 候補は, 雇用主から委員を努めることを禁止されるといった強い理由によって, 評議会の席を放棄ししてもよいです. 候補は, 放棄を説明する範囲を選びます. 放棄は, 参加の欠格事由で棄権ではなく, 不参加を許すために使われるべきではありません.

An individual may also renounce their seat on a Council, for strong reason, such as being forbidden by their employer to serve. The individual chooses the extent to which they explain their renunciation. Renunciation is disqualification from participation, not abstention, and should not be used to excuse an absence of participation.

解任された, または席を放棄した人は, 評議会の資料を受け取らず, 審議の一部も行わず, 合意の決定において手助けせず, 投票しません. それでも, W3C評議会は, W3C関係者の1人として証言を求めたり聞き取りしたりしてもよいです.

Any person who has been dismissed or who renounces their seat does not receive Council materials, take part in its deliberations, help in the determination of consensus, or vote. The W3C Council may still solicit and hear their testimony, as they can of anyone else in the W3C community.

5.6.2.4. 全員一致の短い審議期間
Unanimous Short Circuit

評議会の手続き全体は, 事務局が解決策を推奨し, 席を放棄していない評議会の全ての委員候補が, その解決策を採用することを(棄権無しに)賛成して投票で決めたのならば, 簡略化されてもよいです.

The full Council process may be short-circuited if the Team recommends a resolution and every potential member of a Council who is not renouncing their seat votes affirmatively (no abstentions) to adopt this resolution.

この手続きは, § 5.6.2.3 評議会の参加, 解任, 放棄と同時に実施され, 議長を選ぶより優先されてもよいです.

This step may be run concurrently with § 5.6.2.3 Council Participation, Dismissal, and Renunciation and prior to choosing a Chair.

注意:評議会の委員は, 例えば, とても平凡だったり重複していたりなどするので, 評議会全体の返答を保証することは考えられず, この状況は特別な状況を意味します.

Note: This is intended for exceptional cases that don’t seem to warrant a full Council response because they are, for instance, too trivial, duplicative, etc.

5.6.2.5. 評議会の議長
Council Chairing

各W3C評議会の議長は, その委員によって, 可能な限り合意に基づいて選ばれ, それらの合意が足りなければ, 投票になります. 議長は, W3C評議会の委員でなければなりません. 議長の選定は, 各評議会が形成されるときに実施され, 評議会の運営の間に評議会の事務局の連絡員か議長によって依頼された場合にやり直されなければなりません.

The Chair of each W3C Council is chosen by its members, by consensus if possible, falling back to a vote if that fails. The chair must be a member of that W3C Council. Chair selection happens during formation of each Council, and must be re-run if requested by the Council Team Contact or by the Chair during the Council’s operation.

5.6.2.6. 評議会の審議
Council Deliberations

W3C評議会の議長の指名と事務局の報告書の引き渡しの後で, W3C評議会は召集されたと見なされ, 審議を始められます.

Upon appointment of the W3C Council Chair and delivery of the Team’s report, the W3C Council is considered to be convened and can start deliberations.

事務局が集めた情報を審査しながら, 評議会は, 追加の調査や解析を行ったり, 追加の情報や事務局も含めた誰かからの聞き取りを依頼してもよいです.

Having reviewed the information gathered by the Team, the Council may conduct additional research or analysis, or request additional information or interviews from anyone, including the Team.

さらに, 評議会は合意の仲介を試みてもよく, 成功したら正式な異議は解決されます.

The Council may further attempt to broker consensus, which, if successful, disposes the formal objection.

そうでない場合, 十分な審議の後, W3C評議会は, 異議を是認するか却下するか決めます. W3C評議会は, 何らかの異議を支持する議論に同意したとしても, 正式な異議を却下してもよいです.

Otherwise, after sufficient deliberation, the W3C Council decides whether to uphold or overrule the objection. The W3C Council may overrule the Formal Objection even if it agrees with some of the supportive arguments.

異議を是認する場合, 評議会は, 前進する方法を推奨すべきです. くつがえされた決定が, 既に影響を与えている場合(例えば, 異議が既に公開された文書の中の資料に影響する場合), 評議会は, どのように影響を和らげるか提案すべきです. 事務局は, 適切な緩和が迅速に行われることを確かなものにする責任を負います. そして, 正式な異議は, これらが行われるまで完全に処理されたとは見なされません.

When upholding an objection, it should recommend a way forward. If the overturned decision has already had consequences (e.g., if the objection concerns material already in a published document) the Council should suggest how these consequences might be mitigated. The Team is responsible for making sure that adequate mitigations are enacted in a timely fashion; and the Formal Objection is not considered fully addressed until then.

注意:このことは, 事務局に文書を“非公開にする”といった新たな権限を生じさせません. 事務局の役割は, 既に処理に取り掛かっているどの方法によってでも, 適切な緩和を生じさせる責任の主体をはっきりさせることです.

Note: This does not create new powers for the Team, such as the ability to “unpublish” documents. The Team's role is to ensure the responsible parties enact adequate mitigations, by whatever means they already have at their disposal.

評議会は, 審議のために, 推奨案を返してもよい小部会を作ってもよいですが, 完全な評議会が最終決定を発します. W3C評議会の決定は, 全員一致であるべきで, 合意の下で発せられてもよいです. ただし, 慎重な審議にも関わらず, W3C評議会が合意に至らなかった場合, W3C評議会の議長が代わりに投票することを訴えてもよいです. その場合, 決定は単純な多数決で行われ, 同数の場合, W3C評議会の議長が投票します. 投票の場合, 同じ所属である評議会の2人の委員が同一の票を入れた場合, それらの票は2票ではなく1票と数えられます.

A Council may form sub-groups for deliberation, who may return with a recommendation, but the full Council issues the final decision. The decision of the W3C Council should be unanimous, and may be issued under consensus. However, if despite careful deliberation a W3C Council is unable to reach consensus, the W3C Council Chair may instead resort to voting. In that case, the decision is made by simple majority, with the W3C Council Chair breaking any tie. In case of a vote, if two members of a Council who share the same affiliation cast an identical ballot, then their ballots count as a one vote, not two.

全員一致でない決定の場合, 決定に同意しなかったW3C評議会の委員は, 同意しなかった理由を説明する少数意見を書いてもよいです.

In the case of non-unanimous decisions, members of a W3C Council who disagree with the decision may write a Minority Opinion explaining the reason for their disagreement.

W3C評議会の審議は, W3C評議会および評議会の事務局の連絡員限定の機密です.

The deliberations of a W3C Council are confidential to that W3C Council and its Council Team Contact.

W3C評議会が召集されてから45日以内に結論に至ることができなかった場合, W3C評議会の議長は, 遅延や議論の状況をACに通知しなければなりません. 加えて, W3C評議会の議長は, その報告を公開してもよいです.

If a W3C Council is unable to come to a conclusion within 45 days of being convened, the W3C Council Chair must inform the AC of this delay and of the status of the discussions. The W3C Council Chair may additionally make this report public.

5.6.2.7. 評議会決定の報告
Council Decision Report

評議会は, 評議会報告書を発行することで完了します. 報告書は次のとおりです.

A Council terminates by issuing a Council Report, which:

• 評議会が異議を是認したか却下したか述べなければなりません.

  must state whether the Council upholds or overrules the objection(s).

• 決定を支持する根拠を提供しなければなりません. 根拠は, 正式な異議の中で挙げられた各論点に取り組むべきです.

  must provide a rationale supporting the decision, which should address each argument raised in the Formal Objection(s).

• 評議会によって決められた推奨案を含まなければなりません.

  must include any recommendation decided by the Council.

• 正式な異議が是認された場合, 提案された緩和措置を含むべきです.

  if the Formal Objection has been upheld, should include any suggested mitigations.

• 少数意見があれば含まなければなりません.

  must include the Minority Opinion(s), if any.

• 解任されたか席を放棄した候補の名前, また, 従事することを制限された候補の名前を報告しなければなりません.

  must report the names of those who were dismissed or renounced their seat as well as those who were qualified to serve.

• 最終決定に参加した個人の名前を報告しなければなりません.

  must report the names of the individuals who participated in the final decision.

• 投票が実施された場合, 投票の数を報告してもよいです.

  may report vote totals, if any vote was held.

• 評議会における主張を個人のせいにしてはなりません.

  must not attribute any position to any individual on the Council.

事務局は, 完了した評議会報告書全てを記録しているW3Cウェブサイトの公開ページを管理しなければなりません. 評議会決定がACの抗議によってくつがえされた場合, そのことも言及されなければなりません. 評議会報告書は, 反対された決定や文書より厳しい機密レベルであってはなりません.

The Team must maintain a public page on the W3C website indexing all completed Council Reports. If a Council decision is later overturned by an AC Appeal, this must also be mentioned. Council Reports must be no more confidential than the decision or document being objected to.

評議会は, 機密の面で追加の意見が有益だろうと思うならば, 大本の報告書より制限された機密レベルで, 補足機密評議会報告書を発してもよいです. ただし, 大本の評議会報告書は, 補足機密評議会報告書への参照無しに, それ自身で十分に理解できるものであるべきです.

The Council may also issue a Supplemental Confidential Council Report with a more restricted level of confidentiality than its main report when it believes that additional commentary on confidential aspects of the case would be informative. However, the main Council Report should be self-sufficient and understandable without reference to Supplemental Confidential Council Reports.

5.6.2.8. 評議会決定への抗議
Appealing Council Decisions

諮問委員会の委員は, 評議会報告書の中で発された評議会決定に対する諮問委員会の抗議を発議してもよいです.

Advisory Committee representatives may initiate an Advisory Committee Appeal of a Council decision issued in a Council Report.

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.

明瞭さのために, ACの審査の状況で, 不同意は正式な異議として表現されなければなりません.

For clarity, in the context of an AC Review, dissent must be expressed as a Formal Objection.

事務局は, 諮問委員会の審査意見のために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決定を決め, 諮問委員会に周知しなければなりません. その周知は, 提案への支持の水準(合意か不同意), 特に何らかの正式な異議があったかどうかを, 正式な異議の機密レベルの変更に注意して示さなければなりません.

After the review period, the Team determines the appropriate W3C Decision, which they must announce to the Advisory Committee. The announcement must indicate the level of support for the proposal (consensus or dissent), and specifically whether there were any Formal Objections, with attention to changing the confidentiality level of the Formal Objections.

正式な異議があり, 少なくとも是認された場合, または, 不十分な支持のために合意されなかった場合, W3C決定は, 次のいずれかにならなければなりません.

If there were Formal Objections, at least some of which were upheld, or if there is not consensus because of insufficient support, W3C Decision must be one of:

• 提案を改善するための発案者への要求と一緒に, 提案は追加の作業のために差し戻されます.
  The proposal is returned for additional work, with a request to the initiator to improve the proposal.
• 提案は却下されます.
  The proposal is rejected.

提案が合意された場合, または, どの正式な異議も撤回されるか却下され, 提案が合意を達成するのに十分な支持を得られた場合, W3C決定は, 次のいずれかにならなければなりません.

If the proposal has consensus, or if any Formal Objections are retracted or overruled and the proposal otherwise has sufficient support to achieve consensus, this W3C Decision must be one of:

• 提案は採用されます. 場合によっては, ACの意見に取り組むためにまとめられた追加の変更を伴います(下記参照).
  The proposal is adopted, possibly with additional changes integrated in order to address the comments of the AC (see below).
• 審査の間に判明した望ましい変更を行い再提案するための発案者への要求と一緒に, 提案は追加の作業のために差し戻されます.
  The proposal is returned for additional work, with a request to the initiator to make desirable changes identified during the review and to resubmit.

提案が, 種類1(マークアップ)の変更以外と一緒に採用されたなら, それらの変更は, ACと(あれば)その文書を所有する部会に周知されなければなりません.

If the proposal is adopted with changes other than class 1 (markup) changes, then those changes must be announced to the AC and to the Group that owns the document (if any).

加えて, まとめられた実質的な変更と一緒に提案を採用したとき, 周知は, 実質的な変更の根拠を含まなければならず, それらの変更は, (明確に棄権した委員も含め)提案に投票したACの委員らの合意を得ていなければなりません. 実質的な変更を導入するACの承認に加えて, (部会の合意や実装の実績といった)条件を持つ発行物に対して, それらの他の条件も再び満たされなければなりません.

Additionally, when adopting a proposal with substantive changes integrated, the announcement must include rationale for the substantive changes, and those changes must have the consensus of the subset of the AC that voted on the proposal (including anyone who explicitly abstained). For publications which have conditions in addition to AC approval for introducing substantive changes (such as Group consensus or implementation experience), those other conditions must also be re-fulfilled.

この文書は, 諮問委員会の審査期間の終了から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 Team 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 stages for Recommendation Track documents and the Process document.

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

Advisory Committee representatives may also initiate an appeal for decisions of a W3C Council, and for certain decisions that do not involve an Advisory Committee review. These cases are identified in the sections which describe the requirements for the decision and include additional (non-reviewed) maturity stages 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.

諮問委員会の委員は, 事務局へ要求を送ることで抗議を提出します. また, 委員は, この要求を諮問委員会に共有すべきです. この要求は, “I appeal this Decision”(訳注:"この決定に抗議する"の意味)と言い, その決定を特定すべきで, その決定に抗議する根拠を含んでよいです.

An Advisory Committee representative initiates an appeal by sending a request to the Team, and should also share this request with the Advisory Committee. The request should say “I appeal this Decision” and identify the decision, and may also include their rationale for appealing the decision.

注意:どのように抗議の要求を事務局とACに伝えるかについて, 勧告に対するW3C決定への抗議を参照して下さい.

Note: See Appealing a W3C Decision for a recommendation on how to communicate an appeal request to the Team and the AC.

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

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 Decision?” together with links to the 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 の技術報告書一覧 [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 stage, 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 website.

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 Team 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 document. 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. 文書の解釈に機能上影響しない変更

   Changes that do not functionally affect interpretation of the document

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

For Recommendation-track technical reports specifically, this constitutes changes that do not affect conformance, i.e. 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 examples which clearly conflict with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change requirements.

変更が機能上解釈に影響するかどうか, 何らかの疑義や不適合がある場合は, その変更は, この種類ではありません.

If there is any doubt or disagreement as to whether a change functionally affects interpretation, that change does not fall into this class.

3. 新しい機能を追加しないその他の変更

   Other changes that do not add new features

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

For Recommendation-track documents, 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

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

Changes that add new functionality, such as new elements, new APIs, new rules, 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 group decision. 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 stage, 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.

§ 6.3.3 勧告工程における進展で述べるように, 事務局は, 成熟段階を進展させる依頼が進展のための要件に取り組めていないと判断するときは, その依頼を拒否し, 追加の作業のためにその仕様書を作業部会に戻すでしょう.

As described in § 6.3.3 Advancement on the Recommendation Track, the Team will decline a request to advance in maturity stage and return the specification to a Working Group for further work if it determines that the requirements for advancement have not been met.

6.3.1. 勧告工程における成熟段階
Maturity Stages 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:

勧告候補全体版 (CRS)
Candidate Recommendation Snapshot (CRS)

勧告候補全体版は, 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 verification of either a Transition Request (for the first Candidate Recommendation publication from another maturity stage) or an Update Request (for subsequent Candidate Recommendation Snapshots).

勧告候補草案版 (CRD)
Candidate Recommendation Draft (CRD)

勧告候補草案版は, 作業部会がすぐ次の勧告候補全体版に含めることを意図している, 前の勧告候補全体版からの変更をまとめるために, 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.13.3 W3C勧告の断念の工程を実施する必要無しに以前のものを置き換えます. その文書は, 更新された同じ文書です. 文書が置換されたと明確に宣言し, § 6.3.13.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.13.3 Abandoning a W3C Recommendation: it is the same document, updated. Explicitly declaring a documented superseded, using the process documented in § 6.3.13.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.13.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.13.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 Team 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 stage (called Transition Requests), the Working Group:

• 進展を要求する部会決定を記録しなければなりません.
  must record the group’s decision to request advancement.
• 事務局の検証を通らなければなりません. 何らかの手続き文書の要件が取り組まれていなかった場合, (評議会によって是認されたが完全に処理されていないものを含む)何らかの未解決の正式な異議が残っている場合, 文書がW3C評議会(または委任先)の関係する決定全てを十分に反映していない場合, 事務局の検証(事務局決定)は保留されなければなりません. 事務局が遷移要求を却下した場合, その根拠を諮問委員会と作業部会に示さなければなりません.
  must obtain Team verification. Team verification (a Team decision) must be withheld if any Process requirements are not met or if there remain any unresolved Formal Objections (including any upheld by a Council but not yet fully addressed), or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). If the Team rejects a Transition Request it must indicate its rationale to the Advisory Committee and the Working Group.
• 前回の公開以降の技術報告書に対する全ての新しい機能(種類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 stage.
• どの正式な異議の公開の文書も提供しなければなりません.
  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 stage”, so many requirements do not apply, and verification is normally fairly straightforward. For later stages, especially transition to Candidate or Proposed Recommendation, there is usually a formal review meeting to verify that the requirements have been met.

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

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 stage (called Update Requests) require extra verification. 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 合理化された発行承認の規準を満たすかしなければなりません. 何らかの手続き文書の要件が取り組まれていなかった場合, (評議会によって是認されたが完全に処理されていないものを含む)何らかの未解決の正式な異議が残っている場合, 文書がW3C評議会(または委任先)の関係する決定全てを十分に反映していない場合, 事務局の検証(事務局決定)は保留されなければなりません. 事務局が更新要求を却下した場合, その根拠を作業部会に示さなければなりません. 手続き文書の要件を延期した場合, その根拠をACに示さなければなりません.
  must obtain Team verification, or fulfill the criteria for § 6.3.4.1 Streamlined Publication Approval. Team verification (a Team decision), should be withheld if any Process requirements are not met, and may be withheld in consideration of unresolved Formal Objections (including any upheld by a Council but not yet fully addressed) or if the document does not adequately reflect all relevant decisions of the W3C Council (or its delegates). If the Team rejects an Update Request, it must indicate its rationale to the Working Group. If it waives any Process requirements, it must indicate its rationale to the AC.
• どの正式な異議の公開の文書も提供しなければなりません.
  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 verify that the requirements have been met.

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

Note: Update request verification is expected to be fairly simple compared to verification of 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, verification of 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 verification 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, delineating the Candidate Recommendation review period, 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 verification of having met the requirements for 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 a Team Decision,
• 文書が広範囲にわたる審査を受けたことを示さなければなりません.
  must show that the document has received wide review,
• 勧告候補の審査期間に挙げられた全ての課題が, 正式に取り組まれていたことを示さなければなりません.
  must show that all issues raised during the Candidate Recommendation review period 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 Team:

• 勧告案の発行を諮問委員会に周知しなければなりません. また, 仕様書が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.
• 無理やり承認する理由があるのであれば, 勧告案を最小限の実装の実績で承認してもよいです. そのような場合, 事務局は, その決定の理由を説明しなければなりません. また, その情報は, W3C勧告への進展を提案する審査の要請の中に含まれなければなりません.
  may approve a Proposed Recommendation with minimal implementation experience where there is a compelling reason to do so. In such a case, the Team must explain the reasons for that decision, and that information must be included in the Call for Review proposing advancement to W3C Recommendation.

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 Team 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 stages. (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 Working Draft—or, if the relevant criteria are fulfilled, 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 does not allow 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. 勧告工程における後退
Regression on the Recommendation Track

作業部会は, 上で述べられているように, より低い成熟段階への遷移の要件を満たすことで, その成熟段階で勧告工程の技術報告書を再発行してもよいです.

A Working Group may republish a Recommendation-track technical report at a lower maturity stage by fulfilling the requirements to transition to that maturity stage, as described above.

加えて, TAGとABの承認によって, 事務局は, 広範囲にわたる審査や正式な異議に対する反応としてより低い成熟段階へ技術報告書を差戻してもよいです.

Additionally, with the approval of the TAG and the AB the Team may return the technical report to a lower maturity stage in response to wide review or a formal objection.

6.3.13. 勧告工程の文書の断念
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.13.1. 完了していない勧告の断念
Abandoning an Unfinished Recommendation

何らかの勧告工程にある技術報告書が, もはや進展されたり維持管理されたりすることを意図されておらず, 廃止もされていないのなら, 前回の発行と比べて何も実質的な変更無しに, 中止草案として発行されるべきです. このことは, 作業部会がその報告書の作業を断念することを決めた場合, または, 完了する前にその技術報告書の作業を作業部会に中止するよう要求するACの審査の結果として起こります. 作業部会が終了することになった場合, 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 as the result of an AC Review requiring 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.13.2. 勧告候補の廃止
Rescinding a Candidate Recommendation

勧告候補を廃止する手続きは, 勧告を廃止する場合と一緒です.

The process for rescinding a Candidate Recommendation is the same as for rescinding a Recommendation.

6.3.13.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.13.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 Team 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 Team 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 Team 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 Team'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 verification 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 definition. 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 stages in and of themselves; The maturity stage 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 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 stage, 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 website 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 IPR 指針を通して, W3C技術報告書(とソフトウェア)は, 一般社会で使用料無しに利用できます.
  W3C technical reports whose publication has been approved. Per W3C IPR Policies, W3C technical reports (and software) are available free of charge to the general public.
• 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 website, 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会員の強く求めている関心に対応することです. 1つ目の形式のワークショップの開催者は, ワークショップのプログラムについての方針説明書を要求してもよいですし, それらの資料を出席者や発表者を選ぶのに利用してもよいです.

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手続き文書の意図からして, 技術協定は, W3Cと他の団体や他の複数の団体との間の, コンソーシアムの技術的な活動(例えば, 発行, 部会, 連絡体制)に関する, 正式な契約, 覚書(MoU), もしくはそれらに類似した文書です. 技術協定は, 各団体の他の団体に対する権利と義務を指定します. それらの権利と義務は, 共同の成果, しかるべき調整と一緒の技術的な責任の合意した上での分散, 機密と特定のIPRに対する調整を含んでもよいです.

W3C may negotiate technical agreements with another organization. For purposes of the W3C Process, a technical agreement is a formal contract, or a Memorandum of Understanding (MoU), or a similar document, between W3C and another party or parties, that relates to the technical activity of the Consortium (e.g., its publications, groups, or liaisons). It 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.

技術的でない協定は, 会員関係を目的としたW3Cと会員との間のもの, 提携を目的としてW3Cと提携者との間のもの[規則], コンソーシアムの運営や事業の通常の規定に関する協定を含み, 手続き文書のでの規定を条件としません.

Non-technical agreements, including those between W3C and its Members for the purposes of membership, between W3C and its Partners for the purposes of partnership [BYLAWS], and other agreements related to the operation of the Consortium or to the ordinary provision of services, are not subject to these Process provisions.

技術協定を検討する際(すなわち, 署名するかどうかの決定をする前に), 事務局は, 協定案を, W3Cが協定に署名することでどのような利益を得られるかの説明と一緒に, 審査と議論のために諮問委員会に提示すべきです. 全ての意見に取り組んだ後, 適用される何らかの管理や合意の手続き(例えば, 法律相談や理事会による契約書案の正式な審査)を条件として, 協定に署名しようとする事務局決定を行ったなら, 事務局は署名する意思を周知し, 協定の最終的な文面を, 署名する根拠の説明と一緒に, 諮問委員会に提示しなければなりません. 諮問委員会の委員は, 協定に署名する決定に諮問委員会の抗議を発してもよいです. 抗議によって案が却下されたなら, 事務局は, 理事会によて署名するよう指示されない限り, W3Cの代表として協定に署名してはなりません. 署名された協定は公開されるべきです.

When considering a technical agreement (i.e., before the decision whether to sign is made), the Team should provide the Advisory Committee with a draft of the proposed agreement, along with an explanation of how W3C would benefit from signing this agreement, for their review and discussion. After addressing any comments, and subject to any management or governance procedures that apply (e.g., formal review of proposed contracts by legal counsel or by the Board), if the Team decides to proceed with signing the agreement, the Team must announce the intent to sign, and provide the final text of the agreement, with an explanation of signing rationale, to the Advisory Committee. Advisory Committee representatives may initiate an Advisory Committee Appeal of the decision to sign the agreement. If the proposal is rejected on appeal, the Team must not sign the agreement on behalf of W3C unless directed to do so by the Board. A signed agreement 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 website. 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 review, the Team must either acknowledge or reject the Submission request.
   • 承認された場合, 事務局は, 会員提案についての事務局の意見を加えて, 会員提案を公開されているW3Cのウェブサイトで利用できるようにしなければなりません.
     If acknowledged, the Team must make the Member Submission available at the public W3C website, in addition to Team comments about the Member Submission.
   • 却下された場合, 提案者は, 提案の抗議を提出してもよいです.
     If rejected, the Submitter(s) may initiate a Submission Appeal.

会員提案をW3Cのウェブサイトで利用できるようにすることは, W3C事務局または会員を含めた, W3Cからの支持を意味しません. 提案要求の承認は, 何らかの活動がW3Cによって行われることを意図しません. この承認は, 単に提案要求が提案者によって行われたことを公開の場で記録するだけです. W3Cにより利用可能になった会員提案は, W3Cの“進展中の作業”として参照されてはなりません.

Making a Member Submission available at the W3C website 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 website.

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 fulfill 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週間の間に通知があることを期待できます. 事務局は, 提案者にいつごろ通知が行われそうか知らせ続けなければなりません.