RFC2629 日本語訳
2629 Writing I-Ds and RFCs using XML. M. Rose. June 1999. (Format: TXT=48677 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Rose Request for Comments: 2629 Invisible Worlds, Inc. Category: Informational June 1999
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 2629年の目に見えない世界Inc.カテゴリ: 情報の1999年6月
Writing I-Ds and RFCs using XML
XMLを使用することでI-DsとRFCsに書きます。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series.
このメモはドキュメントに、ソース形式としてインターネット草稿(I-Ds)にXML(拡張マークアップ言語)を使用するためのテクニックとComments(RFC)シリーズのためのRequestを提示します。
Rose Informational [Page 1] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[1ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Using the DTD to Write I-Ds and RFCs . . . . . . . . . . . 4
2.1 XML basics . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Front matter . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 The title Element . . . . . . . . . . . . . . . . . . . . 6
2.2.2 The author Element . . . . . . . . . . . . . . . . . . . . 7
2.2.3 The date Element . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 Meta Data Elements . . . . . . . . . . . . . . . . . . . . 8
2.2.5 The abstract Element . . . . . . . . . . . . . . . . . . . 9
2.2.6 The note Element . . . . . . . . . . . . . . . . . . . . . 9
2.2.7 Status, Copyright Notice, Table of Contents . . . . . . . 9
2.2.7.1 Conformance with RFC 2026 . . . . . . . . . . . . . . . . 9
2.2.8 Everything in the Front . . . . . . . . . . . . . . . . . 10
2.3 The Middle . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 The section Element . . . . . . . . . . . . . . . . . . . 11
2.3.1.1 The t Element . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.2 The list Element . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.3 The figure Element . . . . . . . . . . . . . . . . . . . . 13
2.3.1.4 The xref Element . . . . . . . . . . . . . . . . . . . . . 15
2.3.1.5 The eref Element . . . . . . . . . . . . . . . . . . . . . 15
2.3.1.6 The iref Element . . . . . . . . . . . . . . . . . . . . . 16
2.3.1.7 The vspace Element . . . . . . . . . . . . . . . . . . . . 16
2.4 Back matter . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 The references Element . . . . . . . . . . . . . . . . . . 17
2.4.2 Appendices . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.3 Copyright Status . . . . . . . . . . . . . . . . . . . . . 18
3. Processing the XML Source File . . . . . . . . . . . . . . 19
3.1 Editing . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Checking . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Converting to Text Format . . . . . . . . . . . . . . . . 20
3.3 Converting to HTML Format . . . . . . . . . . . . . . . . 20
3.4 Viewing . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Searching . . . . . . . . . . . . . . . . . . . . . . . . 20
4. Security Considerations . . . . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . 22
A. The rfc Element . . . . . . . . . . . . . . . . . . . . . 23
B. The RFC DTD . . . . . . . . . . . . . . . . . . . . . . . 24
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 29
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 31
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 3 2。 Write I-DsとRFCs. . . . . . . . . . . 4 2.1XML基礎. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2Frontの件にDTDを使用する、.62.2、.1、タイトルElement、.62.2、.2、作者Element、.72.2、.3、日付Element. . . . . . . . . . . . . . . . . . . . . 8 2.2.4Meta Data Elements、.82.2、.5、抽象的なElement…; . . . . . 9 2.2.6 注意Element、.92.2.7Status、Copyright Notice、目次. . . . . . . 9 2.2.7、RFC2026.92.2がある.1Conformance、Front. . . . . . . . . . . . . . . . . 10 2.3Middleの.8Everything、.112.3、.1、セクションElement、.112.3、.1、.1、t Element、.122.3、.1、.2、リストElement。. . . . . . . . . . . . . . . . . . . 12 2.3 .1、.3、図Element、.132.3、.1、.4、xref Element、.152.3、.1、.5、eref Element、.152.3、.1、.6、iref Element、.162.3、.1、.7、vspace Element; .162.4の逆件. . . . . . . . . . . . . . . . . . . . . . . 17 2.4の.1 参照Element. . . . . . . . . . . . . . . . . . 17 2.4.2Appendices. . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.3Copyright Status. . . . . . . . . . . . . . . . . . . . . 18 3 XMLソースファイル. . . . . . . . . . . . . . 19 3.1編集. . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1の照合を処理する、.193.2が変換される、テキスト形式、.203.3が変換される、HTML形式. . . . . . . . . . . . . . . . 20 3.4の見. . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5ることの探. . . . . . . . . . . . . . . . . . . . . . . . 20 4すこと。 B. セキュリティConsiderations. . . . . . . . . . . . . . . . . 21References. . . . . . . . . . . . . . . . . . . . . . . . 22AuthorはA. Address. . . . . . . . . . . . . . . . . . . . . 22rfc Element. . . . . . . . . . . . . . . . . . . . . 23RFC DTDです; .24 C.承認. . . . . . . . . . . . . . . . . . . . . 29のインデックスの.30の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 31
Rose Informational [Page 2] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[2ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
1. Introduction
1. 序論
This memo describes how to write a document for the I-D and RFC series using the Extensible Markup Language [1] (XML). This memo has three goals:
このメモは拡張マークアップ言語[1](XML)を使用することでI-DとRFCシリーズのためのドキュメントを書く方法を説明します。 このメモには、3つの目標があります:
1. To describe a simple XML Document Type Definition (DTD) that is
powerful enough to handle the simple formatting requirements of
RFC-like documents whilst allowing for meaningful markup of
descriptive qualities.
1. 描写的である品質の重要なマーク付けを考慮している間、RFCのようなドキュメントの簡単な形式要件を扱うほど強力な簡単なXML Document Type Definition(DTD)について説明するために。
2. To describe software that processes XML source files, including a
tool that produces documents conforming to RFC 2223 [2], HTML
format, and so on.
2. ソフトウェアについて説明するために、それはXMLソースファイルを処理します、RFC2223[2]、HTML形式などに従いながら書類を提示するツールを含んでいて。
3. To provide the proof-of-concept for the first two goals (this
memo was written using this DTD and produced using that
software).
3. 最初の2つの目標(このメモは、そのソフトウェアを使用することでこのDTDを使用することで書かれて、製作された)に概念の証拠を提供するために。
It is beyond the scope of this memo to discuss the political ramifications of using XML as a source format for RFC-like documents. Rather, it is simply noted that adding minimal markup to plain text:
それは、RFCのようなドキュメントにソース形式としてXMLを使用する政治的事態の波及について議論するためにこのメモの範囲を超えています。 むしろ、それはプレーンテキストへの単に注意されたそんなに加えている最小量のマーク付けです:
o allows the traditional production of textual RFC-like documents
using familiar editors;
o なじみ深いエディタを使用することで原文のRFCのようなドキュメントの伝統的な生産を許します。
o requires some, albeit minimal, additions to existing software
environments; and,
o 既存のソフトウェア環境に最小量ですが、追加をいくつか必要とします。 そして
o permits information to be organized, searched, and retrieved using
both unstructured and structured mechanisms.
o 情報が組織化されて、捜されて、検索されることを不統一なものと同様に構造化されたメカニズムを使用することで許可します。
Rose Informational [Page 3] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[3ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
2. Using the DTD to Write I-Ds and RFCs
2. I-DsとRFCsに書くのにDTDを使用します。
We do not provide a formal or comprehensive description of XML. Rather, this section discusses just enough XML to use a Document Type Declaration (DTD) to write RFC-like documents.
私たちはXMLの正式であるか包括的な記述を提供しません。 むしろ、このセクションはRFCのようなドキュメントを書くのにDocument Type Declaration(DTD)をちょうど使用できるくらいのXMLについて論じます。
If you're already familiar with XML, skip to Appendix B to look at the DTD.
既にXMLになじみ深いなら、Appendix Bまでスキップして、DTDを見てください。
2.1 XML basics
2.1 XML基礎
There are very few rules when writing in XML, as the syntax is simple. There are five terms you'll need to know:
XMLに書くとき、構文が簡単であるときに、ほんのわずかな規則があります。 あなたが知る必要がある5つの用語があります:
1. An "element" usually refers to a start tag, an end tag, and all
the characters in between, e.g., "<example>text and/or nested
elements</example>"
1. 通常、「要素」は開始タグ、終了タグ、および間のすべてのキャラクタ、例えば、「<例の>テキスト、そして/または、入れ子にされた要素の</例の>」を示します。
2. An "empty element" combines the start tag and the end tag, e.g.,
"<empty/>". You don't find these in HTML.
2. 「空の要素」は開始タグと終了タグ、例えば、「<の空の/>」を結合します。 あなたはHTMLでこれらを見つけません。
3. An "attribute" is part of an element. If present, they occur in
the start tag, e.g., "<example name='value'>". Of course, they
can also appear in empty elements, e.g., "<empty name='value'/>".
3. 「属性」は要素の一部です。 存在しているなら、開始タグに起こります、例えば、「<例の名=の'値の'>」。' もちろん、また、彼らは空の要素、例えば、「<の空の名前='値'/>」に現れることができます。
4. An "entity" is a textual macro that starts with "&". Don't worry
about these, you'll only use them whenever you want to put a "&"
or a "<" in your text.
4. 「実体」は“&"から始まる原文のマクロです。 これらを心配しないでください、そして、“&"か"<"をあなたのテキストに置きたがっているときはいつも、あなたはそれらを使用するだけでしょう。
5. A "token" is a string of characters. The first character is
either a letter or an underscore ("_"). Any characters that
follow are either letters, numbers, an underscore, or a period
(".").
5. 「トークン」は一連のキャラクタです。 最初のキャラクタは、手紙か強調("_")のどちらかです。 続くどんなキャラクタも手紙、数、強調、または期間である、(「」、)。
First, start your source file with an XML declaration, a reference to the DTD, and the "rfc" element:
まず最初に、XML宣言、DTDの参照、および"rfc"要素からソースファイルを始動してください:
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc>
...
</rfc>
<?xmlバージョン= 「1インチ?」><!DOCTYPE rfc SYSTEM、「rfc2629.dtd「><rfc>…」 </rfc>。
Ignore the first two lines -- the declaration and the reference -- and simply treat them as opaque strings. Nothing else should be present after the "</rfc>" tag.
最初の2つの系列(宣言と参照)を無視してください、そして、単に不透明なストリングとしてそれらを扱ってください。 他に何もが「</rfc>」タグの後に存在していないべきではありません。
Second, make sure that all elements are properly matched and nested.
2番目に、すべての要素が適切に合わせられていて、入れ子にされるのを確実にしてください。
Rose Informational [Page 4] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[4ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
A properly matched element that starts with "<example>" is eventually followed with "</example>". (Empty elements are always matched.) Elements are properly nested when they don't overlap.
「<の例の>」から始まる適切に合われている要素は結局、「</例の>」で従われています。 (空の要素はいつも合わせられています。) 重ならないとき、要素は適切に入れ子にされます。
For example,
例えば
<outer>
...
<inner>
...
</inner>
...
</outer>
<の外側の>… <の内側の>… </内側の>… </外側の>。
is properly nested.
適切に入れ子にされます。
However,
しかしながら
<outer>
...
<inner>
...
</outer>
...
</inner>
<の外側の>… <の内側の>… </外側の>… </内側の>。
overlaps, so the elements aren't properly nested.
オーバラップであり、したがって、要素は適切に入れ子にされません。
Third, never use "<" or "&" in your text. Instead, use either "<" or "&", respectively.
3番目に、テキストで"<"か“&"を決して使用しないでください。 代わりに、それぞれ"<"か"&"のどちらかを使用してください。
Fourth, there are two quoting characters in XML, 'apostrophe' and "quotation". Make sure that all attributes values are quoted, e.g., "<example name='value'>", If the value contains one of the quoting characters, then use the other to quote the value, e.g., "<example name='"'>", If the value contains both quoting characters, then use one of them to quote the value, and replace occurrances of that character in the attribute value with either ''' (apostrophe) or """ (quotation), e.g., "<example name='"'"'>".
4番目に、XMLでキャラクタを引用する2、'アポストロフィ'、および「引用」があります。 '「属性値でそのキャラクタのoccurrancesを'aposに取り替えてください; 値が値を引用するためにキャラクタ、彼らの当時の使用1を引用しながら両方を含んでいて、'」 (アポストロフィ)か"""(引用)、例えば、「<例の名='apos」という確信しているすべての属性値が引用されて、例えば、「<例の名='が'>」を評価して、Ifが値であることが引用しているキャラクタのひとりを含んで、次に、使用が値、例えば、「<例の名=の'」'>」を引用するもう片方であることをIf'>」を作ってください。'
If you want to put a comment in your source file, here's the syntax:
あなたがソースファイルにコメントを入れたいなら、ここに、構文があります:
<!-- comments can be multiline,
if you wish -->
<!--あなたが願うなら、コメントはマルチラインであるかもしれません--、>。
Finally, XML is case sensitive.
最終的に、XMLは大文字と小文字を区別しています。
Rose Informational [Page 5] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[5ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
2.2 Front matter
2.2 前の件
Immediately following the "<rfc>" tag is the "front" element:
すぐに「<rfc>」タグに続くのは、「前」の要素です:
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc>
<front>
<title ...>
<author ...>
<author ...>
<date ...>
<area ...>
<workgroup ...>
<keyword ...>
<keyword ...>
<abstract ...>
<note ...>
</front>
...
</rfc>
<?xmlバージョン= 「1インチ?」><!DOCTYPE rfc SYSTEM、「rfc2629.dtd「>の>の<の前の><<rfcタイトル…」><作者…><作者…><日付…><領域…><ワークグループ…><キーワード…><キーワード…><要約…><注意…></前部>… </rfc>。
(Note that in all examples, indentation is used only for expository purposes.)
(すべての例では、刻み目が解説の目的にだけ使用されることに注意してください。)
The "front" element consists of a "title" element, one or more "author" elements, a "date" element, one or more optional "area" elements, one or more optional "workgroup" elements, one or more optional "keyword" elements, an optional "abstract" element. and, one or more optional "note" elements.
「前」の要素は「タイトル」要素から成ります、1つ以上の「作者」要素、「日付」要素、1つ以上の任意の「領域」要素、1つ以上の任意の「ワークグループ」要素、1つ以上の任意の「キーワード」要素、任意の「抽象的な」要素、1つ以上の任意の「注意」要素。
2.2.1 The title Element
2.2.1 タイトルElement
The "title" element identifies the title of the document. Because the title will be used in the headers of the document when formatted according to [2], if the title is more than 42 characters, then an abbreviation should also be provided, e.g.,
「タイトル」要素はドキュメントのタイトルを特定します。 [2]によると、フォーマットされるとタイトルがドキュメントのヘッダーで使用されるので、タイトルが42以上のキャラクタであるなら、また、例えば略語を提供するべきです。
<title abbrev="Much Ado about Nothing">
The IETF's Discussion on "Source Format of RFC Documents"
</title>
<タイトルabbrevが等しい、「空騒ぎ、「「RFCドキュメントのソース形式」</についてのIETFの議論が>と題をつける>」
Rose Informational [Page 6] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[6ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
2.2.2 The author Element
2.2.2 作者Element
Each "author" element identifies a document author. Since a document may have more than one author, more than one "author" element may be present. If the author is a person, then three attributes must be present in the "<author>" tag, "initials", "surname", and "fullname", e.g.,
それぞれの「作者」要素はドキュメント作者を特定します。 ドキュメントには1人以上の作者がいるかもしれないので、1つ以上の「作者」要素が存在しているかもしれません。 作者が人であるなら、3つの属性が例えば「<作者>」タグ、「イニシャル」、「姓」、および"fullname"に存在していなければなりません。
<author initials="M.T." surname="Rose"
fullname="Marshall T. Rose">
<作者イニシャルが「M.T.」姓=の「ローズ」fullname=と等しい、「マーシャルT.ローズ">"
The "author" element itself consists of an "organization" element, and, an optional "address" element.
そして、「作者」要素自体は「組織」要素から任意の「アドレス」要素に成ります。
The "organization" element is similar to the "title" element, in that an abbreviation may be paired with a long organization name using the "abbrev" attribute, e.g.,
「組織」要素は「タイトル」要素と同様です、略語が例えば"abbrev"属性を使用する長い組織名と対にされるかもしれないので
<organization abbrev="ISI">
USC/Information Sciences Institute
</organization>
<組織abbrevが等しい、「ISI「>USC/情報科学研究所</組織>」
The "address" element consists of an optional "postal" element, an optional "phone" element, an optional "facsimile" element, an optional "email" element, and, an optional "uri" element.
そして、「アドレス」要素は任意の「郵便」の要素、任意の「電話」要素、任意の「ファクシミリ」要素、任意の「メール」要素から任意の"uri"要素に成ります。
The "postal" element contains one or more "street" elements, followed by any combination of "city", "region" (state or province), "code" (zipcode or postal code), and "country" elements, e.g.,
「郵便」の要素は1つ以上の「通り」要素を含んでいます、続いて、例えば「都市」、「領域」(州か州)、「コード」(zipcodeか郵便番号)、および「国」要素のどんな組み合わせも含みます。
<postal>
<street>660 York Street</street>
<street>M/S 40</street>
<city>San Francisco</city> <region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<の郵便の><通りの>660ヨーク通り</通りの><通りの>M/S40</通りの><都市の>サンフランシスコ</都市の><領域の>カリフォルニアの</地域><コード>94110</コード><国の>米国</国の></郵便の>。
This flexibility is provided to allow for different national formats for postal addresses. Note however, that although the order of the "city", "region", "code", and "country" elements isn't specified, at most one of each may be present. Regardless, these elements must not be re-ordered during processing by an XML application (e.g., display applications must preserve the ordering of the information contained in these elements). Finally, the value of the "country" element should be a two-letter code from ISO 3166.
郵便の宛先のための異なった国家の形式を考慮するためにこの柔軟性を提供します。 しかしながら、「都市」の注文ですが、「領域」、「コード」、および「国」要素が最も1つでそれぞれについて指定されないのが、存在しているかもしれないことに注意してください。 不注意に、これらの要素はXMLによって再規則正しい処理の間、アプリケーションであるはずがありません(例えば、ディスプレイアプリケーションはこれらの要素に含まれた情報の注文を保存しなければなりません)。 最終的に、「国」要素の価値はISO3166からの2レター・コードであるべきです。
Rose Informational [Page 7] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[7ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
The "phone", "facsimile", "email", and "uri" elements are simple, e.g.,
「電話」、「ファクシミリ」、「メール」、および"uri"要素は例えば簡単です。
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
<電話>+1 415 695 3975</phone> <email>mrose@not.invisible.net 、lt;、/メール、gt;、lt;、uri>http://invisible.net/</uri>。
2.2.3 The date Element
2.2.3 日付Element
The "date" element identifies the publication date of the document. It consists of a month and a year, e.g.,
「日付」要素はドキュメントの公表日付を特定します。 それは例えば1カ月と1年から成ります。
<date month="February" year="1999" />
<月=の「2月」年=の「1999」/>日付
The "date" element also has an optional day attribute.
また、「日付」要素には、任意の日の属性があります。
2.2.4 Meta Data Elements
2.2.4 メタデータ要素
The "front" element may contain meta data -- the content of these elements does not appear in printed versions of the document.
「前」の要素はメタデータを含むかもしれません--これらの要素の内容はドキュメントのバージョンを出版しません。
A document has one or more optional "area", "workgroup" and "keyword" elements, e.g.,
ドキュメントには、1任意の「領域」、「ワークグループ」、および「キーワード」要素が例えばあります。
<area>General</area>
<workgroup>RFC Beautification Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
コメントキーワード><キーワード>I-D</キーワード><キーワード>インターネット</草稿</キーワード><キーワード>XML</キーワード><キーワード>拡張マークアップ言語</キーワード @を求める?領域?一般?/領域??ワークグループ?RFC美化ワーキンググループ?/ワークグループ??キーワード?RFC?/キーワード??キーワード?要?br />「領域」要素はドキュメント(例えば、「アプリケーション」の1つ、「一般」、「インターネット」、「管理」、「操作」、「ルート設定」、「セキュリティ」、「輸送」、または「ユーザ」)のために一般的なカテゴリを特定します、「ワークグループ」要素はドキュメントを製作したIETFワーキンググループを特定します、そして、「キーワード」要素は役に立つ検索用語を特定しますが。
The "area" elements identify a general category for the document (e.g., one of "Applications", "General", "Internet", "Management", "Operations", "Routing", "Security", "Transport", or "User"), while the "workgroup" elements identify the IETF working groups that produced the document, and the "keyword" elements identify useful search terms.
Rose Informational [Page 8] RFC 2629 Writing I-Ds and RFCs using XML June 1999
2.2.5 The abstract Element
ドキュメントには1つ以上の「t」要素を含む「抽象的な」要素があるかもしれない、(セクション2.3 .1 .1)。 一般に、ただ一つの「t」要素だけが例えば存在しています。
A document may have an "abstract" element, which contains one or more "t" elements (Section 2.3.1.1). In general, only a single "t" element is present, e.g.,
抽象的な<の<t>Thisメモ>プレゼントのドキュメントに、ソース形式としてインターネット草稿(I-Ds)にXML(拡張マークアップ言語)を使用するためのテクニックとComments(RFC)シリーズ</t></抽象的な>のためのRequest
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language) as a source format
for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
2.2.6 注意Element
2.2.6 The note Element
ドキュメントにはそれのそれぞれが1つ以上の「t」要素を含む1つ以上の「注意」要素があるかもしれない、(セクション2.3 .1 .1)。 義務的な「タイトル」属性があります。 一般に、「注意」要素は例えばIESGからのテキストを含んでいます。
A document may have one or more "note" elements, each of which contains one or more "t" elements (Section 2.3.1.1). There is a mandatory "title" attribute. In general, the "note" element contains text from the IESG, e.g.,
<注意タイトルが等しい、「IESG Note、「IESGは心にわだかまりがある><t>は. </t></注意>を言います」。
<note title="IESG Note">
<t>The IESG has something to say.</t>
</note>
2.2.7 状態、版権情報、目次
2.2.7 Status, Copyright Notice, Table of Contents
メモの状態に関連するテキスト、版権情報、または目次がドキュメントのマークアップに含まれていないことに注意してください--ドキュメントのテキストかHTMLバージョンのどちらかを製作すると、これはXMLアプリケーションで自動的に挿入されます。
Note that text relating to the memo's status, copyright notice, or table of contents is not included in the document's markup -- this is automatically inserted by an XML application when it produces either a text or HTML version of the document.
2.2.7.1 RFC2026との順応
2.2.7.1 Conformance with RFC 2026
インターネット草稿が作成されているなら、"ipr"属性はファイルの始めに「<rfc>」タグに存在しているべきです。 属性の値が1であるべきである、:
If an Internet-Draft is being produced, then the "ipr" attribute should be present in the "<rfc>" tag at the beginning of the file. The value of the attribute should be one of:
full2026: ドキュメントが完全な順応RFC2026のセクション10に関するすべての条項と共に中であることを示します。
full2026: indicating that the document is in full conformance with
all the provisions of Section 10 of RFC 2026;
noDerivativeWorks2026: 派生物を作り出す権利が働いているのを除いて、ドキュメントが完全な順応RFC2026のセクション10に関するすべての条項と共に中であることを示すのは与えられません。 または
noDerivativeWorks2026: indicating that the document is in full
conformance with all the provisions of Section 10 of RFC 2026
except that the right to produce derivative works is not granted;
or,
なにも: RFC2026のセクション10に応じてドキュメントが提供されないで、また作者がインターネット草稿として発行するのを除いたどんな権利もIETFに提供しないのを示します。
none: indicating that the document is NOT offered in accordance with
Section 10 of RFC 2026, and the author does not provide the IETF
with any rights other than to publish as an Internet-Draft.
Rose Informational [Page 9] RFC 2629 Writing I-Ds and RFCs using XML June 1999
In the latter case, a copyright notice will not be automatically inserted during processing by an XML application.
[3] さらに詳しい明細については相談してください。
Consult [3] for further details.
最終的に、自動化されたプロセスにインターネット草稿を提出しているなら、"docName"属性はファイルの始めに「<rfc>」タグに存在しているべきです。 この属性の値は例えばこのインターネット草稿に関連しているドキュメント(ファイルしない)名を含んでいます。
Finally, if the Internet-Draft is being submitted to an automated process, then the "docName" attribute should be present in the "<rfc>" tag at the beginning of the file. The value of this attribute contains the document (not file) name associated with this Internet- Draft, e.g.,
「完全な」<rfc ipr=docNameは「rfcs-1インチの草稿-mroseを書いている>」と等しいです… </rfc>。
<rfc ipr="full" docName="draft-mrose-writing-rfcs-01">
...
</rfc>
2.2.8 前部のすべて
2.2.8 Everything in the Front
そのように、例えば、それを一斉に、私たちが持っている置くこと。
So, putting it all together, we have, e.g.,
XML</タイトル>を使用することでI-DsとRFCsに書く<の前の><タイトル>。
<front>
<title>Writing I-Ds and RFCs using XML</title>
<作者イニシャルが「M.T.」姓=の「ローズ」fullname=と等しい、「マーシャルT.ローズ「>の組織の>の目に見えない世界Inc.<</組織>」
<author initials="M.T." surname="Rose"
fullname="Marshall T. Rose">
<organization>Invisible Worlds, Inc.</organization>
<アドレスの>の<の郵便の><通りの>660ヨーク通り</通りの><通りの>M/S40</通りの><都市の>サンフランシスコ</都市の><領域の>カリフォルニアの</地域><コード>94110</コード><国の>米国</国の></郵便の>。
<address>
<postal>
<street>660 York Street</street>
<street>M/S 40</street>
<city>San Francisco</city> <region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<電話>+1 415 695 3975</phone> <email>mrose@not.invisible.net 、lt;、/メール、gt;、lt;、uri>http://invisible.net/</uri></アドレスの></作者>。
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<月=の「2月」年=の「1999」/>日付
<date month="February" year="1999" />
コメント</キーワード><キーワード>I-D</キーワード>を求める<領域>一般</領域><ワークグループ>RFC美化ワーキンググループ</ワークグループ><キーワード>RFC</キーワード><キーワード>要求
<area>General</area>
<workgroup>RFC Beautification Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
Rose Informational [Page 10] RFC 2629 Writing I-Ds and RFCs using XML June 1999
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language) as a source format
for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>
2.3 中央
2.3 The Middle
「中央」の要素は図書目録と付録以外のドキュメントのすべてのセクションを含みます:
The "middle" element contains all the sections of the document except for the bibliography and appendices:
... </前部の><中くらいの><部…><部…><部…></中央の><逆>…
...
</front>
<middle>
<section ...>
<section ...>
<section ...>
</middle>
<back>
...
「中央」の要素は1つ以上の「セクション」要素から成ります。
The "middle" element consists of one or more "section" elements.
2.3.1 セクションElement
2.3.1 The section Element
それぞれの「セクション」要素はドキュメントのセクションを含みます。 義務的な属性、セクションのタイトルを特定する「タイトル」があります。 また、任意の属性があって、"xref"要素で「アンカー」に十字で参照をつける、それが使用されている(セクション2.3 .1 .4、)例えば。
Each "section" element contains a section of the document. There is a mandatory attribute, "title", that identifies the title of the section. There is also an optional attribute, "anchor", that is used for cross-referencing with the "xref" element (Section 2.3.1.4), e.g.,
<セクションアンカー=「序奏」タイトルが等しい、「序論「>…」 </セクション>。
<section anchor="intro" title="Introduction">
...
</section>
Rose Informational [Page 11] RFC 2629 Writing I-Ds and RFCs using XML June 1999
The "section" element is recursive -- each contains any number and combination of "t", "figure", and "section" elements, e.g.,
<セクションタイトルが等しい、「中央「>…」 <セクションタイトルが等しい、「セクションElement「>…」 <セクションタイトルが等しい、「t Element「>…」</セクション><セクションタイトルが等しい、「リストElement「>…」</セクション><セクションタイトルが等しい、「図Element「>…」</セクション><セクションタイトルが等しい、「xref Element「>…」</セクション><セクションタイトルが等しい、「eref Element「>…」</セクション><セクションタイトルが等しい、「iref Element「>…」</セクション></部分の></部分>。
<section title="The Middle">
...
<section title="The section Element">
...
<section title="The t Element">...</section>
<section title="The list Element">...</section>
<section title="The figure Element">...</section>
<section title="The xref Element">...</section>
<section title="The eref Element">...</section>
<section title="The iref Element">...</section>
</section>
</section>
2.3.1.1 t Element
2.3.1.1 The t Element
「t」要素はパラグラフ、リスト、および数字のどんな数と組み合わせも含んでいます。 相互参照がセクション、図、または参照、"xref"要素に必要である、(セクション2.3 .1 .4は)使用されています。 同様である、"eref"要素、外部参照が必要であるなら(セクション2.3 .1 .5は)使用されています。 "iref"要素でテキストのインデックスを提供する、(セクション2.3 .1 .6)。
The "t" element contains any number and combination of paragraphs, lists, and figures. If a cross-reference is needed to a section, figure, or reference, the "xref" element (Section 2.3.1.4) is used; similarly, if an external-reference is needed, the "eref" element (Section 2.3.1.5) is used. Indexing of text is provided by the the "iref" element (Section 2.3.1.6).
2.3.1.2 リストElement
2.3.1.2 The list Element
「リスト」要素は複数の項目を含んでいます。例えば再帰を考慮して、各個条は「t」要素です。
The "list" element contains one or more items. Each item is a "t" element, allowing for recursion, e.g.,
<リストスタイルが等しい、「数、「><t>. pfirstの品目</t><t>、第2項目:、」。(項目は2つのbulletedサブ項目を含みます)。 <リストスタイルが等しい、「「><t>. . 第2サブ項目</t></が記載する最初のサブ項目</t><t>></t></リスト>」というシンボル
<list style="numbers">
<t>The pfirst item.</t>
<t>The second item, which contains two bulleted sub-items:
<list style="symbols">
<t>The first sub-item.</t>
<t>The second sub-item.</t>
</list>
</t>
</list>
「リスト」要素は任意の属性、または、「掛かってい」て(掛かっているリストのために)、値の「数」(数値リストのための)、「シンボル」(bulletedリストのための)を持っている「スタイル」を「空」に(入り込まれたテキストのための)持っています。 「リスト」要素が入れ子にするなら、最も近い親からデフォルト値を取ります。 さもなければ、デフォルト値は「空です」。
The "list" element has an optional attribute, "style", having the value "numbers" (for numeric lists), "symbols" (for bulleted lists), "hanging" (for hanging lists), or, "empty" (for indented text). If a "list" element is nested, the default value is taken from its closest parent; otherwise, the default value is "empty".
Rose Informational [Page 12] RFC 2629 Writing I-Ds and RFCs using XML June 1999
When nested within a "hanging list" element, the "t" element has an optional attribute, "hangText" that specifies the text to be inserted, e.g.,
<リストスタイルが等しい、「絞首刑、「><t hangTextが等しい、「full2026: 「ドキュメントが完全な順応RFC2026; </t>のセクション10に関するすべての条項と共に中であることを示す>」
<list style="hanging">
<t hangText="full2026:">indicating that the document is in
full conformance with all the provisions of Section 10 of RFC
2026;</t>
<t hangTextが等しい、「noDerivativeWorks2026: 「派生している作品を製作する権利が与えられないのを除いて、ドキュメントが完全な順応RFC2026のセクション10に関するすべての条項と共に中であることを示す>」 または、</t>。
<t hangText="noDerivativeWorks2026:">indicating that the
document is in full conformance with all the provisions of
Section 10 of RFC 2026 except that the right to produce
derivative works is not granted; or,</t>
<t hangText="none:">indicating that the document is NOT
offered in accordance with Section 10 of RFC 2026, and the
author does not provide the IETF with any rights other than
to publish as an Internet-Draft.</t>
</list>
<t hangTextが等しい、「なにも: 「RFC2026のセクション10に応じてドキュメントが提供されないで、また作者がインターネット草稿として. </t></リスト>を発行するのを除いたどんな権利もIETFに提供しないのを示す>」
2.3.1.3 The figure Element
2.3.1.3 図Element
The "figure" element groups an optional "preamble" element, an "artwork" element, and an optional "postamble" element together. The "figure" element also has an optional "anchor" attribute that is used for cross-referencing with the "xref" element (Section 2.3.1.4). There is also an optional "title" attribute that identifies the title of the figure.
「図」要素は任意の「序文」要素、「アートワーク」要素、および任意の「ポストアンブル」要素を一緒に分類します。 また、「図」要素には"xref"で参照箇所に交差している要素に使用される任意の「アンカー」属性がある、(セクション2.3 .1 .4)。 また、図のタイトルを特定する任意の「タイトル」属性があります。
The "preamble" and "postamble" elements, if present, are simply text. If a cross-reference is needed to a section, figure, or reference, the "xref" element (Section 2.3.1.4) is used; similarly, if an external-reference is needed, the "eref" element (Section 2.3.1.5) is used. Indexing of text is provided by the the "iref" element (Section 2.3.1.6).
存在しているなら、「序文」と「ポストアンブル」要素は単にテキストです。 相互参照がセクション、図、または参照、"xref"要素に必要である、(セクション2.3 .1 .4は)使用されています。 同様である、"eref"要素、外部参照が必要であるなら(セクション2.3 .1 .5は)使用されています。 "iref"要素でテキストのインデックスを提供する、(セクション2.3 .1 .6)。
The "artwork" element, which must be present, contains "ASCII artwork". Unlike text contained in the "t", "preamble", or "postamble" elements, both horizontal and vertical whitespace is significant in the "artwork" element.
「アートワーク」要素(存在していなければならない)は「ASCIIアートワーク」を含んでいます。 「t」に含まれたテキスト、「序文」、または「ポストアンブル」要素と異なって、水平なものと同様に垂直な空白は「アートワーク」要素で重要です。
Rose Informational [Page 13] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[13ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
So, putting it all together, we have, e.g.,
そのように、例えば、それを一斉に、私たちが持っている置くこと。
<figure anchor="figure_example">
<preamble>So,
putting it all together, we have, e.g.,</preamble>
<artwork>
ascii artwork goes here...
<図アンカー=、「図_例、「><序文>So、一斉にそれを置いて、私たちは置きました、例えば、</序文><アートワーク>ASCIIアートワークはここに行きます」。
be sure to use "<" or "&" instead of "<" and "&",
respectively!
</artwork>
<postamble>which is a very simple example.</postamble>
</figure>
"<"と“&"の代わりにそれぞれ"<"か"&"を必ず使用してください! aまさしくその簡単な例</ポストアンブル></数値>である</アートワーク><ポストアンブル>。
which is a very simple example.
非常に簡単な例です。
If you have artwork with a lot of "<" characters, then there's an XML trick you can use:
多くの"<"キャラクタとのアートワークがありましたら、あなたが使用できるXMLトリックがあります:
<figure>
<preamble>If you have artwork with a lot of "<"
characters, then there's an XML trick you can
use:</preamble>
<artwork><![CDATA[
ascii artwork goes here...
<は><序文>Ifについて計算します。あなたには多くの"<"キャラクタとのアートワークがあって、そこのその時によるXMLの気取っているあなたが: </序文><アートワーク><を使用できるということである、![CDATA、[ASCIIアートワークはここに行きます…
just don't use "]]" in your artwork!
]]></artwork>
<postamble>The "<![CDATA[ ... ]]>" construct is called
a CDATA block -- everything between the innermost brackets
is left alone by the XML application.</postamble>
</figure>
「ただ、使用しない」、]、」 あなたのアートワークで! ]、></アートワーク><ポストアンブル>、「<!、[CDATA、[」 … 「]、>、」 構造物はCDATAブロックと呼ばれます--最も奥深い括弧の間のすべてが. XMLアプリケーション</ポストアンブル></数値>によって放っておかれます。
The "<![CDATA[ ... ]]>" construct is called a CDATA block -- everything between the innermost brackets is left alone by the XML application.
「<[CDATA[…]]!>」構造物はCDATAブロックと呼ばれます--XMLアプリケーションによって最も奥深い括弧の間のすべてがレフト・アローンです。
Because the "figure" element represents a logical grouping of text and artwork, an XML application producing a text version of the document should attempt to keep these elements on the same page. Because RFC 2223 [2] allows no more than 69 characters by 49 lines of content on each page, XML applications should be prepared to prematurely introduce page breaks to allow for better visual grouping.
「図」要素がテキストとアートワークの論理的な組分けを表すので、ドキュメントのテキストバージョンを生産するXMLアプリケーションは、同じページのこれらの要素を保つのを試みるべきです。 RFC2223[2]が各ページの内容の49の系列で69未満のキャラクタを許容するので、XMLアプリケーションは早まってより良い視覚組分けを考慮するためにページブレークを紹介するように準備されるべきです。
Rose Informational [Page 14] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[14ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
Finally, the "artwork" element has two optional attributes: "name" and "type". The former is used to suggest a filename to use when storing the content of the "artwork" element, whilst the latter contains a suggestive data-typing for the content.
最終的に、「アートワーク」要素には、2つの任意の属性があります: 「命名し」て、「タイプします」。 前者は「アートワーク」要素の内容を保存するとき使用するファイル名を示すのに使用されます、後者は内容のための思わせ振りのデータ型定義を含んでいますが。
2.3.1.4 The xref Element
2.3.1.4 xref Element
The "xref" element is used to cross-reference sections, figures, and references. The mandatory "target" attribute is used to link back to the "anchor" attribute of the "section", "figure", and "reference" elements. The value of the "anchor" and "target" attributes should be formatted according to the token syntax in Section 2.1.
"xref"要素は相互参照部、数字、および参照に使用されます。 義務的な「目標」属性は、「セクション」、「図」、および「参照」要素の「アンカー」属性につないで戻るのに使用されます。 セクション2.1のトークン構文によると、「アンカー」と「目標」属性の値はフォーマットされるべきです。
If used as an empty element, e.g.,
空の要素として、例えば使用されます。
according to the token syntax in <xref target="xml_basics" />.
<のトークン構文によると、xref目標は「xml_基礎」/>と等しいです。
then the XML application inserts an appropriate phrase during processing, such as "Section 2.1" or "<a href="#xml_basics">XML Basics</a>".
そして、XMLアプリケーションは「セクション2.1インチか「<a href=」#xml_基礎「>XML Basics</a>」」などの処理の間、適切な句を挿入します。
If used with content, e.g.,
例えば内容と共に使用されます。
conforming to <xref target="refs.RFC2223">RFC 2223</xref>.
<xref目標=に従う、「refs.RFC2223「>RFC2223</xref>。」
then the XML application inserts an appropriate designation during processing, such as "RFC 2223 [2]" or "<a href="#refs.RFC2223">RFC 2223</a>". Although the XML application decides what "an appropriate designation" might be, its choice is consistent throughout the processing of the document.
そして、XMLアプリケーションは「RFC2223[2]」か「<a href=」#refs.RFC2223「>RFC2223</a>」などの処理の間、適切な名称を挿入します。 XMLアプリケーションは、「適切な名称」が何であるだろうかを決めますが、選択はドキュメントの処理の間中一貫しています。
2.3.1.5 The eref Element
2.3.1.5 eref Element
The "eref" element is used to reference external documents. The mandatory "target" attribute is a URI [4], e.g.,
"eref"要素は参照の外部のドキュメントに使用されます。 義務的な「目標」属性は例えばURI[4]です。
<eref target="http://metalab.unc.edu/xml/">Cafe con Leche</eref>
<eref目標=、「 http://metalab.unc.edu/xml/ 「>CafeまやかしLeche</eref>」
Note that while the "target" attribute is always present, the "eref" element may be empty, e.g.,
例えば、「目標」属性がいつも存在している間"eref"要素が空であるかもしれないというメモ
<eref target="http://invisible.net/" />
<eref目標=" http://invisible.net/ "/>。
and the XML application inserts an appropriate designation during processing such as "[9]" or "<a href="http://invisible.net/">http://invisible.net/</a>".
または、そして、XMLアプリケーションが"[9]"などの処理の間、適切な名称を挿入する、「<a href=「 http://invisible.net/ 「>http://invisible.net/</a>」。」
Rose Informational [Page 15] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[15ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
2.3.1.6 The iref Element
2.3.1.6 iref Element
The "iref" element is used to add information to an index. The mandatory "item" attribute is the primary key the information is stored under, whilst the optional "subitem" attribute is the secondary key, e.g.,
"iref"要素は、情報をインデックスに追加するのに使用されます。 義務的な「項目」属性は情報が保存される主キーです、任意の"「副-項目」"属性は例えばセカンダリキーですが
<iref item="indexing" subitem="how to" />
<irefの品目=「インデックス」「副-項目」が等しい、「」 />へのどのように
Finally, note that the "iref" element is always empty -- it never contains any text.
最終的に、"iref"要素がいつも空であることに注意してください--それはどんなテキストも決して含んでいません。
2.3.1.7 The vspace Element
2.3.1.7 vspace Element
The "vspace" element, which may occur only inside the "t" element, is used by the author to provide formatting guidance to the XML application. There is an attribute, "blankLines", that indicates the number of blank lines that should be inserted. A physical linebreak is specified by using the default value, "0".
"vspace"要素(「t」要素だけの中に現れるかもしれない)は、形式指導をXMLアプリケーションに提供するのに作者によって使用されます。 属性、挿入されるべきである空白行の数を示す「blankLines」があります。 デフォルト値を使用する「0インチ」物理的なlinebreakは指定されます。
In addition, the "vspace" element can be used to force a new physical paragraph within a list item, e.g.,
さらに、例えばリスト項目の中で新しい物理的なパラグラフを強制するのに"vspace"要素を使用できます。
<list style="numbers">
<t>This is list item.
<vspace blankLines="1" />
This is part of the same list item,
although when displayed, it appears
as a separate physical paragraph.</t>
</list>
<リストスタイルが等しい、「数、「><t>Thisはリスト項目です」。 1インチ/>のThisは同じリスト項目の一部です、表示すると、別々の物理的なパラグラフとして現れますが。<vspace blankLinesは「</t></は>を記載すること」と等しいです。
An XML application producing a text version of the document should exercise care when encountering a value for "blankLines" that causes a pagebreak -- in particular, if a "vspace" element causes a pagebreak, then no further blank lines should be inserted. This allows authors to "force" a pagebreak by using an arbitrarily large value, e.g., "blankLines='100'".
pagebreakを引き起こす「blankLines」のために値に遭遇するとき、ドキュメントのテキストバージョンを生産するXMLアプリケーションは注意するべきです--"vspace"要素がpagebreakを引き起こすなら、特に、一層の空白行を全く挿入するべきではありません。 これは、作者が任意に大きい値、例えば、「blankLines='100'」を使用することによってpagebreakを「強制すること」を許容します。
Finally, note that the "vspace" element is always empty -- it never contains any text.
最終的に、"vspace"要素がいつも空であることに注意してください--それはどんなテキストも決して含んでいません。
Rose Informational [Page 16] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[16ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
2.4 Back matter
2.4 逆件
Finally, the "back" element is used for references and appendices:
最終的に、「逆」要素は参照と付録に使用されます:
...
</middle>
<back>
<references>
<reference ...>
<reference ...>
</references>
<section ...>
<section ...>
</back>
</rfc>
... </中央の逆>の><参照><<参照…><参照…></参照><部…><部…></逆></rfc>。
The "back" element consists of an optional "references" element, and, one or more optional "section" elements. The "back" element itself is optional, if your document doesn't have any references or appendices, you don't have to include it.
そして、「逆」要素は任意の「参照」要素から成ります。1任意の「セクション」の要素。 「逆」要素自体は任意です、あなたのドキュメントにどれか参照や付録がないなら、あなたがそれを入れる必要はありません。
2.4.1 The references Element
2.4.1 参照Element
The "references" element contains the document's bibliography. It contains one or more "reference" elements.
「参照」要素はドキュメントの図書目録を含んでいます。 それは1つ以上の「参照」要素を含んでいます。
Each "reference" element contains a "front" element and one or more optional "seriesInfo" elements.
それぞれの「参照」要素は「前」の要素と1つ以上の任意の"seriesInfo"要素を含んでいます。
We've already discussed the "front" element back in Section 2.2.
私たちは既にセクション2.2の「前」の要素について議論しました。
The "seriesInfo" element has two attributes, "name" and "value" that identify the document series and series entry, respectively.
"seriesInfo"要素には、それぞれドキュメントシリーズとシリーズエントリーを特定する2つの属性、「名前」、および「値」があります。
Rose Informational [Page 17] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[17ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
The "reference" element has an optional "anchor" attribute that is used for cross-referencing with the "xref" element (Section 2.3.1.4), e.g.,
「参照」要素には"xref"で参照箇所に交差している要素に使用される任意の「アンカー」属性がある、(セクション2.3 .1 .4、)例えば。
<reference anchor="refs.RFC2200">
<front>
<title>Internet Official Protocol Standards</title>
<author initials="J." surname="Postel"
fullname="Jon Postel">
<organization abbrev="ISI">
USC/Information Sciences Institute
</organization>
</author>
<参照アンカー=「「公式のプロトコル標準</タイトル><が書く>の前の><タイトル><インターネットは=に頭文字をつける」というrefs.RFC2200J.」姓=の「ポステル」fullnameが等しい、「ジョン・ポステル、「><組織abbrevが等しい、「ISI「>USC/情報科学研究所</組織の></作者>」
<date month="June" year="1997" />
</front>
<seriesInfo name="RFC" value="2200" />
<seriesInfo name="STD" value="1" />
</reference>
"STD"「2200」/><seriesInfo「1997」/></前部><seriesInfo名前="RFC"「6月」年間の<日付の月==価値=名=値は「1インチ/>の</参照>」と等しいです。
The "reference" element also has an optional "target" attribute that is used for external references (c.f., Section 2.3.1.5). The XML application, if producing an HTML version of the document will use the "target" attribute accordingly; however, if the "name" attribute of the "seriesInfo" element has the value "RFC", then the XML application should automatically provide an appropriate default for the "target" attribute (e.g., "http://example.com/rfcs/rfc2200.txt").
また、「参照」要素には外部参照に使用される任意の「目標」属性がある、(c.f.、セクション2.3 .1 .5)。 XMLアプリケーションであり、生産すると、ドキュメントのHTMLバージョンはそれに従って、「目標」属性を使用するでしょう。 しかしながら、値の"RFC"が"seriesInfo"要素の「名前」属性にあるなら、XMLアプリケーションは自動的に「目標」属性(例えば、" http://example.com/rfcs/rfc2200.txt ")に適切なデフォルトを提供するべきです。
2.4.2 Appendices
2.4.2 付録
To include appendices after the bibliography, simply add more "section" elements. (For an example, look at the example at the beginning of Section 2.4.)
図書目録の後に付録を含むには、単により多くの「セクション」要素を加えてください。 (例がないかどうか、セクション2.4の始めに例を見てください。)
2.4.3 Copyright Status
2.4.3 著作権状態
The copyright status for the document is not included in the document's markup -- this is automatically inserted by an XML application that produces either a text or HTML version of the document.
ドキュメントのための著作権状態はドキュメントのマークアップに含まれていません--これはドキュメントのテキストかHTMLバージョンのどちらかを製作するXMLアプリケーションで自動的に挿入されます。
Rose Informational [Page 18] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[18ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
3. Processing the XML Source File
3. XMLソースファイルを処理します。
This section concerns itself with applications that operate on an XML source file. A lot of XML tools are available, as are many lists of XML resources, e.g., Cafe con Leche [5].
このセクションはXMLソースファイルを作動させるアプリケーションに携わります。 多くのXMLツールがXMLリソースの多くのリストのように利用可能である、例えば、CafeはLeche[5]をだまします。
There are two kinds of XML tools: validating and non-validating. Both check that the source file conforms to the rules given in Section 2.1. However, in addition to making sure that the source file is well-formed, a validating tool also reads the DTD referenced by the source file to make sure that they match. There are a number of both validating and non-validating tools available.
2種類のXMLツールがあります: 有効にして非有効にします。 両方が、ソースファイルがセクション2.1で与えられた規則に一致しているのをチェックします。 しかしながら、ソースファイルが確実に整形式になるようにすることに加えて、有効にするツールはまた、ソースファイルによって参照をつけられる、彼らが合っているのを確実にするDTDを読みます。 有効にするのと非の有効にするツールの利用可能な多くの両方があります。
3.1 Editing
3.1 編集
There are several XML editors available. Ideally, you want an editor that validates. This has two advantages:
手があいている数人のXMLエディタがいます。 理想的に、あなたはそれが有効にするエディタが欲しいです。 これには、2つの利点があります:
o the editor provides guidance in fleshing-out the document
structure; and,
o エディタはドキュメント構造を太らせるのに指導を提供します。 そして
o the editor validates that the source file matches the rules in the
DTD.
o エディタはそれを有効にします。ソースファイルはDTDにおける規則に合っています。
There are two major modes in Emacs that support XML: tdtd [6] and psgml [7]. The latter mode allows you to validate the source file (by calling an external program). If you visit the source file in Emacs and the major mode isn't "SGML" or "XML", then usually all it takes is adding these lines to your ".emacs" file:
XMLをサポートするEmacsには2つの長音階があります: tdtd[6]とpsgml[7]。 後者のモードで、あなたはソースファイル(外部プログラムを呼ぶのによる)を有効にすることができます。 長音階があなたがEmacsでソースファイルを訪問して、「SGML」か"XML"でないなら、通常、それが取るすべてがあなたの".emacs"ファイルにこれらの系列を追加しています:
(setq auto-mode-alist
(cons (cons "\\.xml$" 'sgml-mode) auto-mode-alist))
「(setq、自動モード船が傾いている、(まやかし、(」 \\.xml$をだます、」、'sgml-モード)、自動モード船が傾いている、)、'
and then restarting Emacs. If this doesn't work, try one of the sources above.
そして、Emacsを再開すること。 これが働いていないなら、上のソースのひとりを試してください。
The author uses both sgml-mode in Emacs, and a commercial validating editor, Clip! version 1.5 [8], when editing source files.
ソースファイルを編集するとき、作者はEmacsにおけるsgml-モードとエディタを有効にするコマーシャル、Clip!バージョン1.5[8]の両方を使用します。
3.1.1 Checking
3.1.1 照合
If your editor doesn't validate, then you should run a program to validate the source file.
あなたのエディタが有効にしない、そして、あなたは、ソースファイルを有効にするためにプログラムを動かすべきです。
The author uses the AlphaWorks XML parser [9] for this purpose. It requires that your system have a Java virtual machine. In addition to Java, there are validating parsers written in C, Perl, Python, and Tcl.
作者は[9] このためにAlphaWorks XMLパーサを使用します。 それは、あなたのシステムにはJava仮想マシンがあるのを必要とします。 Javaに加えて、Cに書かれたパーサを有効にする、Perl、パイソン、およびTclがあります。
Rose Informational [Page 19] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[19ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
3.2 Converting to Text Format
3.2 テキスト形式に変えること。
The author has written the xml2rfc tool [10], which reads the source file and produces both a text and HTML version of the document. (This memo was produced using the xml2rfc tool.) Note that xml2rfc isn't a validating tool, so it's a good idea to use either a validating editor or run a stand-alone validating parser prior to using the tool.
作者は、ツール[10]をxml2rfcに書いて、ドキュメントのテキストとHTMLバージョンを生産物の両方に書きました。(ツールはソースファイルを読みます)。 (このメモはxml2rfcツールを使用することで製作されました。) 有効にしているエディタを使用するか、またはツールを使用する前にスタンドアロンの有効にするパーサを実行するのが、名案であるためにxml2rfcが有効にするツールでないことに注意してください。
3.3 Converting to HTML Format
3.3 HTML形式に変えること。
The XML Style Language (XSL) is used to describe transformations from the source file into some other structured file. So, ideally you should use an XSL-capable formatter to convert an XML source file to HTML.
XML様式Language(XSL)は、ソースファイルから変換についてある他の構造化ファイルの中に説明するのに使用されます。 それで、理想的に、あなたは、XMLソースファイルをHTMLに変換するのにXSLできるフォーマッタを使用するべきです。
However, as of this writing XSL is still in considerable flux. (Hence, no reference was included in this memo, as by the time you read this section, the reference would be outdated.) So, in the interim, the author uses the xml2rfc tool for this purpose, even though this tool doesn't provide much flexibility in its HTML layout.
しかしながら、この書くこと現在、まだかなりのフラックスにはXSLがあります。 (したがって、指示するものは全くこのメモに含まれていませんでした、あなたがこのセクションを読む時までに参照が時代遅れであるだろうというときに。) そのように、そして、その間、作者はこのためにxml2rfcツールを使用します、このツールが多くの柔軟性をHTMLレイアウトに提供しませんが。
3.4 Viewing
3.4 見ること
Browsers that support either XSL or Cascading Style Sheets (CSS) are able to view the source file directly.
スタイルシート(CSS)をXSLかCascadingのどちらかにサポートするブラウザは直接ソースファイルを見ることができます。
At present, the author doesn't use any of these browsers, instead converting source files to either text or HTML.
現在のところ、代わりにテキストかHTMLのどちらかにソースファイルを変換して、作者はこれらのブラウザのいずれも使用しません。
3.5 Searching
3.5 探すこと
As with text editors, any text-oriented search tool (e.g., grep) can be used on the source file. However, there are search tools available that understand structured source.
テキストエディタなら、ソースファイルの上でどんなテキスト指向の検索ツール(例えば、grep)も使用できます。 しかしながら、構造化されたソースを理解している利用可能な検索ツールがあります。
The author uses sgrep version 1.9 [11] for this purpose, e.g.
作者は例えば[11] このためにsgrepバージョン1.9を使用します。
sgrep -g xml 'ELEMENTS("title") not in ELEMENTS("back")' \
writing-rfcs.xml
sgrep-g xml'Elements(「逆」)でないところのElements(「タイトル」)'\書くこと-rfcs.xml
which extracts the title element from the source file.
ソースファイルからタイトル要素を抜粋します。
Rose Informational [Page 20] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[20ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
4. Security Considerations
4. セキュリティ問題
This memo raises no security issues; however, according to [2], your document should contain a section near the end that discusses the security considerations of the protocol or procedures that are the main topic of your document, e.g.,
このメモは安全保障問題を全く提起しません。 しかしながら、[2]によると、あなたのドキュメントは終わり頃の例えばあなたのドキュメントの主な話題であるプロトコルか手順のセキュリティ問題について論ずるセクションを含むはずです。
<middle>
...
<section title="Security Considerations">
<t>This memo raises no security issues;
however,
according to <xref target="refs.RFC2223" />,
your document should contain a section near the end
that discusses the security considerations of the
protocol or procedures that are the main topic of your
document.</t>
</section>
</middle>
<の中央>… <セクションタイトルが等しい、「セキュリティConsiderations、「><t>Thisメモは安全保障問題を全く提起しません」。 しかしながら、<xref目標="refs.RFC2223"/>によると、あなたのドキュメントは終わり頃の. あなたのドキュメントの</t></部の></中央の>の主な話題であるプロトコルか手順のセキュリティ問題について論ずるセクションを含むはずです。
Rose Informational [Page 21] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[21ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
References
参照
[1] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998.
[1]ワールドワイドウェブコンソーシアム、「拡張マークアップ言語(XML)1インチ、W3C XML、1998年2月。」
[2] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[2] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[3] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[5] http://metalab.unc.edu/xml/
[5] http://metalab.unc.edu/xml/
[6] http://www.mulberrytech.com/tdtd/
[6] http://www.mulberrytech.com/tdtd/
[7] http://www.inria.fr/koala/plh/sxml.html
[7] http://www.inria.fr/koala/plh/sxml.html
[8] http://www.t2000-usa.com/
[8] http://www.t2000-usa.com/
[9] http://www.alphaworks.ibm.com/formula/xml/
[9] http://www.alphaworks.ibm.com/formula/xml/
[10] http://memory.palace.org/authoring/
[10] http://memory.palace.org/authoring/
[11] http://www.cs.helsinki.fi/~jjaakkol/sgrep.html
[11] http://www.cs.helsinki.fi/~jjaakkol/sgrep.html
Author's Address
作者のアドレス
Marshall T. Rose Invisible Worlds, Inc. 660 York Street San Francisco, CA 94110 US
マーシャルT.のバラの目に見えない世界Inc.660ヨーク・通りサンフランシスコ(カリフォルニア)94110米国
Phone: +1 415 695 3975 EMail: mrose@not.invisible.net URI: http://invisible.net/
以下に電話をしてください。 +1 3975年の415 695メール: mrose@not.invisible.net ユリ: http://invisible.net/
Rose Informational [Page 22] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[22ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
Appendix A. The rfc Element
付録A.はrfc Elementです。
The "<rfc>" tag at the beginning of the file, with only an "ipr" attribute (Section 2.2.7.1), produces an Internet-Draft. However, when other attributes are added to this tag by the RFC editor, an RFC is produced, e.g.,
"ipr"属性だけがあるファイルの始めの「<rfc>」タグ、(セクション2.2 .7 .1) インターネット草稿を作成します。 しかしながら、他の属性がRFCエディタによってこのタグに加えられるとき、RFCは例えば生産されます。
<rfc number="2200"
obsoletes="2000, 1920, 1880, 1800, ..."
category="std"
seriesNo="1">
<rfc番号=「2200」が=を時代遅れにする、「2000、1920、1880、1800、」 …カテゴリ="std"seriesNo=「1インチの>」
At a minimum, the "number" attribute should be present.
最小限では、「数」属性は存在しているべきです。
The other attributes are:
他の属性は以下の通りです。
o "obsoletes", having a comma-separated list of RFC numbers, that
the document obsoletes;
o 「時代遅れに」、有aがRFC番号のリストをコンマで切り離して、それがドキュメントである、時代遅れにします。
o "updates", having a comma-separated list of RFC numbers, that the
document updates;
o 「アップデート」、有aはRFC番号のリストをコンマで切り離して、それはドキュメント最新版です。
o "category", having one of these values:
o これらの1つを持っている「カテゴリ」が以下を評価します。
1. "std", for a Standards-Track document;
1. Standards-道のドキュメントのための「std」。
2. "bcp", "for a Best Current Practices document;
2. "bcp"、「Best Current Practicesドキュメント」。
3. "exp", for an Experimental Protocol document;
3. Experimentalプロトコルドキュメントのための「exp」。
4. "historic", for a historic document; or,
4. 歴史的文書に「歴史的」。 または
5. "info", the default, for an Informational document.
5. 「インフォメーション」、Informationalドキュメントのためのデフォルト。
o "seriesNo", having the corresponding number in the STD (std), BCP
(bcp), or FYI (info) series.
o "seriesNo"、STDに対応する数を持っているか(std)、BCP(bcp)、またはFYI(インフォメーション)シリーズ。
Finally, a special entity, "&rfc.number;", is available. Authors preparing an RFC should use this entity whenever they want to reference the number of the RFC within the document itself. In printed versions of the document, the appropriate substitution (or "XXXX") will occur.
「」 最終的にa特別な実体rfc.number」は利用可能です。 彼らがドキュメント自体の中にRFCの数が参照に欲しいときはいつも、RFCを準備している作者はこの実体を使用するべきです。 ドキュメントの印刷されたバージョンでは、適切な代替(または、"XXXX")は起こるでしょう。
Rose Informational [Page 23] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[23ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
Appendix B. The RFC DTD
付録B.はRFC DTDです。
<!--
DTD for the RFC document series, draft of 99-01-30
-->
<!--RFCドキュメントシリーズのためのDTD、99-01-30の草稿-->。
<!--
Contents
<!--コンテンツ
DTD data types
DTDデータ型
The top-level
トップレベル
Front matter
前の件
The Body
ボディー
Back matter
-->
逆件-->。
<!--
DTD data types:
<!--DTDデータ型:
entity description
====== ===============================================
NUMBER [0-9]+
NUMBERS a comma-separated list of NUMBER
実体記述====== =============================================== NUMBER[0-9]+民数記はNUMBERのコンマで切り離されたリストです。
DAY the day of the month, e.g., "1"
MONTH the month of the year, e.g., "January"
YEAR a four-digit year, e.g., "1999"
DAYは月、例えば、「1年の月の1インチの月、例えば、4ケタの年間の「1月」年、例えば、「1999」」の日です。
URI e.g., "http://invisible.net/"
URI、例えば、" http://invisible.net/ "
ATEXT/CTEXT printable ASCII text (no line-terminators)
ATEXT/CTEXTの印刷可能なASCIIテキスト(系列ターミネータがありません)
TEXT character data
-->
TEXTキャラクタデータ-->。
<!ENTITY % NUMBER "CDATA"> <!ENTITY % NUMBERS "CDATA">
<!実体%番号、「CDATA、「><!実体%番号、「CDATA">"
<!ENTITY % DAY "CDATA"> <!ENTITY % MONTH "CDATA"> <!ENTITY % YEAR "CDATA">
<!実体%日、「CDATA、「><!実体%月、「CDATA、「><!実体%年、「CDATA">"
Rose Informational [Page 24] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[24ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
<!ENTITY % URI "CDATA">
<!実体%ユリ、「CDATA">"
<!ENTITY % ATEXT "CDATA"> <!ENTITY % CTEXT "#PCDATA">
<!実体%ATEXT、「CDATA「><!実体%CTEXT」#PCDATA">"
<!ENTITY % TEXT "#PCDATA">
「<!実体%テキスト」#PCDATA">"
<!ENTITY rfc.number "2629">
<!ENTITY rfc.number、「2629">"
<!--
The top-level
-->
<!--トップレベル-->。
<!--
attributes for the "rfc" element are supplied by the RFC
editor. when preparing drafts, authors should leave them blank.
"rfc"要素のための属性はRFCエディタによって供給されます。<!--草稿を準備するとき、作者は彼らを空白の状態でおくべきです。
the "seriesNo" attribute is used if the category is, e.g., BCP.
-->
<!ELEMENT rfc (front,middle,back?)>
<!ATTLIST rfc
number %NUMBER; #IMPLIED
obsoletes %NUMBERS; ""
updates %NUMBERS; ""
category (std|bcp|info|exp|historic)
"info"
seriesNo %NUMBER; #IMPLIED
ipr (full2026|noDerivativeWorks2026|none)
#IMPLIED
docName %ATEXT; #IMPLIED>
カテゴリが使用するなら、"seriesNo"属性は例えば使用されています。BCP。 --><!ELEMENT rfc(前の、そして、中央の、そして、逆?)><!ATTLIST rfc数の%NUMBER。 #IMPLIEDは%民数記を時代遅れにします。 「「アップデート%民数記」 「「カテゴリ、(std|bcp|インフォメーション| exp|、歴史的である、)、「インフォメーション」 seriesNo%NUMBER」 #IMPLIED ipr(full2026| noDerivativeWorks2026| なにも)#IMPLIED docName%ATEXT。 #暗示している>。
<!--
Front matter
-->
<!--前の件-->。
<!ELEMENT front (title,author+,date,area*,workgroup*,keyword*,
abstract?,note*)>
ELEMENTが向かう<!(タイトル、+、日付、領域*、ワークグループ*、キーワード*が抜き取る作者?、注意*)>。
<!-- the "abbrev" attribute is used for headers, etc. -->
<!ELEMENT title (%CTEXT;)>
<!ATTLIST title
abbrev %ATEXT; #IMPLIED>
<!--"abbrev"属性はヘッダーなどに使用されます。 --><!ELEMENTタイトル(%CTEXT;)><!ATTLISTタイトルabbrev%ATEXT。 #暗示している>。
<!ELEMENT author (organization,address?)> <!ATTLIST author
<!ELEMENTは(組織、アドレス?)を書きます。ATTLISTが書く><!
Rose Informational [Page 25] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[25ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
initials %ATEXT; #IMPLIED
surname %ATEXT; #IMPLIED
fullname %ATEXT; #IMPLIED>
イニシャル%ATEXT。 #IMPLIED姓の%ATEXT。 #IMPLIED fullname%ATEXT。 #暗示している>。
<!ELEMENT organization
(%CTEXT;)>
<!ATTLIST organization
abbrev %ATEXT; #IMPLIED>
<!ELEMENT組織(%CTEXT;)><!ATTLIST組織abbrev%ATEXT。 #暗示している>。
<!ELEMENT address (postal?,phone?,facsimile?,email?,uri?)>
ELEMENTが扱う<!(郵便であるか、電話?、ファクシミリ(メールする)、uri)?>。
<!-- at most one of each the city, region, code, and country
elements may be present -->
<!ELEMENT postal (street+,(city|region|code|country)*)>
<!ELEMENT street (%CTEXT;)>
<!ELEMENT city (%CTEXT;)>
<!ELEMENT region (%CTEXT;)>
<!ELEMENT code (%CTEXT;)>
<!ELEMENT country (%CTEXT;)>
<!ELEMENT phone (%CTEXT;)>
<!ELEMENT facsimile (%CTEXT;)>
<!ELEMENT email (%CTEXT;)>
<!ELEMENT uri (%CTEXT;)>
<!; 高々都市(領域)がコード化するそれぞれの1つ; (%CTEXT;)>。
<!ELEMENT date EMPTY>
<!ATTLIST date
day %DAY; #IMPLIED
month %MONTH; #REQUIRED
year %YEAR; #REQUIRED>
<!ELEMENT日付EMPTY><!ATTLISTは日%DAYとデートします。 #暗示している月の%月。 #%年の必要な年。 #必要な>。
<!-- meta-data... --> <!ELEMENT area (%CTEXT;)> <!ELEMENT workgroup (%CTEXT;)> <!ELEMENT keyword (%CTEXT;)>
<(メタデータ)! --><!ELEMENT領域(%CTEXT;)><!ELEMENTワークグループ(%CTEXT;)><!ELEMENTキーワード(%CTEXT;)>。
<!ELEMENT abstract (t)+>
<!ELEMENT note (t)+>
<!ATTLIST note
title %ATEXT; #REQUIRED>
<!のELEMENTの抽象的な(t)+><!ELEMENT注意(t)+><!ATTLISTはタイトル%ATEXTに注意します。 #必要な>。
<!--
The body
-->
<!--ボディー-->。
<!ELEMENT middle (section)+>
<!のELEMENTの中央(セクション)+>。
Rose Informational [Page 26] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[26ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
<!ELEMENT section (t|figure|section)*>
<!ATTLIST section
anchor ID #IMPLIED
title %ATEXT; #REQUIRED>
<!ELEMENTセクション(t|図|セクション)*><!ATTLISTセクションアンカーID#IMPLIEDタイトル%ATEXT。 #必要な>。
<!ELEMENT t (%TEXT;|list|figure|xref|eref|iref|vspace)*>
<!ATTLIST t
hangText %ATEXT; #IMPLIED>
<!ELEMENT t(%TEXT; | リスト|図|xref| eref|iref|vspace)*><!ATTLIST t hangText%ATEXT。 #暗示している>。
<!-- the value of the style attribute is inherited from the closest
parent -->
<!ELEMENT list (t+)>
<!ATTLIST list
style (numbers|symbols|hanging|empty)
"empty">
スタイル属性の値が最も近い親から引き継がれるという><!ELEMENTリスト(t+)><!ATTLISTが記載する<!が流行に合わせる、(数|シンボル|絞首刑| 空になってください)「">"を空にしてください。
<!ELEMENT xref (%CTEXT;)>
<!ATTLIST xref
target IDREF #REQUIRED
pageno (true|false) "false">
<!ELEMENT xref(%CTEXT;)><!ATTLIST xrefがIDREF#REQUIRED pagenoを狙う、(本当である、| 虚偽)、「誤った">"
<!ELEMENT eref (%CTEXT;)>
<!ATTLIST eref
target %URI; #REQUIRED>
<!ELEMENT eref(%CTEXT;)><!ATTLIST eref目標%URI。 #必要な>。
<!ELEMENT iref EMPTY>
<!ATTLIST iref
item %ATEXT; #REQUIRED
subitem %ATEXT; "">
<!ELEMENT iref EMPTY><!ATTLIST iref項目%ATEXT。 #REQUIRED subitem%ATEXT。 「">"
<!ELEMENT vspace EMPTY>
<!ATTLIST vspace
blankLines %NUMBER; "0">
<!ELEMENT vspace EMPTY><!ATTLIST vspace blankLines%NUMBER。 「0インチの>」
<!ELEMENT figure (preamble?,artwork,postamble?)>
<!ATTLIST figure
anchor ID #IMPLIED
title %ATEXT; "">
<!ELEMENTが計算する、(序文?、アートワーク、ポストアンブル)?><!ATTLISTはアンカーID#IMPLIEDタイトル%ATEXTについて計算します。 「">"
<!ELEMENT preamble (%TEXT;|xref|eref|iref)*>
<!ELEMENT artwork (%TEXT;)*>
<!ATTLIST artwork
xml:space (default|preserve) "preserve">
<!ELEMENT postamble (%TEXT;|xref|eref|iref)*>
<!ELEMENT序文(%TEXT; | xref|eref|iref)*><!ELEMENTアートワーク(%TEXT;)*><!ATTLISTアートワークxml: スペース(デフォルト|保護区)、「「><!ELEMENTポストアンブル(%TEXT; | xref|eref|iref)*>」を保存してください。
<!--
Back matter
<!--逆件
Rose Informational [Page 27] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[27ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
-->
-->。
<!-- sections, if present, are appendices --> <!ELEMENT back (references?,section*)>
<!--存在しているなら、セクションは付録です--ELEMENTが支持する><!(参照?、セクション*)>。
<!ELEMENT references (reference+)>
<!ELEMENT reference (front,seriesInfo*)>
<!ATTLIST reference
anchor ID #IMPLIED
target %URI; #IMPLIED>
<!ELEMENT seriesInfo EMPTY>
<!ATTLIST seriesInfo
name %ATEXT; #REQUIRED
value %ATEXT; #REQUIRED>
<!ELEMENT参照(参照+)><!ELEMENT参照(seriesInfo*、向かってください)><!ATTLIST参照アンカーID#IMPLIED目標%URI。 #IMPLIED><!ELEMENT seriesInfo EMPTY><!ATTLIST seriesInfoは%をATEXTと命名します。 #REQUIREDは%ATEXTを評価します。 #必要な>。
Rose Informational [Page 28] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[28ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
Appendix C. Acknowledgements
付録C.承認
The author gratefully acknowledges the contributions of: Alan Barrett, Brad Burdick, Brian Carpenter, Steve Deering, Patrik Faltstrom, Jim Gettys, Carl Malamud, Chris Newman, Kurt Starsinic, and, Frank Strauss.
作者は感謝して以下の貢献を承諾します。 そして、アラン・バーレット、ブラッド・バーディック、ブライアンCarpenter、スティーブ・デアリングパトリクFaltstrom、ジムGettys、カール・マラマッド、クリス・ニューマン、カートStarsinic、フランク・ストラウス。
Rose Informational [Page 29] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[29ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
Index
インデックス
I
indexing
how to 16
16へのどのようにに索引をつける私
Rose Informational [Page 30] RFC 2629 Writing I-Ds and RFCs using XML June 1999
ローズ情報[30ページ]のRFC2629書くことのI-Dsと1999年6月にXMLを使用するRFCs
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rose Informational [Page 31]
ローズInformationalです。[31ページ]
一覧
スポンサーリンク
