RFC3470 日本語訳
3470 Guidelines for the Use of Extensible Markup Language (XML) withinIETF Protocols. S. Hollenbeck, M. Rose, L. Masinter. January 2003. (Format: TXT=64252 bytes) (Also BCP0070) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck
Request for Comments: 3470 VeriSign, Inc.
BCP: 70 M. Rose
Category: Best Current Practice Dover Beach Consulting, Inc.
L. Masinter
Adobe Systems Incorporated
January 2003
Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3470ベリサインInc.BCP: 70M.バラカテゴリ: Inc.L.Masinterアドビ・システムズ株式会社2003年1月に相談する最も良い現在の練習ドーヴァービーチ
Guidelines for the Use of Extensible Markup Language (XML)
within IETF Protocols
IETFプロトコルの中の拡張マークアップ言語(XML)の使用のためのガイドライン
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
拡張マークアップ言語(XML)は、データを構造化するためのフレームワークです。 Standard Generalized Markup Language(SGML)から発展しましたが(マークアップ言語は、ドキュメントを構造化するのは主として焦点を合わせました)、XMLは、構造化されたデータを表すための広く使用されたメカニズムになるように発展しました。
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.
開発されていて、さまざまなインターネットプロトコルがあります。 多くで、構造化されたデータの表現の必要性は彼らのアプリケーションに関連するようになります。 表現メソッドとしてXMLの使用における大きな関心がありました。 このドキュメントは、基本のXML概念について説明して、XMLの使用で様々な代替手段を分析して、IETF標準化過程プロトコルの中でXMLの使用のためのガイドラインを提供します。
Table of Contents
目次
Conventions Used In This Document . . . . . . . . . . . . . . . . 2
1. Introduction and Overview . . . . . . . . . . . . . . . . . 2
1.1 Intended Audience. . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 XML Evolution . . . . . . . . . . . . . . . . . . . . 3
1.4 XML Users, Support Groups, and Additional
Information. . . . . . . . . . . . . . . . . . . . . . 4
2. XML Selection Considerations . . . . . . . . . . . . . . . . 4
3. XML Alternatives . . . . . . . . . . . . . . . . . . . . . . 5
コンベンションは本書では.2 1を使用しました。 序論と概要. . . . . . . . . . . . . . . . . 2 1.1対象とする訪問者。 . . . . . . . . . . . . . . . . . . 3 1.2 範囲. . . . . . . . . . . . . . . . . . . . . . . . 3 1.3XML発展. . . . . . . . . . . . . . . . . . . . 3 1.4XMLユーザ、援助グループ、および追加情報。 . . . . . . . . . . . . . . . . . . . . . 4 2. XML選択問題. . . . . . . . . . . . . . . . 4 3。 XML代替手段. . . . . . . . . . . . . . . . . . . . . . 5
Hollenbeck, et al. Best Current Practice [Page 1] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[1ページ]RFC3470XML
4. XML Use Considerations and Recommendations . . . . . . . . . 7
4.1 XML Syntax and Well-Formedness . . . . . . . . . . . . 7
4.2 XML Information Set . . . . . . . . . . . . . . . . . 7
4.3 Syntactic Restrictions . . . . . . . . . . . . . . . . 8
4.4 XML Declarations . . . . . . . . . . . . . . . . . . . 9
4.5 XML Processing Instructions . . . . . . . . . . . . . 9
4.6 XML Comments . . . . . . . . . . . . . . . . . . . . . 10
4.7 Validity and Extensibility . . . . . . . . . . . . . . 10
4.8 Semantics as Well as Syntax. . . . . . . . . . . . . . 12
4.9 Namespaces . . . . . . . . . . . . . . . . . . . . . . 12
4.9.1 Namespaces and Attributes. . . . . . . . . . . . 13
4.10 Element and Attribute Design Considerations. . . . . . 14
4.11 Binary Data and Text with Control Characters . . . . . 16
4.12 Incremental Processing . . . . . . . . . . . . . . . . 16
4.13 Entity Declarations and Entity References . . . . . . 16
4.14 External References . . . . . . . . . . . . . . . . . 17
4.15 URI Processing . . . . . . . . . . . . . . . . . . . . 17
4.16 White Space . . . . . . . . . . . . . . . . . . . . . 18
4.17 Interaction with the IANA . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . 19
5.1 Character Sets and Encodings . . . . . . . . . . . . . 19
5.2 Language Declaration . . . . . . . . . . . . . . . . . 20
5.3 Other Internationalization Considerations . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . 22
10. Informative References . . . . . . . . . . . . . . . . . . . 23
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28
4. XMLは問題と推薦. . . . . . . . . 7 4.1XML構文と井戸-Formedness.74.2XML一組の情報. . . . . . . . . . . . . . . . . 7 4.3の構文の制限. . . . . . . . . . . . . . . . 8 4.4XML宣言を使用します; .94.5 XML処理命令. . . . . . . . . . . . . 9 4.6XMLは構文と同様に.104.7の正当性と伸展性. . . . . . . . . . . . . . 10 4.8意味論について論評します。 . . . . . . . . . . . . . 12 4.9の名前空間. . . . . . . . . . . . . . . . . . . . . . 12 4.9.1の名前空間と属性。 . . . . . . . . . . . 13 4.10の要素と属性は問題を設計します。 . . . . . 制御文字. . . . . 16 4.12の増加の処理. . . . . . . . . . . . . . . . 16 4.13実体宣言がある14 4.11のバイナリ・データとテキストとIANA. . . . . . . . . . . . . . 19 5との実体参照. . . . . . 16 4.14外部参照. . . . . . . . . . . . . . . . . 17 4.15URI処理. . . . . . . . . . . . . . . . . . . . 17 4.16余白.18 4.17相互作用。 国際化問題. . . . . . . . . . . . 19 5.1文字コードとEncodings. . . . . . . . . . . . . 19 5.2言語宣言. . . . . . . . . . . . . . . . . 20 5.3他の国際化問題. . . . . . 20 6。 IANA問題. . . . . . . . . . . . . . . . . . . . 21 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . 21 8。 承認. . . . . . . . . . . . . . . . . . . . . . 22 9。 引用規格. . . . . . . . . . . . . . . . . . . . 22 10。 有益な参照. . . . . . . . . . . . . . . . . . . 23 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 27 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 28
Conventions Used In This Document
本書では使用されるコンベンション
This document recommends, as policy, what specifications for Internet protocols -- and, in particular, IETF standards track protocol documents -- should include as normative language within them. The capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in the sense of how they would be used within other documents with the meanings as specified in BCP 14, RFC 2119 [1].
このドキュメントは方針としてインターネットプロトコル(特にIETF標準化過程プロトコルドキュメント)のための仕様が標準の言語としてそれらの中に含むべきであることを推薦します。 “SHOULD"、“MUST"が「必要である」という大文字で書かれたキーワード、などはそれらが他のドキュメントの中にBCP14での指定されるとしての意味でどう使用されるだろうかに関する意味で使用されます、RFC2119[1]。
1. Introduction and Overview
1. 序論と概要
The Extensible Markup Language (XML, [8]) is a framework for structuring data. While it evolved from the Standard Generalized Markup Language (SGML, [30]) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data in protocol exchanges. See "XML in 10 points" [47] for an introduction to XML.
拡張マークアップ言語、(XML、[8])は、データを構造化するためのフレームワークです。 Standard Generalized Markup Languageから発展されて、それをゆったり過ごしてください。(SGML、[30])--主としてドキュメントを構造化するのに集中しているマークアップ言語--XMLはプロトコル交換における構造化されたデータを表すための広く使用されたメカニズムになるように発展しました。 XMLにおいて序論のための「10ポイントのXML」[47]を見てください。
Hollenbeck, et al. Best Current Practice [Page 2] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[2ページ]RFC3470XML
1.1 Intended Audience
1.1 対象とする訪問者
Many Internet protocol designers are considering using XML and XML fragments within the context of existing and new Internet protocols. This document is intended as a guide to XML usage and as IETF policy for standards track documents. Experienced XML practitioners will likely already be familiar with the background material here, but the guidelines are intended to be appropriate for those readers as well.
多くのインターネットプロトコルデザイナーが、存在することの文脈の中でXMLとXML断片を使用すると考えて、新しいインターネットプロトコルです。 このドキュメントはXML用法へのガイドとして標準化過程ドキュメントのためのIETF方針として意図します。 経験豊富なXML開業医はおそらく既にここのバックグラウンドの材料になじみ深くなるでしょうが、ガイドラインがまた、それらの読者にとって適切であることを意図します。
1.2 Scope
1.2 範囲
This document is intended to give guidelines for the use of XML content within a larger protocol. The goal is not to suggest that XML is the "best" or "preferred" way to represent data; rather, the goal is to lay out the context for the use of XML within a protocol once other factors point to XML as a possible data representation solution. The Common Name Resolution Protocol (CNRP, [24]) is an example of a protocol that would be addressed by these guidelines if it were being newly defined. This document does not address the use of protocols like SMTP or HTTP to send XML documents as ordinary email or web content.
このドキュメントが、より大きいプロトコルの中でXML内容の使用のためのガイドラインを与えることを意図します。 目標はXMLがデータを表す「最も良い」か「都合のよい」方法であると示唆しないことです。 むしろ、目標は他の要素が可能なデータ表現ソリューションとしていったんXMLを示すとプロトコルの中でXMLの使用のための文脈を広げることです。 俗称Resolutionプロトコル、(CNRP、[24])はそれが新たに定義されているならこれらのガイドラインによって扱われるプロトコルに関する例です。 このドキュメントは、普通のメールかウェブ内容としてドキュメントをXMLに送るためにSMTPやHTTPのようなプロトコルの使用を扱いません。
There are a number of protocol frameworks already in use or under development which focus entirely on "XML protocol" -- the exclusive use of XML as the data representation in the protocol. For example, the World Wide Web Consortium (W3C) is developing an XML Protocol framework based on SOAP ([45] and [46]). The applicability of such protocols is not part of the scope of this document.
既に使用中の、または、開発中の多くのプロトコルフレームワークが完全に「XMLは議定書を作るところ」のどの焦点であるか--そこでは、プロトコルにおけるデータ表現としてのXMLの専用? 例えば、ワールドワイドウェブコンソーシアム(W3C)はSOAP([45]と[46])に基づくXMLプロトコルフレームワークを開発しています。 そのようなプロトコルの適用性はこのドキュメントの範囲の一部ではありません。
In addition, there are higher-level representation frameworks, based on XML, that have been designed as carriers of certain classes of information; for example, the Resource Description Framework (RDF, [38]) is an XML-based representation for logical assertions. This document does not provide guidelines for the use of such frameworks.
さらに、XMLに基づくある情報の種類のキャリヤーとして設計されているよりハイレベルの表現フレームワークがあります。 例えば、Resource記述Framework、(リモート・データ・ファシリティ、[38])は論理的な主張のXMLベースの表現です。 このドキュメントはそのようなフレームワークの使用のためのガイドラインを提供しません。
1.3 XML Evolution
1.3 XML発展
XML 1.0 was originally published as a W3C recommendation in February 1998 [35], and was revised in a 2nd edition [8] in October 2000. Several additional facilities have also been defined that layer on the base specification. Although these additions are designed to be consistent with XML 1.0, they have varying levels of stability, consensus, and implementation. Accordingly, this document identifies the major evolutionary features of XML and makes suggestions as to the circumstances in which each feature should be used.
XML1.0は元々W3C推薦として1998年2月の[35]で発行されて、2000年10月に2番目の版[8]で改訂されました。 また、基礎仕様で層にされるいくつかの追加の便宜供与が定義されました。 これらの追加はXML1.0と一致しているように設計されていますが、それらには、異なったレベルの安定性、コンセンサス、および実装があります。 それに従って、このドキュメントは、XMLの主要な進化論の特徴を特定して、各特徴が使用されるべきである事情に関して提案をします。
Hollenbeck, et al. Best Current Practice [Page 3] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[3ページ]RFC3470XML
1.4 XML Users, Support Groups, and Additional Information
1.4 XMLユーザ、援助グループ、および追加情報
There are many XML support groups, with some devoted to the entire XML industry [51], some devoted to developers [52], some devoted to the business applications of XML [53], and many, many groups devoted to the use of XML in a particular context.
多くのXMLサポートグループがあります、全体のXML産業[51]にささげられたいくつか、開発者[52]にささげられたいくつか、XML[53]のビジネス・アプリケーションにささげられたいくつか、および特定の文脈におけるXMLの使用にささげられた多くのグループと共に。
It is beyond the scope of this document to provide a comprehensive list of referrals. Interested readers are directed to the three references above as starting points, as well as their favorite Internet search engine.
それは、紹介に関する総覧を提供するためにこのドキュメントの範囲を超えています。 興味のある読者は出発点としての上記の3つの参照箇所、およびそれらのお気に入りのインターネット検索エンジンに向けられます。
2. XML Selection Considerations
2. XML選択問題
XML is a tool that provides a means towards an end. Choosing the right tool for a given task is an essential part of ensuring that the task can be completed in a satisfactory manner. This section describes factors to be aware of when considering XML as a tool for use in IETF protocols:
XMLは終わりに向かって手段を供給するツールです。 与えられたタスクに正しいツールを選ぶのは、タスクが満足のできるように完成できるのを確実にする不可欠の部分です。 IETFプロトコルにおける使用のためにXMLがツールであるとみなしながら、このセクションはいつを意識しているかために要素について説明します:
1. XML is a meta-markup language that can be used to define markup
languages for specific domains and problem spaces.
1. XMLは特定のドメインと問題空間とマークアップ言語を定義するのに使用できるメタマークアップ言語です。
2. XML provides both logical structure and physical structure to
describe data. Data framing is built-in.
2. XMLは、データについて説明するために論理構造と物理構造の両方を提供します。 データ縁どりは内蔵です。
3. XML instances can be validated against the formal definition of a
protocol specification.
3. プロトコル仕様の公式の定義に対してXMLインスタンスを有効にすることができます。
4. XML supports internationalization.
4. XMLは国際化をサポートします。
5. XML is extensible. Unlike some other markup languages (such as
HTML), new tags (and thus new protocol elements) can be defined
without requiring changes to XML itself.
5. XMLは広げることができます。 ある他のマークアップ言語(HTMLなどの)と異なって、XML自身に釣り銭がいないで、新しいタグ(そして、その結果、新しいプロトコル要素)を定義できます。
6. XML is still evolving. The formal specifications are still being
influenced and updated as use experience is gained and applied.
6. XMLはまだ発展しています。 それでも、形式仕様は、影響を及ぼして、経験が行われる使用としてアップデートして、適用することです。
7. XML does not provide native mechanisms to support detailed data
typing. Additional mechanisms (such as those described in
Section 4.7) are required to specify abstract protocol data
types.
7. XMLは、詳細データタイプをサポートするために固有のメカニズムを提供しません。 追加メカニズム(セクション4.7で説明されたものなどの)は抽象的なプロトコルデータ型を指定しなければなりません。
8. XML is text-based, so XML fragments are easily created, edited,
and managed using common utilities. Further, being text-based
means it more readily supports incremental development,
8. XMLがテキストベースであり、XML断片は、共用設備を使用することで編集されて、容易に作成されるので、管理されます。 さらに、テキストベースであることは、より容易に増加の開発をサポートすることを意味します。
Hollenbeck, et al. Best Current Practice [Page 4] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[4ページ]RFC3470XML
debugging, and logging. A simple "canned" XML fragment can be
embedded within a program as a string constant, rather than
having to be constructed.
デバッグして、登録します。 組み立てられなければならないよりストリング定数としてプログラムの中でむしろ簡単な「缶詰」のXML断片を埋め込むことができます。
9. Binary data has to be encoded into a text-based form to be
represented in XML.
9. バイナリ・データは、XMLに表されるためにテキストベースのフォームにコード化されなければなりません。
10. XML is verbose when compared with many other structured data
representation languages. A representation with element
extensibility and human readability typically requires more bits
when compared to one optimized for efficient machine processing.
10. 他の多くの構造化されたデータ表現言語と比べると、XMLは冗長です。 効率的な機械処理のために最適化された1つと比べると、要素伸展性と人間の読み易さがある表現は、より多くのビットを通常必要とします。
11. XML implementations are still relatively new. As designers and
implementers gain experience, it is not uncommon to find defects
in early and current products.
11. XML実装はまだ比較的新しいです。 デザイナーとimplementersが経験を積むのに従って、早くて現在の製品における欠陥を見つけるのは珍しくはありません。
12. XML support is available in a large number of software
development utilities, available in both open source and
proprietary products.
12. XMLサポートは、多くのソフトウェア開発ユーティリティで利用可能であって、オープンソースと有標製品の両方で利用可能です。
13. XML processing speed can be an issue in some environments. XML
processing can be slower because XML data streams may be larger
than other representations, and the use of general purpose XML
parsers will add a software layer with its own performance costs
(though these costs can be reduced through consistent use of an
optimized parser). In some situations, processing XML requires
examining every byte of the entire XML data stream, with higher
overhead than with representations where uninteresting segments
can be skipped.
13. XML処理速度はいくつかの環境で問題であるかもしれません。 XMLデータ・ストリームが他の表現より大きいかもしれないので、XML処理は、より遅い場合があります、そして、汎用のXMLパーサの使用はそれ自身の性能コストでソフトウェア層を加えるでしょう(最適化されたパーサの一貫した使用でこれらのコストを削減できますが)。 いくつかの状況で、処理XMLは、あらゆるバイトを調べるのを全体のXMLデータ・ストリームを要求します、おもしろくないセグメントをスキップできる表現より高いオーバーヘッドで。
3. XML Alternatives
3. XML代替手段
This document focuses on guidelines for the use of XML. It is useful to consider why one might use XML as opposed to some other mechanism. This section considers some other commonly used representation mechanisms and compares XML to those alternatives.
このドキュメントはXMLの使用のためのガイドラインに焦点を合わせます。 1つがなぜある他のメカニズムと対照的にXMLを使用するかもしれないかを考えるのは役に立ちます。 このセクションは、ある他の一般的に使用された表現がメカニズムであると考えて、それらの代替手段とXMLを比較します。
For many fundamental protocols, the extensibility requirements are modest, and the performance requirements are high enough that fixed binary data blocks are the appropriate representation; mechanisms such as XML merely add bloat. RFC 3252 [23] describes a humorous example of XML as protocol bloat.
多くの基本的なプロトコルに、伸展性要件は穏やかです、そして、性能要件は固定バイナリ・データブロックが適切な表現であることで高いです。 XMLなどのメカニズムは、ふくれるように単に言い足します。 プロトコルがふくれるとき、RFC3252[23]はXMLのユーモラスな例について説明します。
In addition, there are other representation and extensibility frameworks that have been used successfully within communication protocols. For example, Abstract Syntax Notation 1 (ASN.1) [28] along with the corresponding Basic Encoding Rules (BER, [29]) are part of the OSI communication protocol suite, and have been used in
さらに、通信プロトコルの中で首尾よく使用された他の表現と伸展性フレームワークがあります。 例えば、対応するBasic Encoding Rulesと共にSyntax Notation1(ASN.1)[28]を抜き取ってください。(BER、[29])がOSI通信プロトコルスイートの一部である、中で使用されてください、そうした。
Hollenbeck, et al. Best Current Practice [Page 5] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[5ページ]RFC3470XML
many subsequent communications standards (e.g., the ANSI Information Retrieval protocol [27] and the Simple Network Management Protocol (SNMP, [13]). The External Data Representation (XDR, [14]) and variations of it have been used in many other distributed network applications (e.g., the Network File System (NFS) protocol [22]). With some ASN.1 encoding types, data types are explicit in the representation, while with XDR, the data types of components are described externally as part of an interface specification.
例えば、ANSI情報Retrievalは27とSimple Network Managementプロトコル(SNMP、13)について議定書の中で述べます。それのExternal Data Representation(XDR、14)と変化は他の多くの分配されたネットワーク応用(例えば、ネットワークファイルシステム(NFS)プロトコル22)で使用されました。多くのその後のコミュニケーション規格、(何らかのASN.1がタイプをコード化していて、データ型は表現で明白です; コンポーネントに関するデータ型はXDRと共にインターフェース仕様の一部として外部的に記述されていますが。
Many other protocols use data structures directly (without data encapsulation) by describing the data structure with Backus Normal Form (BNF, [25]); many IETF protocols use an Augmented Backus-Naur Form (ABNF, [16]). The Simple Mail Transfer Protocol (SMTP, [21]) is an example of a protocol specified using ABNF.
他の多くのプロトコルが直接(データカプセル化なしで)バッカス記法でデータ構造について説明することによってデータ構造を使用する、(BNF、[25])。 多くのIETFプロトコルがAugmented BN記法を使用します。(ABNF、[16])。 シンプルメールトランスファプロトコル、(SMTP、[21])はABNFを使用することで指定されたプロトコルに関する例です。
ASN.1, XDR, and BNF are described here as examples of alternatives to XML for use in IETF protocols. There are other alternatives, but a complete enumeration of all possible alternatives is beyond the scope of this document.
ASN.1、XDR、およびBNFはIETFプロトコルにおける使用のためにここでXMLへの代替手段に関する例と説明されます。 他の代替手段がありますが、すべての可能な選択肢の悉皆調査はこのドキュメントの範囲を超えています。
Other representation methods may differ from XML in several important ways:
他の表現メソッドはいくつかの重要な方法でXMLと異なるかもしれません:
Text Encoding and character sets: the character encoding used to represent a formal specification. XML defines a consistent character model based on the Universal Character Set (UCS, [31] and [33]), and requires that XML parsers accept at least UTF-8 [4] and UTF-16 [20], and allows for other encodings. While ASN.1 and XDR may carry strings in any encoding, there is no common mechanism for defining character encodings within them. Typically, ABNF definitions tend to be defined in terms of octets or characters in ASCII.
テキストEncodingと文字集合: 文字符号化は以前はよく形式仕様を表していました。 XMLがUniversal文字コードに基づく一貫したキャラクタモデルを定義する、(UCS、[31]、および[33])、XMLパーサが少なくともUTF-8[4]とUTF-16[20]を受け入れるのが必要であり、他のencodingsを考慮します。 ASN.1とXDRはどんなコード化でもストリングを運ぶかもしれませんが、それらの中で文字符号化を定義するためのどんな一般的なメカニズムもありません。 通常、ABNF定義は、ASCIIで八重奏かキャラクタで定義される傾向があります。
Data Encoding: XML is defined as a sequence of characters, rather than a sequence of bytes. XML Schema [42] includes mechanisms for representing some data types (integer, date, array, etc.) but many binary data types are encoded in Base64 [15] or hexadecimal. ASN.1 and XDR have rich mechanisms for encoding a wide variety of data types.
zデータの符号化: XMLはバイトの系列よりむしろキャラクタの系列と定義されます。 XML Schema[42]はいくつかのデータ型(整数、日付、配列など)を表すためのメカニズムを含んでいますが、多くのバイナリ・データタイプがBase64[15]か16進でコード化されます。 ASN.1とXDRには、さまざまなデータ型をコード化するための豊かなメカニズムがあります。
Extensibility: XML has a rich extensibility model such that XML specifications can frequently be versioned independently. Specifications can be extended by adding new element names and attributes (if done compatibly); other extensions can be added by defining new XML namespaces [9], though there is no standard mechanism in XML to indicating whether or not new extensions are mandatory to recognize. Similarly, there are several techniques available to extend ASN.1 specifications. XDR specifications tend to not be independently extensible by different parties because the
伸展性: XMLには、金持ちの伸展性モデルが、頻繁に独自にXML仕様をversionedされることができるように、あります。 新しい要素名と属性を加えることによって、仕様を広げることができます(矛盾なくするなら)。 新しいXML名前空間[9]を定義することによって、他の拡大を加えることができます、どんな標準のメカニズムも新しい拡大が認識するために義務的であるかどうかを示すことへのXMLにありませんが。 同様に、ASN.1仕様を広げるために利用可能ないくつかのテクニックがあります。 XDR仕様は、異なったパーティーが独自に広げることができない傾向があります。
Hollenbeck, et al. Best Current Practice [Page 6] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[6ページ]RFC3470XML
framing and data types are implicit and not self-describing. The extensibility of BNF-based protocol elements needs to be explicitly planned.
縁どりとデータ型は、暗黙で自己について説明していません。 BNFベースのプロトコル要素の伸展性は、明らかに計画される必要があります。
Legibility of protocol elements: As noted above, XML is text-based, and thus carries the advantages (and disadvantages) of text-based protocol elements. Typically this is shared with (A)BNF-defined protocol elements. ASN.1 and XDR use binary encodings which are not easily human readable.
プロトコル要素の読みやすさ: 上で述べたように、XMLはテキストベースであり、その結果、テキストベースのプロトコル要素の利点(そして、損失)を運びます。 通常、これは(A)BNFによって定義されたプロトコル要素と共有されます。 ASN.1とXDRは容易に読み込み可能な状態で人間でない2進のencodingsを使用します。
4. XML Use Considerations and Recommendations
4. XMLは問題と推薦を使用します。
This section notes several aspects of XML and makes recommendations for use. Since the 1998 publication of XML version 1 [35], an editorial second edition [8] was published in 2000; this section refers to the second edition.
このセクションは、XMLのいくつかの局面に注意して、使用のための推薦状をします。 1998年のXMLバージョン1[35]の公表以来、社説の第2版[8]は2000年に発行されました。 このセクションは第2版を示します。
4.1 XML Syntax and Well-Formedness
4.1XML構文と井戸-Formedness
XML [8] is defined in terms of a concrete syntax: a sequence of characters, using the characters "<", "=", "&", etc. as delimiters. An instance is XML if and only if it is well-formed, i.e., all character and markup data conforms to the structural rules defined in section 2.1 of [8].
XML[8]は具象構文で定義されます: デリミタとしてキャラクタ"<"、「=」、“&"などを使用するキャラクタの系列。 そして、インスタンスがXMLである、それが整形式である場合にだけ、すなわちすべてのキャラクタとマーク付けデータは[8]のセクション2.1で定義された構造的な規則に従います。
Character and markup data that is not well-formed is not XML; well-
formedness is the basis for syntactic compatibility with XML.
Without well-formedness, all of the advantages of using XML
disappear. For this reason, it is recommended that protocol
specifications explicitly require XML well-formedness ("MUST be
well-formed").
整形式でないキャラクターとマーク付けデータはXMLではありません。 井戸形成はXMLとの構文の互換性の基礎です。 井戸-形成がなければ、XMLを使用する利点のすべてが見えなくなります。 この理由で、プロトコル仕様が明らかに、XML井戸-形成(「整形式でなければならない」)を必要とするのは、お勧めです。
The IETF has a long-standing tradition of "be liberal in what you accept" that might seem to be at odds with this recommendation. Given that XML requires well-formedness, conforming XML parsers are intolerant of well-formedness errors. When specifying the handing of erroneous XML protocol elements, a protocol design must never recommend attempting to partially interpret non-well-formed instances of an element which is required to be XML. Reasonable behaviors in such a scenario could include attempting retransmission or aborting an in-progress session.
IETFには、この推薦と仲たがいしてあるように思えるかもしれない「あなたが受け入れるものに自由主義者がいる」長年の伝統があります。 XMLが井戸-形成を必要とするなら、従っているXMLパーサは井戸-形成誤りで偏狭です。 誤ったXMLプロトコル要素を手渡すことを指定するとき、プロトコルデザインは、XMLになるのに必要である要素の非整形式のインスタンスを部分的に解釈するのを試みることを決して勧めてはいけません。 そのようなシナリオにおける合理的な振舞いは、「再-トランスミッション」を試みるか、または進行中のセッションを中止するのを含むかもしれません。
4.2 XML Information Set
4.2 XML一組の情報
In addition to the concrete syntax of XML, there is an abstract model of XML content known as the "Information Set" (infoset) [37]. One might think of an XML parser as consuming the concrete syntax and producing an XML Information Set for further processing.
XMLの具象構文に加えて、「一組の情報」(infoset)[37]として知られているXML内容の抽象モデルがいます。 人は具象構文を消費して、さらなる処理のためにXML情報Setを生産するとXMLパーサを考えるかもしれません。
Hollenbeck, et al. Best Current Practice [Page 7] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[7ページ]RFC3470XML
In typical use of XML, the definition of allowable XML documents is often defined in terms of the Information Set of the XML and not the concrete syntax. The notion is that any syntactic representation which yielded the same information set would be treated equivalently.
XMLの典型的な使用では、許容できるXMLドキュメントの定義は具象構文ではなく、XMLの情報Setでしばしば定義されます。 概念は同じ一組の情報をもたらしたどんな統語表示も同等に扱われるだろうということです。
It some cases, protocols have been defined solely in terms of the XML Information Set, or by allowing other concrete syntax representations. However, since the context of XML embedded within other Internet protocols requires an unambiguous definition of the concrete syntax, defining an XML protocol element in terms of its XML Information Set alone and allowing other concrete syntax representations is out of scope for this document.
それ、いくつかのケース、プロトコルは、唯一XML情報Set、または他の具象構文表現を許容することによって、定義されました。 しかしながら、他のインターネットプロトコルの中で埋め込まれたXMLの文脈が具象構文の明白な定義を必要とするので、このドキュメントのための範囲の外にXML情報Setに関して単独でXMLプロトコル要素を定義して、他の具象構文表現を許容するのがあります。
4.3 Syntactic Restrictions
4.3 構文の制限
In some circumstances a protocol designer may be tempted to define an XML-based protocol element as "XML", but at the same time imposing additional restrictions beyond those imposed by the XML recommendation itself -- for example, restricting the document character encoding, or avoiding CDATA sections, character entity references, imposing additional restrictions on use of white space, etc. The general category of restrictions addressed by this section are ones that would allow some but not other of the set of syntactic representations which have the same canonical representation according to canonical XML described in RFC 3076 [6].
いくつかの事情では、プロトコルデザイナーは、XMLベースのプロトコル要素に"XML"を定義づけるように誘惑されますが、同時に、XML推薦自体で課されたものを超えて追加制限を課すかもしれません--例えば、ドキュメント文字符号化を制限するか、またはCDATA部を避けるキャラクタ実体参照、追加制限を余白の使用に課すことなど。 扱われて、このセクションがいくつかを許容しますが、別に許容するというわけではない正準なXMLによると、同じ正準な表現を持っている統語表示のセットの1つであるという制限の一般的なカテゴリはRFCで3076[6]について説明しました。
Making these kinds of restrictions in a protocol definition may have the disadvantage that an implementer of the protocol may not be able to use an otherwise conforming XML processor to parse the XML-based protocol elements. In some cases, the motivation for subsetting XML is to allow implementers to build special-purpose processors that are lighter weight than a full-scale conforming XML processor. There are a number of good, conforming XML parsers that are small, fast, and free, while special-purpose processors have frequently been known to fail to handle some cases of legal XML syntax.
プロトコル定義における、これらの種類の制限をするのにおいてプロトコルのimplementerが使用できないかもしれない不都合があるかもしれない、そうでなければ、XMLベースのプロトコル要素を分析するXMLプロセッサを従わせます。 いくつかの場合、subsetting XMLに関する動機はimplementersが実物大の従っているXMLプロセッサより軽い重さである専用プロセッサを組立てるのを許容することです。 利益の数があります、小さくて、速くて、無料であることのXMLパーサを従わせて、頻繁に専用プロセッサが法的なXML構文に関するいくつかのケースを扱わないのが知られていますが。
In general, such syntactic restrictions should be avoided. In circumstances where restrictions on the variability of the syntactic representation of XML is necessary for one reason or another, designers should consider using "Canonical XML" [6] as the definition of the protocol element, since all such variability has been removed. Some specific issues are discussed in Section 4.4, Section 4.13, and Section 5.1 below.
一般に、そのような構文の制限は避けられるべきです。 XMLの統語表示の可変性における制限が何らかの理由に必要である事情では、デザイナーは、「正準なXML」[6]を使用するのが、プロトコル要素の定義であるとみなすべきです、そのようなすべての可変性を取り除いたので。 以下でセクション4.4、セクション4.13、およびセクション5.1でいくつかの特定の問題について議論します。
Hollenbeck, et al. Best Current Practice [Page 8] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[8ページ]RFC3470XML
4.4 XML Declarations
4.4 XML宣言
An XML declaration (defined in section 2.8 of [8]) is a small header at the beginning of an XML data stream that indicates the XML version and the character encoding used. For example,
XML宣言、([8])のセクション2.8で定義されているのは、XMLバージョンと文字符号化が使用したのを示すXMLデータ・ストリームの始めの小さいヘッダーです。 例えば
<?xml version="1.0" encoding="UTF-8"?>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>。
specifies the use of XML version 1 and UTF-8 character encoding.
XMLバージョン1とUTF-8文字符号化の使用を指定します。
In some uses of XML as an embedded protocol element, the XML used is a small fragment in a larger context, where the XML version is fixed at "1.0" and the character encoding is known to be "UTF-8". In those cases, an XML declaration might add extra overhead. In cases where the XML is a larger component which may find its way alone as an external entity body (transported as a MIME message, for example), the XML declaration is an important marker and is useful for reliability and extensibility. The XML declaration is also an important marker for character set/encoding (see Section 5.1), if any encoding other than UTF-8 or UTF-16 is used. Note that in the case of UTF-16, XML requires that the entity starts with a Byte Order Mark (BOM), which is not part of the character data. Note that the XML Declaration itself is not part of the XML document's Information Set.
埋め込まれたプロトコル要素としてのXMLのいくつかの用途で、使用されるXMLがXMLバージョンが修理されているより大きい文脈の小さい破片である、「1インチと文字符号化は「UTF-8インチ」であることが知られています。 それらの場合では、XML宣言は付加的なオーバーヘッドを加えるかもしれません。 XMLが外部実体本体(MIMEメッセージとして、例えば、輸送される)として単独で届くかもしれないより大きいコンポーネントである場合では、XML宣言は、重要なマーカーであり、信頼性と伸展性の役に立ちます。 また、XML宣言は文字集合/コード化のための重要なマーカー(セクション5.1を見る)です、UTF-8かUTF-16を除いた何かコード化が使用されているなら。 UTF-16の場合では、XMLが、実体がキャラクタデータの一部でないByte Orderマーク(BOM)から始まるのを必要とすることに注意してください。 XML Declaration自身がXMLドキュメントの情報Setの一部でないことに注意してください。
Protocol specifications must be clear about use of XML declarations.
XML [8] notes that "XML documents should begin with an XML
declaration which specifies the version of XML being used." In
general, an XML declaration should be encouraged ("SHOULD be
present") and must always be allowed ("MAY be sent"). An XML
declaration should be required in cases where, if allowed, the
character encoding is anything other than UTF-8 or UTF-16.
プロトコル仕様はXML宣言の使用に関して明確であるに違いありません。 「XMLドキュメントは使用されるXMLのバージョンを指定するXML宣言で始まるはずです。」と、XML[8]は述べます。 一般に、XML宣言が奨励されるべきである、(「SHOULD、存在してください、」、)、いつも許容しなければなりません(「送るかもしれません」)。 XML宣言が許容されているなら、文字符号化がUTF-8以外の何かUTF-16であるでも場合で必要であるべきです。
4.5 XML Processing Instructions
4.5 XML処理命令
An XML processing instruction (defined in section 2.6 of [8]) is a component of an XML document that signals extra "out of band" information to the receiver; a common use of XML processing instructions are for document applications. For example, the XML2RFC application used to generate this document and described in RFC 2629 [19] supports a "table of contents" processing instruction:
XML処理命令、([8])のセクション2.6で定義されているのは、「バンド」付加的な情報を受信機に示すXMLドキュメントの部品です。 XML処理命令の一般の使用はドキュメントアプリケーションのためのものです。 例えば、このドキュメントを作るのに使用されて、RFC2629[19]で説明されたXML2RFCアプリケーションは、「目次」が処理命令であるとサポートします:
<?rfc toc="yes"?>
<?rfc toc=「はい」?>。
As described in section 2.6 of [8], processing instructions are not part of the document's character data, but must be passed through to the application. As a consequence, it is recommended that processing instructions be ignored when encountered in normal protocol processing. It is thus also recommended that processing instructions
[8]のセクション2.6で説明されるように、処理命令をドキュメントのキャラクタデータの一部ではありませんが、アプリケーションに通り抜けなければなりません。 結果として、通常のプロトコル処理で遭遇すると処理命令が無視されるのは、お勧めです。 また、そんなに処理している指示はこのようにしてそれに推薦されます。
Hollenbeck, et al. Best Current Practice [Page 9] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[9ページ]RFC3470XML
not be used to define normative protocol data structures or extensions for the following reasons:
以下の理由で標準のプロトコルデータ構造か拡大を定義するには、使用されないでください:
o Processing instructions are not namespace aware; there is no way
to qualify a processing instruction target with a namespace.
o 処理命令は名前空間意識していません。 名前空間で処理命令目標に資格を与える方法が全くありません。
o Processing instruction use can not be constrained by most schema
languages,
o ほとんどのスキーマ言語は処理命令使用を抑制できません。
o Character references are not recognized within a processing
instruction.
o 文字参照は処理命令の中で認識されません。
o Processing instructions don't have any XML-defined structure
beyond the division between the target and everything else. This
means that applications typically have to parse the content of the
processing instruction in a system-dependent way; if the content
was provided within an element instead, the structure could be
expressed in the XML and the parsing could be done by the XML
parser.
o 処理命令には、目標と他の何もかもの間の分割を超えて少しのXMLによって定義された構造もありません。 これは、アプリケーションがシステム依存する方法で処理命令の内容を通常分析しなければならないことを意味します。 代わりに要素の中で内容を提供するなら、XMLで構造を急送できるでしょうに、そして、XMLパーサは構文解析ができました。
4.6 XML Comments
4.6 XMLコメント
An XML comment (defined in section 2.5 of [8]) is a component of an XML document that provides descriptive information that is not part of the document's character data. XML comments, like comments used in programming languages, are often used to provide explanatory information in human-understandable terms. An example:
XMLはコメントします。([8])のセクション2.5で定義されているのは、ドキュメントのキャラクタデータの一部でない記述的な情報を提供するXMLドキュメントの部品です。 コメントがプログラミングに言語を使用したようにXMLコメントは人間理解できる用語例の説明している情報を提供するのにおいてしばしば使用されています:
<!-- This is a example comment. -->
<!--これは例のコメントです。 -->。
XML comments can be ignored by conformant processors. As a consequence, it is strongly recommended that comments not be used to define normative protocol data structures or extensions. It is thus also strongly recommended that comments be ignored if encountered in normal protocol processing.
conformantプロセッサはXMLコメントを無視できます。 結果として、コメントが標準のプロトコルデータ構造か拡大を定義するのに使用されないことが強く勧められます。 また、通常のプロトコル処理で遭遇するならコメントが無視されることがこのようにして強く勧められます。
4.7 Validity and Extensibility
4.7 正当性と伸展性
One important value of XML is that there are formal mechanisms for defining structural and data content constraints; these constrain the identity of elements or attributes or the values contained within them. There is more than one such formalism:
XMLの1つの重要な値は構造的でデータ満足している規制を定義するための正式なメカニズムがあるということです。 これらはそれらの中に含まれた要素のアイデンティティ、属性または値を抑制します。 そのような形式の1つ以上があります:
o A "Document Type Definition" (DTD) is defined in section 2.8 of
[8]; the concept came from a similar mechanism for SGML. There is
significant experience with using DTDs, including in IETF
protocols.
o 「ドキュメント型定義」(DTD)は[8]のセクション2.8で定義されます。 概念はSGMLに同様のメカニズムから来ました。 IETFにプロトコルを含んでいて、DTDを使用する重要な経験があります。
Hollenbeck, et al. Best Current Practice [Page 10] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[10ページ]RFC3470XML
o XML Schema (defined in [41] and [42]) provides additional features
to allow a tighter and more precise specification of allowable
protocol syntax and data type specifications.
o XML Schema、(定義されたコネ[41]と[42])は、許容できるプロトコル構文とデータ型仕様の、よりきつくて、より正確な仕様を許容するために付加的な機能を提供します。
o There are also a number of other mechanisms for describing XML
instance validity; these include, for example, Schematron [49] and
RELAX NG [48]. Part 2 of the ISO/IEC Document Schema Definition
Language (DSDL, [32]) standard is based on RELAX NG.
o また、XMLインスタンスの正当性について説明するための他の多くのメカニズムがあります。 これらは例えばSchematron[49]とRELAX NG[48]を含んでいます。 ISO/IEC Document Schema Definition Languageの第2部、(DSDL、[32])規格はRELAX NGに基づいています。
There is ongoing discussion (and controversy) within the XML community on the use and applicability of various validity constraint mechanisms. The choice of tool depends on the needs for extensibility or for a formal language and mechanism for constraining permissible values and validating adherence to the constraints.
様々な正当性規制メカニズムの使用と適用性のXML共同体の中に現在行われている議論(そして、論争)があります。ツールのこの選択は、許容値を抑制して、固守を規制に有効にするための伸展性か形式言語とメカニズムの必要性次第です。
There are cases where protocols have defined validity using one or another validity mechanism, but the protocol definitions have not insisted that all corresponding protocol elements be "valid". The decision depends in part on the design for protocol extensibility. Each formalism has different ways of allowing for future extensions; in addition, a protocol design may have its own versioning mechanism, way of updating the schema, or pointing to a new one. For example, the use of XML namespaces (Section 4.9) with XML Schema allows other kinds of extensibility without compromising schema validity.
ケースがプロトコルが1か別の正当性メカニズムを使用することで正当性を定義しましたが、プロトコル定義がすべての対応するプロトコル要素が「有効である」と主張していないところにあります。 決定はプロトコル伸展性のためにデザインに一部よります。 各形式には、今後の拡大を考慮する異なった方法があります。 さらに、プロトコルデザインには、それ自身のずっと図式をアップデートするか、または新しいものを示すversioningメカニズムがあるかもしれません。 例えば、図式の正当性に感染しないで、XML SchemaとのXML名前空間(セクション4.9)の使用は他の種類の伸展性を許容します。
No matter what formalism is chosen, there are usually additional syntactic constraints, and inevitably additional semantic constraints, on the validity of XML elements that cannot be expressed in the formalism.
どんな形式が選ばれても、通常追加している構文の規制、および必然的に追加している意味規制があります、形式で表すことができないXML要素の正当性で。
This document makes the following recommendations for the definition of protocols using XML:
このドキュメントはXMLを使用することでプロトコルの定義のための以下の推薦状をします:
o Protocols should use an appropriate formalism for defining
validity of XML protocol elements.
o プロトコルは、XMLプロトコル要素の正当性を定義するのに適切な形式を使用するべきです。
o Protocols may or may not insist that all corresponding protocol
elements be valid, according to the validity mechanism chosen; in
either case, the extensibility design should be clear. What
happens if the data is not valid?
o プロトコルは、選ばれた正当性メカニズムによると、すべての対応するプロトコル要素が有効であると主張するかもしれません。 どちらかの場合では、伸展性デザインは明確であるはずです。 データが有効でないなら、何が起こりますか?
o As described in Section 3 there is no standard mechanism in XML
for indicating whether or not new extensions are mandatory to
recognize. XML-based protocol specifications should thus
explicitly describe extension mechanisms and requirements to
recognize or ignore extensions.
o セクション3で説明されるように、どんな標準のメカニズムも新しい拡大が認識するために義務的であるかどうかを示すためのXMLにありません。 その結果、XMLベースのプロトコル仕様は明らかに、拡張機能と拡大を認識するか、または無視するという要件について説明するべきです。
Hollenbeck, et al. Best Current Practice [Page 11] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[11ページ]RFC3470XML
An idealized model for XML processing might first check for well- formedness; if OK, apply the primary formalism and, if the instances "passes", apply the other constraints so that the entire set (or as much as is machine processable) can be checked at the same time.
XML処理のための理想化されたモデルは最初に、井戸形成がないかどうかチェックするかもしれません。 OKであるなら、プライマリ形式を適用してください、そして、インスタンスが「通る」なら、同時に全体のセット(または、マシン「プロセス-可能」であるのと同じくらい多く)をチェックできるように他の規制を適用してください。
However, it is reasonable to allow conforming implementations to avoid doing validation at run-time and rely instead on ad-hoc code to avoid the higher expense, for example, of schema validation, especially given that there will likely be additional hand-crafted semantic validation.
しかしながら、例えば、図式合法化について、より高い費用を避けるためにランタイムのときに合法化するのを避けて、代わりに臨時のコードを当てにするために実装を従わせるのを許容するのは妥当です、追加手作りの意味合法化がおそらくあれば。
4.8 Semantics as Well as Syntax
4.8 構文と同様に意味論
While the definition of an XML protocol element using a validity formalism is useful, it is not sufficient. XML by itself does not supply semantics. Any document defining a protocol element with XML MUST also have sufficient prose in the document describing the semantics of whatever XML the document has elected to define.
正当性形式を使用するXMLプロトコル要素の定義は役に立ちますが、それは十分ではありません。 それ自体でXMLは意味論を供給しません。 また、XML MUSTと共にプロトコル要素を定義するどんなドキュメントもドキュメントが定義するのを選んだどんなXMLの意味論についても説明するドキュメントの十分な散文を持っています。
4.9 Namespaces
4.9 名前空間
XML namespaces, defined in [9], provide a means of assigning markup to a specific vocabulary. If two elements or attributes from different vocabularies have the same name, they can be distinguished unambiguously if they belong to different namespaces. Additionally, namespaces provide significant support for protocol extensibility as they can be defined, reused, and processed dynamically.
[9]で定義されたXML名前空間は特定のボキャブラリーにマーク付けを割り当てる手段を提供します。 同じ名前が異なったボキャブラリーからの2つの要素か属性にあるなら、明白に異なった名前空間に属すなら、それらを区別できます。 さらに、名前空間はそれらを定義して、再利用されて、ダイナミックに処理できるようにプロトコル伸展性の重要なサポートを提供します。
Markup vocabulary collisions are very possible when namespaces are not used to separate and uniquely identify vocabularies. Protocol definitions should use existing XML namespaces where appropriate. When a new namespace is needed, the "namespace name" is a URI that is used to identify the namespace; it's also useful for that URI to point to a description of the namespace. Typically (and recommended practice in W3C) is to assign namespace names using persistent http URIs.
マーク付けボキャブラリー衝突は、名前空間がいつであるかがどんな以前はよく別々の状態でそうしていなかったのが非常に可能であり、唯一ボキャブラリーを特定します。 プロトコル定義は適切であるところで既存のXML名前空間を使用するべきです。 新しい名前空間が必要であるときに、「名前空間名」は名前空間を特定するのに使用されるURIです。 また、そのURIが名前空間の記述を示すのも、役に立ちます。 永続的なhttp URIを使用することで名前空間名を通常割り当てることになっています(そして、W3Cの推奨案)。
In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN namespace (see [11] and [12]). Although there are instances of IETF specifications creating new URI schemes to define XML namespaces, this practice is strongly discouraged.
IETF標準化過程文書における、名前空間の場合では、このために使用できたIETFの自己のウェブスペースの何らかの永久的な地域があれば、役に立つでしょうに。 そのようなものの代わりに他の永久的なURIを使用できます、例えば、IETF URN名前空間におけるURNs。([11]と[12])を見てください。 XML名前空間を定義するために新しいURI体系を作成するIETF仕様のインスタンスがありますが、この習慣は強くがっかりしています。
Hollenbeck, et al. Best Current Practice [Page 12] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[12ページ]RFC3470XML
4.9.1 Namespaces and Attributes
4.9.1 名前空間と属性
There is a frequently misunderstood aspect of the relationship between unprefixed attributes and the default XML namespace - the natural assumption is that an unprefixed attribute is qualified by the default namespace, but this is not true. Rather, the unprefixed attribute belongs to no namespace at all. Thus, in the following example:
「非-前に置」かれた属性とデフォルトXML名前空間との関係の頻繁に誤解された局面があります--自然な仮定は「非-前に置」かれた属性がデフォルト名前空間によって資格がありますが、これが本当でないということです。 むしろ、「非-前に置」かれた属性は名前空間に全く属しません。 このようにして、以下の例で:
<ns1:fox a="xxx" ns1:b="qqq"
xmlns="http://example.org"/>
<fox a="xxx" ns1:b="qqq"
xmlns="http://example.org" xmlns:ns1="http://example.org"/>
<ns1: ="xxx"ns1を欺いてください: "qqq"b=xmlnsは" http://example.org "/><キツネ="xxx"ns1と等しいです: "qqq"b=xmlnsは" http://example.org "xmlnsと等しいです: ns1は" http://example.org "/>と等しいです。
the attribute "a" is in no namespace, while "ns1:b" is the same namespace as the containing element. A specific description of the relationship between default namespaces and attributes can be found in section 5.2 of [9]. The practical implication of the relationship between namespaces and attributes is that care must be taken to ensure that no element contains multiple attributes that have identical names or have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.
どんな名前空間にも属性“a"がありませんが、「ns1: b」は含んでいる要素と同じ名前空間です。 [9]のセクション5.2でデフォルト名前空間と属性との関係の明確な記述を見つけることができます。 名前空間と属性との関係の実用的な含意は注意がどんな要素も同じ名前を持っている複数の属性を含まないのを保証するために取ったに違いないか、または同じである名前空間名に縛られた同じ地方の部分と接頭語の名前に資格を与えたに違いないということです。
In XML applications, the choice between prefixed and non-prefixed attributes frequently is based on whether they always appear inside elements of the same namespace (in which case non-prefixed and thereby non-namespaced names are used) or whether it's required that they can be applied to elements in other arbitrary namespaces (in which case a prefixed name is used). Both situations occur in the XSLT [43] language: while attributes are unprefixed when they occur inside elements in the XSLT namespace, such as:
XMLアプリケーションでは、前に置かれて非前に置かれた属性の選択は同じ名前空間の要素の中でいつも見えるかどうか(その場合、非前に置かれてその結果、非namespacedされた名前は使用されています)、またはそれが、他の任意の名前空間でそれらを要素に適用できるのを必要としたかどうか(その場合、前に置かれた名前は使用されています)頻繁に基づいています。 両方の状況はXSLT[43]言語で起こります: それらであるときに、属性が「非-前に置」かれている間、XSLT名前空間における、以下などの要素の中に起こってください。
<xsl:value-of select="."/>
「<xsl:、値、-、=」 . 」 />を選択してください。
Hollenbeck, et al. Best Current Practice [Page 13] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[13ページ]RFC3470XML
they are prefixed when they appear in non-XSLT elements, such as the "xsl:version" attribute when using "literal result element stylesheets":
彼らが非XSLTで要素で、あれほど見えるとそれらが前に置かれている、「文字通りの結果要素スタイルシート」を使用するとき、「xsl: バージョン」は結果と考えます:
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total: <xsl:value-of select="exp-rep/total"/></p>
</body>
</html>
<html xsl: バージョン=、「1インチのxmlns: xslが" http://www.w3.org/1999/XSL/Transform "xmlns=と等しい、「 http://www.w3.org/TR/xhtml1/strict 、「><ヘッド><タイトル>Expense Report Summary</タイトル></ヘッド><ボディー><p>Total:」 <xsl:、値、-、=「exp-レップ/合計」/></p></ボディー></htmlな>を選択してください。
4.10 Element and Attribute Design Considerations
4.10 要素と属性デザイン問題
XML provides much flexibility in allowing a designer to use either elements, attributes, or element content to carry data. This section gives a flavor of the design considerations; there is much written about this in the XML literature. Consistent use of elements, attributes, and values is an important characteristic of a sound design.
データを運ぶためにデザイナーが要素、属性か要素含有量のどちらかを使用するのを許容するのにXMLは多くの柔軟性を提供します。 このセクションはデザイン問題の風味を与えます。 これに関してXML文学に書かれていて、多くがあります。 要素、属性、および値の一貫した使用は音のデザインの重要な特性です。
Attributes are generally intended to contain meta-data that describes the element, and as such they are subject to the following restrictions:
一般に、属性が要素について説明するメタデータを含むことを意図して、そういうものとして、それらは以下の制限を受けることがあります:
o Attributes are unordered,
o 属性は順不同のです。
o There can be no more than one instance of a given attribute within
a given element, though an attribute may contain several values
separated by white space ([8], section 2.3 and 3.3.1),
o 与えられた要素の中に与えられた属性の1つ未満のインスタンスがあることができます、属性は余白([8]によって切り離されたいくつかの値、セクション2.3と3.3.1を)含むかもしれませんが
o Attribute values can have no internal XML markup for providing
internal structure, and
o そして属性値が内部の構造を提供するためのどんな内部のXMLマークアップも持つことができない。
o Attribute values are normalized ([8], section 3.3) before
processing
o 属性値が正常にされる、([8]、セクション3.3)、処理
Consider the following example that describes an IP address using an attribute to describe the address value:
属性を使用することでIPアドレスについて説明する以下の例がアドレス値について説明すると考えてください:
<address addrType="ipv4">10.1.2.3</address>
<アドレスaddrTypeは「ipv4">10.1.2.3</アドレス>」と等しいです。
Hollenbeck, et al. Best Current Practice [Page 14] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[14ページ]RFC3470XML
One might encode the same information using an <addrType> element instead of an "addrType" attribute:
1つは"addrType"属性の代わりに<addrType>要素を使用することで同じ情報をコード化するかもしれません:
<address>
<addrType>ipv4</addrType>
<value>10.1.2.3</value>
</address>
<アドレス><addrType>ipv4</addrType><価値>10.1.2の.3</値の></アドレス>。
Another way of encoding the same information would be to use markup for the "addrType":
同じ情報をコード化する別の方法は"addrType"にマーク付けを使用するだろうことです:
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
<アドレス><addrType><ipv4/></addrType><価値>10.1.2の.3</値の></アドレス>。
Choosing between these designs involves tradeoffs concerning, among other considerations, the likely extensibility patterns and the ability of the formalism to constrain the values appropriately. In the first example, the attribute can be thought of as meta-data to the element which it modifies, and provides for a kind of "element extensibility". The third example allows for a different kind of extensibility: the "ipv4" space can be extended using other namespaces, and the <ipv4> element can include additional markup.
これらのデザインを選ぶと、見返りは他の問題の中でありそうな伸展性パターンと適切に値を抑制する形式の能力に関してかかわります。 最初の例では、属性は、メタデータとしてそれが変更する要素に考えることができて、一種の「要素伸展性」に備えます。 3番目の例は異種の伸展性を考慮します: 「他の名前空間を使用することでipv4"スペースを広げることができます、そして、<ipv4>要素は追加マーク付けを含むことができます。」
Many protocols include parameters that are selected from an enumerated set of values. Such enumerated values can be encoded as elements, attributes, or strings within element values. Any protocol design should consider how the set of enumerated values is to be extended: by revising the protocol, by including different values in different XML namespaces, or by establishing an IANA registry (as per RFC 2434 [18]). In addition, a common practice in XML is to use a URI as an XML attribute value or content.
多くのプロトコルが列挙されたセットの値から選択されるパラメタを含んでいます。 要素、属性、またはストリングとして要素値の中でそのような列挙された値をコード化できます。 どんなプロトコルデザインも列挙された値のセットが広げられることになっていることの方法を考えるべきです: プロトコルを改訂するか、異なったXML名前空間に異価を含んでいるか、またはIANA登録を確立する、(RFC2434[18])に従って。 さらに、XMLの一般的な習慣はXML属性値か内容としてURIを使用することになっています。
Languages that describe syntactic validity (including XML Schema and DTDs) often provide a mechanism for specifying "default" values for an attribute. If an element does not specify a value for the attribute, then the "default" value is used. The use of default values for attributes is discouraged by this document. Although the use of this feature can reduce both the size and clutter of XML documents, it has a negative impact on software which doesn't know the document's validity constraints (e.g., for packet tracing or digital signature).
構文の正当性(XML SchemaとDTDを含んでいる)について説明する言語がしばしば「デフォルト」値を属性に指定するのにメカニズムを提供します。 要素が属性に値を指定しないなら、「デフォルト」値は使用されています。 デフォルト値の属性の使用はこのドキュメントでお勧めできないです。 この特徴の使用はサイズとXMLドキュメントの散乱の両方を減少させることができますが、それはドキュメントの正当性規制(例えば、パケットのたどるかデジタル署名のための)を知らないソフトウェアの上でマイナスの影響があります。
Hollenbeck, et al. Best Current Practice [Page 15] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[15ページ]RFC3470XML
4.11 Binary Data and Text with Control Characters
制御文字がある4.11のバイナリ・データとテキスト
XML is defined as a character stream rather than a stream of octets. There is no way to embed raw binary data directly within an XML data stream; all binary data must be encoded as characters. There are a number of possible encodings; for example, XML Schema [42] defines encodings using decimal digits for integers, Base64 [15], or hexadecimal digits. In addition, binary data might be transmitted using some other communication channel, and referenced within the XML data itself using a URI.
XMLは八重奏のストリームよりむしろキャラクタストリームと定義されます。 XMLデータ・ストリームの直接中で生のバイナリ・データを埋め込む方法が全くありません。 キャラクタとしてすべてのバイナリ・データをコード化しなければなりません。 多くの可能なencodingsがあります。 例えば、XML Schema[42]は、整数、Base64[15]、または16進数字に10進数字を使用することでencodingsを定義します。 さらに、バイナリ・データは、ある他の通信チャネルを使用することで伝えられて、URIを使用するXMLデータ自体の中で参照をつけられるかもしれません。
Protocols that need a container that can hold both structural data and large quantities of binary data should consider carefully whether XML is appropriate, since the Base64 and hex encodings are inefficient. Otherwise, protocols should use the mechanisms of XML Schema to represent binary data; the Base64 encoding is best for larger quantities of data.
XMLが適切であるか否かに関係なく、構造的なデータと大量のバイナリ・データの両方を保持できるコンテナを必要とするプロトコルは熟考するべきです、Base64と十六進法encodingsが効率が悪いので。 さもなければ、プロトコルはバイナリ・データを表すのにXML Schemaのメカニズムを使用するべきです。 多く以上の量のデータに、Base64コード化は最も良いです。
XML does not allow "control" characters (0x00-0x1F) except for TAB (0x09), CR (0x0A), and LF (0x0D). They can not be specified even using character entity references. There is currently no common way of encoding them within what is otherwise ordinary text. This means that strings that might be considered "text" within an ABNF-defined protocol element may need to be treated as binary data within an XML representation, or some other encoding mechanism might need to be invented.
XMLはTAB(0×09)、CR(0x0A)、およびLF(0x0D)以外の「コントロール」キャラクタ(0×00 0x1F)を許容しません。 キャラクタ実体参照を使用さえすることでそれらを指定できません。 現在、そうでないことの中のコード化しているそれら普通のテキストのどんな一般的な道もありません。 これは、ABNFによって定義されたプロトコル要素の中の考えられた「テキスト」であるかもしれないストリングが、XML表現の中でバイナリ・データとして扱われる必要があるかもしれないか、またはある他のコード化メカニズムが、発明される必要であるかもしれないことを意味します。
4.12 Incremental Processing
4.12 増加の処理
In some situations, it is possible to incrementally process an XML document as each tag is received; this is analogous to the process by which browsers incrementally render HTML pages as they are received. Note that incremental processing is difficult to implement if interspersed across multiple interactions. In other words, if a protocol requires incremental processing across both directions of a bidirectional stream, then it may place an unusual burden on protocol implementers.
いくつかの状況で、それぞれのタグが受け取られているとき、XML文書を増加して処理するのは可能です。 これはそれらが受け取られているときブラウザがHTML形式のページを増加して表すプロセスに類似しています。 複数の相互作用の向こう側に点在するなら増加の処理は実装するのが難しいことに注意してください。 言い換えれば、プロトコルが双方向のストリームの両方の方向の向こう側に増加の処理を必要とするなら、それはプロトコルimplementersに珍しい負担をかけるかもしれません。
4.13 Entity Declarations and Entity References
4.13 実体宣言と実体参照
In addition to its role as a validity mechanism, an XML DTD provides a facility for "entity declarations" ([8], section 4.2). An entity declaration defines, in the DTD, a kind of macro capability where an "entity reference" may be used to call up and include the content of the entity declaration.
正当性メカニズムとしての役割に加えて、XML DTDは「実体宣言」([8]に施設を提供します、セクション4.2、) 「実体参照」が実体宣言の内容を呼び出して、含むのに使用されるかもしれないところで実体宣言はDTDで一種のマクロ能力を定義します。
Hollenbeck, et al. Best Current Practice [Page 16] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[16ページ]RFC3470XML
This feature adds complexity to XML processing, and seems more appropriate for use of XML in document processing than in data representation. As such, this document recommends avoiding entity declarations in protocol specifications.
この特徴は、XML処理に複雑さを加えて、データ表現より文書処理におけるXMLの使用には適切に見えます。 そういうものとして、このドキュメントは、プロトコル仕様で実体宣言を避けることを勧めます。
On the other hand, there are five standard entity references built into XML: "&", "<", ">", "'", and """. XML also has the ability to write character data using numeric entity references (using the Unicode [33] value for the character). Entity references are normally expanded before the XML Information Set is computed. Restricting the use of these entity references would introduce an additional syntactic restriction (see Section 4.3) unnecessarily; these entity references should be allowed.
他方では、標準のXMLが組み込まれた5つの実体参照があります: 「"&"、"<"">"」、およびapos;、」 """。 また、XMLには、数値実体参照を使用することで(キャラクタにユニコード[33]値を使用して)キャラクタにデータを書く能力があります。 XML情報Setが計算される前に通常、実体参照は広げられます。 これらの実体参照の使用を制限すると、追加構文の制限(セクション4.3を見る)は不必要に紹介されるでしょう。 これらの実体参照は許容されるべきです。
4.14 External References
4.14の外部参照
When using XML in the context of a stateless protocol, be it the protocol itself (e.g., SOAP), or simply as content transferred by an existing protocol (e.g., XML/HTTP), care must be taken to not make the meaning of a message depend on information outside the message itself. XML provides external entities (see Section 4.13), which are an easy way to make the meaning of a message depend on something external. Using schema languages that can change the Infoset, like XML Schema, is another way.
それがプロトコル(例えば、SOAP)自体であったなら状態がないプロトコルの文脈でXMLを使用するとき、単に既存のプロトコル(例えば、XML/HTTP)によって内容が移されたように、メッセージの意味をメッセージ自体の外で情報によらせないように注意しなければなりません。 XMLは外部実体(セクション4.13を見る)を提供します。(外部実体はメッセージの意味を何か外部であることのものによらせる簡単な方法です)。 XML SchemaのようにInfosetを変えることができるスキーマ言語を使用するのは、別の方法です。
4.15 URI Processing
4.15 URI処理
The XML Base specification [36] defines an attribute "xml:base" in the XML namespace that is intended to affect the "base" to be used for relative URI processing described in RFC 2396 [17]. The facilities of xml:base for controlling URI processing may be useful to protocol designers, but if xml:base is allowed the interaction with any other protocol facilities for establishing URI context must be specified clearly. Note that use of relative URIs in namespace declarations has been deprecated by the W3C; some specific issues with relative URIs in namespace declarations and canonical XML can be found in section 1.3 of RFC 3076 [6].
XML基地の仕様[36]は属性がXMLで「: ベースをxmlする」というRFC2396[17]で説明された相対的なURI処理に使用されるために「ベース」に影響することを意図する名前空間を定義します。 xmlの施設: URI処理を制御するためのベースはデザイナーについて議定書の中で述べるために役に立つかもしれませんが、xml: ベースが許容されているなら、明確にURI文脈を確立するためのいかなる他のプロトコル施設との相互作用も指定しなければなりません。 名前空間宣言における相対的なURIの使用がW3Cで推奨しないことに注意してください。 RFC3076[6]のセクション1.3で名前空間宣言と正準なXMLの相対的なURIのいくつかの特定の問題を見つけることができます。
Note also that, in many cases, the term "URI" and the syntactic use of URIs within XML allows non-ASCII characters within URIs. For example, the XML Schema "anyURI" datatype ([42] section 3.2.17) allows for direct encoding of characters outside of the US-ASCII range. Most current IETF protocols and specifications do not allow this syntax. Protocol specifications should be clear about the range of characters specified, e.g., by adding a restriction to the range of characters allowed in the anyURI schema datatype, or by specifying that characters outside the US-ASCII range should be escaped when passed to older protocols or APIs.
また、「URI」という用語とXMLの中のURIの構文の使用がURIの中に多くの場合で非ASCII文字を許容することに注意してください。 例えば、米国-ASCIIの外部をキャラクタにコード化する.17が)ダイレクトに考慮するXML Schema"anyURI"データ型式([42]部3.2は及びます。 ほとんどの現在のIETFプロトコルと仕様はこの構文を許容しません。 例えば、anyURI図式データ型式で許容されたキャラクタの範囲に制限を加えることによって指定されたキャラクタの範囲か、より古いプロトコルかAPIに通過されると米国-ASCII範囲の外のキャラクタ逃げられるべきであると指定することによって、プロトコル仕様は明確であるはずです。
Hollenbeck, et al. Best Current Practice [Page 17] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[17ページ]RFC3470XML
4.16 White Space
4.16 余白
XML's prescribed white space handling behavior can be a source of confusion between protocol designers and implementers. In XML instances all white space is considered significant and is by default visible to processing applications. Consider this example from Section 4.10:
XMLの処方された余白取り扱いの振舞いはプロトコルデザイナーとimplementersの間の混乱の源であるかもしれません。 すべての余白は、XMLインスタンスでは、重要であると考えられて、デフォルトで考えられます。処理アプリケーションに目に見えます。 セクション4.10からのこの例を考えてください:
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
<アドレス><addrType><ipv4/></addrType><価値>10.1.2の.3</値の></アドレス>。
This fragment contains an <address> element and two child elements. It also contains white space for pretty-printing purposes:
この断片は<アドレス>要素と2つの子供要素を含んでいます。 また、それはきれいな印刷目的のための余白を含んでいます:
o at least three line separators, which will be converted by the XML
processor to newline (U+000A) characters (see section 2.11 of
[8]), and
o そして少なくとも3がXMLプロセッサによってニューライン(U+000A)キャラクタに変換される分離符を裏打ちする、([8])のセクション2.11を見てください。
o one or more white space characters prefixing the <addrType> and
<value> elements, which an XML processor will make visible to
software reading the instance.
o <addrType>と<を前に置く1つ以上の余白キャラクタが>要素を評価します。(XMLプロセッサは要素をインスタンスを読むソフトウェアに目に見えるようにするでしょう)。
Implementers might safely assume that they can ignore the white space in the example above, but white space used for pretty-printing can be a source of confusion in other situations. Consider a minor change to the <value> element:
Implementersは、彼らが上記の例の余白を無視できると安全に仮定するかもしれませんが、きれいな印刷に使用される余白は他の状況における混乱の源であるかもしれません。 <値の>要素とマイナーチェンジを考えてください:
<value>
10.1.2.3
</value>
<価値>10.1.2の.3</値の>。
where white space is found on both sides of the IP address. XML processors treat the white space surrounding "10.1.2.3" as an integral part of the <value> element. A failure to recognize this behavior can lead to confusion and errors in both design and implementation.
白いところでは、スペースがIPアドレスの両側で見つけられます。 XMLプロセッサが余白周辺を扱う、「10.1、.2、<値の>要素の不可欠の部分としての0.3インチ、」 この振舞いを認識しない場合、デザインと実装の両方で混乱と誤りにつながることができます。
All white space is considered significant in XML instances. As a consequence, it is recommended that protocol designers provide specific guidelines to address white space handling within protocols that use XML.
すべての余白がXMLインスタンスで重要であると考えられます。 結果として、プロトコルデザイナーがXMLを使用するプロトコルの中で余白が取り扱いであると扱うために特別な基準を提供するのは、お勧めです。
Hollenbeck, et al. Best Current Practice [Page 18] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[18ページ]RFC3470XML
4.17 Interaction with the IANA
4.17 IANAとの相互作用
When XML is used in an IETF protocol there are multiple factors that might require IANA action, including:
XMLがIETFプロトコルに使用されるとき、である:IANA動作を必要とするかもしれない重複因子があります。
o XML media types. A piece of XML in a protocol element is
sometimes intrinsically bound to the protocol context in which it
appears, and in particular might be directly derived from and/or
input to protocol state-machine implementations. In cases where
the XML content has no relevant meaning outside it's original
protocol context, there is no reason to register a MIME type.
When it is possible that XML content can be interpreted outside of
its original context (such as when that XML content is being
stored in a file system or tunneled over another protocol), then a
MIME type can be registered to specify the specific format for the
data and to provide a hint as to how it might be processed.
o XMLメディアタイプ。 プロトコル要素のXMLの1つの断片はそれが現れて、直接特に現れるプロトコル文脈へのバウンドは時々本質的に、実装を引き出される、そして/または、プロトコル州マシンに入力するということです。 場合では、XML内容の外にどんな関連意味もどこにないかが、オリジナルのプロトコル文脈である、MIMEの種類を登録する理由が全くありません。 オリジナルの文脈(そのXML内容がファイルシステムに保存されるか、または別のプロトコルの上でトンネルを堀られている時などの)の外でXML内容を解釈できるのが可能であると、データのための特定の形式を指定して、それがどう処理されるかもしれないかに関してヒントを提供するためにMIMEの種類を登録できます。
If MIME labeling is needed, then the advice of RFC 3023 [5]
applies. In particular, if the XML represents a new language or
document type, a new MIME media type should be registered for the
reasons described in RFC 3023 sections 7 and A.1. In situations
where XML is used to encode generic structured data (e.g., a
document-oriented application that involves combining XML with a
stylesheet), "application/xml" might be appropriate ("MAY be
used"). The "text/xml" media type is not recommended ("SHOULD NOT
be used") because of issues involving display behavior and default
charsets.
MIMEラベリングが必要であるなら、RFC3023[5]のアドバイスは適用されます。 XMLが新しい言語かドキュメントタイプの代理をするなら、特に、新しいMIMEメディアタイプはRFC3023部7とA.1で説明された理由で示されるべきです。 XMLがジェネリックの構造化されたデータ(例えば、XMLをスタイルシートに結合することを伴うドキュメント指向のアプリケーション)をコード化するのに使用される状況で、「アプリケーション/xml」は適切であるかもしれません(「使用されるかもしれません」)。 「テキスト/xml」メディアタイプが推薦されない、(「SHOULD NOT、使用されてください、」、)、ディスプレイの振舞いとデフォルトcharsetsにかかわる問題のために。
o URI registration. There is an ongoing effort ([11], [12]) to
create a URN namespace explicitly for defining URIs for namespace
names and other URI-designated protocol elements for use within
IETF standards track documents; it might also establish IETF
policy for such use.
o URI登録。 進行中の取り組み([11]があります、使用のために名前空間名のためのURIと他のURIで指定されたプロトコル要素を定義するためにIETF標準化過程ドキュメントの中に明らかにURN名前空間を作成する[12])。 また、それはそのような使用のためのIETF方針を確立するかもしれません。
5. Internationalization Considerations
5. 国際化問題
This section describes internationalization considerations for the use of XML to represent data in IETF protocols. In addition to the recommendations here, IETF policy on the use of character sets and languages described in RFC 2277 [3] also applies.
XMLの使用がIETFプロトコルのデータを表すように、このセクションは国際化問題について説明します。 また、ここでの推薦に加えて、RFC2277[3]で説明された文字集合と言語の使用に関するIETF方針は適用されます。
5.1 Character Sets and Encodings
5.1 文字コードとEncodings
IETF protocols frequently speak of the "character set" or "charset" of a string, which is used to denote both the character repertoire and the encoding used to represent sequences of characters as sequences of bytes.
IETFプロトコルは頻繁に「文字集合」かストリングの"charset"について話します。(ストリングは、バイトの系列としてキャラクタの系列を表すのに使用されるキャラクタレパートリーとコード化の両方を指示するのに使用されます)。
Hollenbeck, et al. Best Current Practice [Page 19] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[19ページ]RFC3470XML
XML performs all character processing in terms of the Universal Character Set (UCS, [31] and [33]). XML requires all XML processors to support both the UTF-8 [4] and UTF-16 [20] encodings of UCS, although other encodings (charsets) compatible with UCS may be allowed. Documents and external parsed entities encoded in UTF-16 are required to begin with a Byte Order Mark ([8] section 4.3.3).
XMLはUniversal文字コードに関してすべての文字処理を実行します。(UCS、[31]、および[33])。 XMLは両方がUCSのUTF-8[4]とUTF-16[20]encodingsであるとサポートするためにすべてのXMLプロセッサを必要とします、UCSとのコンパチブル他のencodings(charsets)は許容されるかもしれませんが。 UTF-16でコード化されたドキュメントと外部の解析対象実体は初めに必要であることで、Byte Orderマーク([8]が4.3に.3を)区分するということです。
IETF policy [3] requires that the UTF-8 charset be allowed for all text.
IETF方針[3]は、UTF-8 charsetがすべてのテキストのために許容されているのを必要とします。
This document requires that IETF protocols using XML allow for the UTF-8 encoding of XML data. Since conforming XML processors are mandated to also accept UTF-16 encoding, also allowing for UTF-16 encoding (with the mandated Byte Order Mark) is recommended. Some XML applications are using a Byte Order Mark with UTF-8 encoding, but this use should not be encouraged and isn't appropriate for XML embedded in other protocols.
このドキュメントは、XMLを使用するIETFプロトコルがXMLデータのUTF-8コード化を考慮するのを必要とします。 以来従っているXMLプロセッサは、また、コード化(強制されたByte Orderマークがいる)が推薦されるUTF-16をコード化して、また、考慮しながらUTF-16を受け入れるために強制されます。 いくつかのXMLアプリケーションがUTF-8コード化と共にByte Orderマークを使用していますが、この使用は、奨励するべきでなくて、他のプロトコルに埋め込まれたXMLには、適切ではありません。
Restricting XML data to only be expressed in UTF-8 is an additional syntactic restriction (see Section 4.3) which, depending on circumstances, might add additional implementation complexity. When encodings other than UTF-8 or UTF-16 are used, the encoding must be specified using an "encoding" attribute in the XML declaration (see Section 4.4), even if there might be other protocol mechanisms for designating the encoding.
UTF-8で言い表されるだけであるためにXMLデータを制限するのは、事情によって、追加実装の複雑さを加えるかもしれない追加構文の制限(セクション4.3を見る)です。 UTF-8かUTF-16以外のencodingsが使用されているとき、XML宣言に「コード化」属性を使用することでコード化を指定しなければなりません(セクション4.4を見てください)、コード化を指定するための他のプロトコルメカニズムがあるかもしれなくても。
5.2 Language Declaration
5.2 言語宣言
Text encapsulated in XML can be represented in many different human languages, and it is often useful to explicitly identify the language used to present the text. XML defines a special attribute in the "xml" namespace, xml:lang, that can be used to specify the language used to represent data in an XML document. The xml:lang attribute (which has to be explicitly declared for use within a DTD or XML Schema) and the values it can assume are defined in section 2.12 of [8].
多くの異なった人間の言語でXMLでカプセル化されたテキストは表すことができます、そして、明らかにテキストを提示するのに使用される言語を特定するのはしばしば役に立ちます。 XMLはxml: "xml"名前空間、XMLドキュメントのデータを表すのに使用される言語を指定するのに使用できるlangで特別な属性を定義します。 xml: lang属性(DTDかXML Schemaの中の使用のために明らかに宣言されなければならない)とそれが仮定できる値は[8]のセクション2.12で定義されます。
It is strongly recommended that protocols representing data in a human language mandate use of an xml:lang attribute if the XML instance might be interpreted in language-dependent contexts.
XMLインスタンスが表すかもしれないならxml: lang属性の人間の言語命令使用でのデータを表すプロトコルが言語依存する文脈で解釈されることが強く勧められます。
5.3 Other Internationalization Considerations
5.3 他の国際化問題
There are standard mechanisms in the typography of some human languages that can be difficult to represent using merely XML character string data types. For example, pronunciation clues can be provided using Ruby annotation [39], and embedding controls (such as those described in section 3.4 of [34]) or an XHTML [40] "dir"
いくつかの表すのが単にXMLキャラクタ列データを使用するのにおいて難しい場合がある人間の言語の活版印刷には標準のメカニズムがあります。 例えば、Ruby注釈[39]を使用して、コントロールを埋め込みながら発音手がかりを提供できる、([34])のセクション3.4で説明されたものかXHTML[40]"dir"
Hollenbeck, et al. Best Current Practice [Page 20] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[20ページ]RFC3470XML
attribute can be used to note the proper display direction for bidirectional text.
双方向のテキストによって適切なディスプレイ方向に注意するのに属性を使用できます。
There are a number of tricky issues that can arise when using extended character sets with XML document formats. For example:
XMLドキュメント・フォーマットがある拡張文字集合を使用するとき起こることができる多くの油断のならない問題があります。 例えば:
o There are different ways of representing characters consisting of
combining characters, and
o そしてキャラクタを結合するのから成るキャラクタの代理をする異なった方法がある。
o There has been some debate about whether URIs should be
represented using a restricted US-ASCII subset or arbitrary
Unicode (e.g., "URI character sequence" vs "original character
sequence" in RFC 2396 [17]).
o URIが制限された米国-ASCII部分集合か任意のユニコードを使用することで表されるべきであるかどうかの何らかの討論がありました。(例えば、RFC2396[17])の「オリジナルのキャラクタシーケンス」に対する「URIキャラクタシーケンス。」
Some of these issues are discussed, with recommendations, in the W3C's "Character Model for the World Wide Web" document [44].
W3C's「WWWのためのキャラクターモデル」ドキュメント[44]でこれらの問題のいくつかについて推薦と議論します。
It is strongly recommended that protocols representing data in a human language reuse existing mechanisms as needed to ensure proper display of human-legible text.
人間の言語のデータを表すプロトコルが人間読みやすいテキストの適切なディスプレイを確実にするために必要に応じて既存のメカニズムを再利用することが強く勧められます。
6. IANA Considerations
6. IANA問題
This memo, per se, has no impact on the IANA. Section 4.17 notes some factors that might require IANA action when protocols using XML are defined.
このメモはIANAにそういうものとして影響力を全く持っていません。 セクション4.17はXMLを使用するプロトコルが定義されるときIANA動作を必要とするかもしれないいくつかの要素に注意します。
7. Security Considerations
7. セキュリティ問題
Network protocols face many different kinds of threats, including unintended disclosure, modification, and replay. Passive attacks, such as packet sniffing, allow an attacker to capture and view information intended for someone else. Captured data can be modified and replayed to the original intended recipient, with the recipient having no way to know that the information has been compromised, detect modifications, be assured of the sender's identity, or to confirm which protocol instance is legitimate.
ネットワーク・プロトコルは、故意でない公開、変更を含む脅威の多くの異種に直面して、再演されます。 パケットスニフィングなどの受け身の攻撃は他の誰かのために意図するキャプチャする攻撃者と視点情報を許容します。 オリジナルの意図している受取人に捕らわれているデータを変更して、再演できます、変更を検出するか、送付者のアイデンティティについて安心する、情報が感染された、どれがインスタンスについて議定書の中で述べるかを確認するのが正統であることを知る方法を全く持っていない受取人と共に。
Several security service options for XML are available to help mitigate these risks. Though XML does not include any built-in security services, other protocols and protocol layers provide services that can be used to protect XML protocols. XML encryption [10] provides privacy services to prevent unintended disclosure. Canonical XML [6] and XML digital signatures [7] provide integrity services to detect modification and authentication services to confirm the identity of the data source. Other IETF security protocols (e.g., the Transport Layer Security (TLS) protocol [2]) are also available to protect data and service endpoints as appropriate.
XMLのためのいくつかのセキュリティー・サービスオプションが、これらの危険を緩和するのを助けるために利用可能です。 XMLは少しの内蔵のセキュリティーサービスも含んでいませんが、他のプロトコルとプロトコル層はXMLプロトコルを保護するのに利用できるサービスを提供します。 XML暗号化[10]は、故意でない公開を防ぐためにプライバシーサービスを提供します。 正準なXML[6]とXMLデジタル署名[7]は、データ送信端末のアイデンティティを確認するために変更と認証サービスを検出するために保全サービスを提供します。 他のIETFセキュリティプロトコル、(また、例えば、Transport Layer Security(TLS)プロトコル[2])も、適宜データとサービス終点を保護するために利用可能です。
Hollenbeck, et al. Best Current Practice [Page 21] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[21ページ]RFC3470XML
Given the lack of security services in XML, it is imperative that protocol specifications mandate additional security services to counter common threats and attacks; the specific required services will depend on the protocol's threat model.
XMLのセキュリティー・サービスの不足を考えて、プロトコル仕様が一般的な脅威と攻撃に対抗するために追加担保サービスを強制するのは、必須です。 特定の必要なサービスはプロトコルの脅威モデルに頼るでしょう。
Experience has shown that code that parses network traffic is often a "soft target" for blackhats. Accordingly, implementers MUST take great care to ensure that their XML handling code is robust with respect to malformed XML, buffer overruns, misuse of entity declarations, and so on.
経験は、ネットワークトラフィックを分析するコードがしばしばblackhatsのための「ソフトターゲット」であると示しました。 それに従って、implementersは、それらのXML取り扱いコードが確実に奇形のXML、バッファ超過、実体宣言の誤用などに関して強健になるようにするために高度の注意を取らなければなりません。
XML mechanisms that follow external references (Section 4.14) may also expose an implementation to various threats by causing the implementation to access external resources automatically. It is important to disallow arbitrary access to such external references within XML data from untrusted sources. Many XML grammars define constructs using URIs for external references; in such cases, the same precautions must be taken.
また、実装が自動的に外部のリソースにアクセスすることを引き起こすことによって、外部参照(セクション4.14)に従うXMLメカニズムは様々な脅威に実装を暴露するかもしれません。 信頼できないソースからのXMLデータの中のそのような外部参照への任意のアクセスを禁じるのは重要です。 多くのXML文法が外部参照にURIを使用することで構造物を定義します。 そのような場合、同じ注意を払わなければなりません。
8. Acknowledgements
8. 承認
The authors would like to thank the following people who have provided significant contributions to the development of this document:
作者はこのドキュメントの開発への重要な貢献を提供した以下の人々に感謝したがっています:
Mark Baker, Tim Berners-Lee, Tim Bray, James Clark, Josh Cohen, John Cowan, Alan Crouch, Martin Duerst, Jun Fujisawa, Christian Geuer- Pollmann, Yaron Goland, Graham Klyne, Dan Kohn, Rick Jeliffe, Chris Lilley, Murata Makoto, Michael Mealling, Jean-Jacques Moreau, Andrew Newton, Julian Reschke, Jonathan Rosenberg, Miles Sabin, Rich Salz, Peter Saint-Andre, Simon St Laurent, Margaret Wasserman, and Daniel Veillard.
マイルのベイカー、ティム・バーナーズ・リー、ティムBray、ジェームス・クラーク、ジョッシュ・コーエン、ジョン・カウァン、アランCrouch、マーチンDuerst、Jun藤沢、クリスチャンのGeuerポルマン、ヤロンGoland、グラハムKlyne、ダン・コーン、リックJeliffe、クリス・リリー、誠ムラタ、マイケルMealling、ジャン・ジャック・モロー、アンドリュー・ニュートン、ジュリアンReschke、ジョナサン・ローゼンバーグ、セービン、金持ちのザルツ、ピーターサンアンドレ、サイモン・Stローラン、マーガレット・ワッサーマン、およびダニエルVeillardをマークしてください。
9. Normative References
9. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[4]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
Hollenbeck, et al. Best Current Practice [Page 22] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[22ページ]RFC3470XML
[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[5] ムラタとM.と聖ローランとS.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[6] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[6] ボワイエ、J.、「正準なXML、バージョン1インチ、RFC3076、2001インチ年3月。
[7] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, March
2002.
[7] イーストレーク、D.、Reagle、J.、D.独奏、および「(拡張マークアップ言語)XML-署名構文と処理」(RFC3275)は2002を行進させます。
[8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, <http://www.w3.org/TR/REC-xml>.
[8]ロバの鳴き声、T.、パオリ、J.、Sperberg-マックィーン、C.、およびE.Maler、「拡張マークアップ言語(XML)1.0(2番目の教育)」、W3C REC-xml、2000年10月、<http://www.w3.org/TR/REC-xml>。
[9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C
REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-
names>.
「XMLの名前空間」という[9]ロバの鳴き声、T.、オランダ人、D.、およびA.Laymanは1999年1月に<http://www.w3.org/TR/REC-xml名を>にW3C REC-xml挙げます。
[10] Imamura, T., Dillaway, B., Schaad, J. and E. Simon, "XML
Encryption Syntax and Processing", W3C REC-xmlenc-core, October
2001, <http://www.w3.org/TR/xmlenc-core/>.
[10] 「XML暗号化構文と処理」という今村、T.、Dillaway、B.、Schaad、J.、およびE.サイモンは2001年10月にW3C REC-xmlenc<xmlenc http://www.w3.org/TR/コア/>の芯を取ります。
10. Informative References
10. 有益な参照
[11] Masinter, L., Mealling, M., Klyne, G. and T. Hardie, "An IETF
URN Sub-namespace for Registered Protocol Parameters", Work in
Progress.
[11] 「登録されたプロトコルパラメタのためのサブ名前空間のIETFつぼ」というMasinter、L.、食事、M.、Klyne、G.、およびT.ハーディーは進行中で働いています。
[12] Mealling, M., "The IETF XML Registry", Work in Progress.
[12] 食事、M.、「IETF XML登録」が進行中で働いています。
[13] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990.
[13] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびC.デーヴィン(「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157)は1990がそうするかもしれません。
[14] Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
[14]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[15]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[16] Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[16] クロッカー、D.編とP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[17] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[17]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
Hollenbeck, et al. Best Current Practice [Page 23] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[23ページ]RFC3470XML
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[18]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[19] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
[19] M. ローズ、RFC2629、「XMLを使用することでI-DsとRFCsに書く」6月1999日
[20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[20] ホフマン、P.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781、2000年2月。
[21] Klensin, J. (Ed.), "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[21]Klensin、J.編、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[22] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
3010, December 2000.
[22]SheplerとS.とキャラハンとB.とロビンソンとD.とサーロウとR.とBeameとC.とアイスラーとM.とD.Noveck、「NFSバージョン4プロトコル」、RFC3010、2000年12月。
[23] Kennedy, H., "Binary Lexical Octet Ad-hoc Transport", RFC 3252,
April 2002.
[23] ケネディ、H.、「2進の語彙八重奏臨時の輸送」、RFC3252、2002年4月。
[24] Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution
Protocol (CNRP)", RFC 3367, August 2002.
[24] ポップとN.と食事とM.とM.モーズリー、「俗称解決プロトコル(CNRP)」、RFC3367、2002年8月。
[25] Backus, J., "The syntax and semantics of the proposed
international algebraic language of the Zurich ACM-GAMM
conference", June 1959.
[25] 1959年6月のバッカスと、J.と、「チューリッヒACM-GAMM会議の提案された国際代数言語の構文と意味論」
[26] American National Standards Institute, "Code Extension
Techniques for Use with the 7-bit Coded Character Set of
American National Standard Code (ASCII) for Information
Interchange", ANSI X3.41, FIPS PUB 35, 1974.
[26] American National Standards Institut、「7ビットのコード化文字集合の米国標準規格コード(ASCII)との情報交換の使用のための拡大のテクニックをコード化してください」、ANSI X3.41、FIPSパブ35、1974。
[27] American National Standards Institute, "Information Retrieval:
Application Service Definition and Protocol Specification",
ANSI Z39.50, ISO Standard 23950, 1995.
[27] American National Standards Institut、「情報検索:」 「アプリケーションは定義とプロトコル仕様を修理する」ANSI Z39.50、ISO規格23950、1995。
[28] International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)", ISO
Standard 8824, December 1990.
[28] 国際標準化機構、「情報処理システム--オープン・システム・インターコネクション--抽象構文記法1の仕様(ASN.1)」、ISO規格8824(1990年12月)。
[29] International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1)", ISO Standard 8825, December 1990.
[29] 国際標準化機構、「情報処理システム--オープン・システム・インターコネクション--基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます」、ISO規格8825、1990年12月。
Hollenbeck, et al. Best Current Practice [Page 24] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[24ページ]RFC3470XML
[30] International Organization for Standardization, "Information
processing - Text and office systems - Standard Generalized
Markup Language (SGML)", ISO Standard 8879, 1988.
[30]国際標準化機構、「情報処理--テキストとオフィス・システム--標準のGeneralized Markup Language(SGML)。」(ISO Standard8879、1988)
[31] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane", ISO
Standard 10646-1, May 1993.
[31] 国際標準化機構、「情報Technology--普遍的なMultiple-八重奏コード化された文字コード(UCS)--第1部:、」 「アーキテクチャと基本多言語水準」(ISO規格10646-1)は1993がそうするかもしれません。
[32] International Organization for Standardization, "DSDL Part 0 -
Overview", December 2001, <http://www.jtc1.org/FTP/Public/SC34/
DOCREG/0275.htm>.
[32]国際標準化機構、「DSDLは0--概要を分け」2001年12月<http://www.jtc1.org/FTP/公共の/SC34/DOCREG/0275.htm>。
[33] Unicode Consortium, "The Unicode Standard, as it may from time
to time be revised or amended", March 2002, <http://
www.unicode.org/unicode/standard/standard.html>.
[33] ユニコードConsortium、「ユニコードStandard、それのように時々改訂されるか修正されているかもしれません」、2002年3月、<http://www.unicode.org/ユニコード/規格/standard.html>。
[34] Duerst, M. and A. Freytag, "Unicode in XML and other Markup
Languages", February 2002, <http://www.w3.org/TR/unicode-xml/>.
[34]DuerstとM.とA.フライターク、「XMLと他のMarkup Languagesのユニコード」、2002年2月、<ユニコードhttp://www.w3.org/TR/xml/>。
[35] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup
Language (XML) 1.0", W3C REC-xml-1998, February 1998, <http://
www.w3.org/TR/1998/REC-xml-19980210/>.
[35]ロバの鳴き声、T.、パオリ、J.、およびC.Sperberg-マックィーン、「拡張マークアップ言語(XML)1インチ、W3C REC-xml-1998 1998年2月、<http://www.w3.org/TR/1998/REC-xml-19980210/>。」
[36] Marsh, J., "XML Base", W3C REC-xmlbase, June 2001, <http://
www.w3.org/TR/xmlbase/>.
[36] 沼地、J.、「XML基地」、W3C REC-xmlbase、2001年6月、<http://www.w3.org/TR/xmlbase/>。
[37] Cowan, J. and R. Tobin, "XML Information Set", W3C REC-infoset,
October 2001, <http://www.w3.org/TR/xml-infoset/>.
[37] カウァンとJ.とR.トビン、「XML一組の情報」、W3C REC-infoset、2001年10月、<http://www.w3.org/TR/xml-infoset/>。
[38] Lassila, O. and R. Swick, "Resource Description Framework (RDF)
Model and Syntax Specification", W3C REC-rdf-syntax, February
1999, <http://www.w3.org/TR/REC-rdf-syntax>.
[38]Lassila、O.、R.Swick、および「リソース記述フレームワーク(リモート・データ・ファシリティ)モデルと構文仕様」、W3C REC-rdf-構文、1999年2月、<REC-rdf http://www.w3.org/TR/構文>。
[39] Suignard, M., Ishikawa, M., Duerst, M. and T. Texin, "Ruby
Annotation", W3C REC-RUBY, May 2001, <http://www.w3.org/TR/
ruby/>.
[39]SuignardとM.と石川とM.とDuerstとM.とT.Texin、「ルビー色の注釈」、W3C REC-RUBY、2001年5月、<http://www.w3.org/TR/ ruby/>。
[40] Pemberton, S., "XHTML 1.0: The Extensible HyperText Markup
Language", W3C REC-XHTML, January 2000, <http://www.w3.org/TR/
xhtml1/>.
[40] ペンバートン、S.、「XHTML1.0:」 「Extensibleハイパーテキスト・マークアップ言語」、W3C REC-XHTML、2000年1月、<http://www.w3.org/TR/ xhtml1/>。
[41] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
<http://www.w3.org/TR/xmlschema-1/>.
[41] トンプソン、H.、ぶな、D.、マローニー、M.、およびN.メンデルゾーン、「XML図式第1部:」 「構造」(W3C REC-xmlschema-1)は2001、<http://www.w3.org/TR/xmlschema-1/>がそうするかもしれません。
[42] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
[42] ビロン、P.、およびA.Malhotra、「XML図式第2部:」 「データ型式」(W3C REC-xmlschema-2)は2001、<http://www.w3.org/TR/xmlschema-2/>がそうするかもしれません。
Hollenbeck, et al. Best Current Practice [Page 25] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[25ページ]RFC3470XML
[43] Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC-
xslt, November 1999, <http://www.w3.org/TR/xslt>.
[43] クラーク、J.、「XSL変換バージョン1インチ、W3C REC- xslt、1999年11月、<http://www.w3.org/TR/xslt>(XSLT)。」
[44] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A. and
T. Texin, "Character Model for the World Wide Web 1.0", April
2002, <http://www.w3.org/TR/charmod/>.
[44]Duerst、M.、Yergeau、F.、石田、R.、オオカミ、M.、フライターク、A.、およびT.Texin、「WWW1インチ、2002年4月、<http://www.w3.org/TR/charmod/>のキャラクターモデル。」
[45] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", June 2002,
<http://www.w3.org/TR/soap12-part1/>.
[45] JJ M.、ハドリー、M.、モロー、H.ニールセン、Gudginに、「バージョン1.2第1部を石けんでこすってください」 「メッセージングフレームワーク」、2002年6月、<http://www.w3.org/TR/soap12-part1/>。
[46] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
Version 1.2 Part 2: Adjuncts", June 2002,
<http://www.w3.org/TR/soap12-part2/>.
[46] JJ M.、ハドリー、M.、モロー、H.ニールセン、Gudginに、「バージョン1.2第2部を石けんでこすってください」 「付属物」、2002年6月、<http://www.w3.org/TR/soap12-part2/>。
[47] W3C Communications Team, "XML in 10 points", November 2001,
<http://www.w3.org/XML/1999/XML-in-10-points>.
[47] W3CコミュニケーションTeam、「10ポイントのXML」2001年11月、中の<http://www.w3.org/XML/1999/XML10ポイントの>。
[48] OASIS Technical Committee: RELAX NG, "RELAX NG Specification",
December 2001, <http://www.oasis-open.org/committees/relax-ng/
spec-20011203.html>.
[48] オアシス専門委員会: RELAX NG、「RELAX NG仕様」2001年12月にngを<http://www.oasis-open.org/委員会/寛げる/仕様-20011203.html>。
[49] Jelliffe, R., "The Schematron", November 2001, <http://
www.ascc.net/xml/schematron/>.
[49]Jelliffe、R.、「Schematron」、2001年11月の<http://www.ascc.net/xml/schematron/>。
URIs
URI
[50] <http://www.imc.org/ietf-xml-use/>
[50] <http://www.imc.org/ietf-xml-使用/>。
[51] <http://xml.org/>
[51] <http://xml.org/>。
[52] <http://xmlhack.com/>
[52] <http://xmlhack.com/>。
[53] <http://oasis-open.org/>
[53] <http://オアシス-open.org/>。
Hollenbeck, et al. Best Current Practice [Page 26] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[26ページ]RFC3470XML
11. Authors' Addresses
11. 作者のアドレス
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
スコットHollenbeckベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
Phone: +1 703 948 3257 EMail: shollenbeck@verisign.com
以下に電話をしてください。 +1 3257年の703 948メール: shollenbeck@verisign.com
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
Inc.POB255268サクラメント、カリフォルニア95865-5268米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 8878年の916 483メール: mrose@dbc.mtview.ca.us
Larry Masinter Adobe Systems Incorporated Mail Stop W14 345 Park Ave. San Jose, CA 95110 US
ラリーMasinterアドビ・システムズはメール停止W14 345公園Aveを組み込みました。 サンノゼ、カリフォルニア95110米国
Phone: +1 408 536 3024 EMail: LMM@acm.org URI: http://larry.masinter.net
以下に電話をしてください。 +1 3024年の408 536メール: LMM@acm.org ユリ: http://larry.masinter.net
Hollenbeck, et al. Best Current Practice [Page 27] RFC 3470 XML within IETF Protocols January 2003
Hollenbeck、他 IETFプロトコル2003年1月の中の最も良い現在の習慣[27ページ]RFC3470XML
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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機能のための基金は現在、インターネット協会によって提供されます。
Hollenbeck, et al. Best Current Practice [Page 28]
Hollenbeck、他 最も良い現在の習慣[28ページ]
一覧
スポンサーリンク
