W3C 勧告

XML 1.0 名前空間(第3版) XML 1.1 名前空間(第2版)

2009 年 12 月 8 日付 2006 年 8 月 16 日付 W3C 勧告

Tim Bray, Textuality <tbray@textuality.com>
Dave Hollander, Contivo, Inc. <dmh@contivo.com>
Andrew Layman, Microsoft <andrewl@microsoft.com>
Richard Tobin, University of Edinburgh and Markup Technology Ltd <richard@inf.ed.ac.uk> <richard@cogsci.ed.ac.uk>
Henry S. Thompson, University of Edinburgh and W3C <ht@w3.org> - Third Edition

この文書の公式の修正を含み得る 正誤表 正誤表 も参照願います。 Please refer to the errata for this document, which may include normative corrections.

翻訳版 翻訳版 もご覧ください。 See also translations .

この文書には次の非公式版の形式も用意されています: XML 版 および 第2版からの差分が強調されている HTML 版 This document is also available in these non-normative formats: XML and HTML highlighting differences from the second edition.

Copyright © 2009 2006  W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.


XML名前空間は、 XML 文書内で利用する要素と属性の名前に対し URIIRI 参照により識別される名前空間に結び付けることにより,修飾するための単純な手法を提供する。 XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by _URI references.


この節では公開された時点におけるこの文書の位置付けについて述べます。他の文書がこの文書に取って代わる可能性があります。 W3C の現在の出版リストとこの文書の最新の状態は W3C technical reports index にて見られます。 This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

この文書は W3C XML Activity の一部として XML Core Working Group によって作成されました。 この仕様の英語版のみが公式のバージョンです。 他言語版については http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names-11 をご覧ください。 This document is a product of the XML Core Working Group as part of the W3C XML Activity. The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names-11 .

既知の実装は Namespaces 1.1 implementation report に記載されています。 (名前空間 1.1 の既知の実装のすべてが名前空間 1.0 もサポートしています。) テストスイートも XML Test Suite のページから入手できます。 Known implementations are documented in the Namespaces 1.1 implementation report (all known Namespaces 1.1 implementations also support Namespaces 1.0) . A test suite is also available via the XML Test Suite page.

この第3版では、公開日時点にて既知の,すべての正誤表が統合されています。 これは 2006 年 8 月 16 日の版 を置き換えるものになります。 This third edition incorporates all known errata as of the publication date. It supersedes the previous edition of 16 August 2006.

この第2版では、公開日時点にて既知の,すべての正誤表が統合されています。 これはその前の 2004 年 2 月 4 日付け W3C 勧告 を置き換えるものになります。 読者の便宜のため, 改訂部分を色付けした XHTML バージョン も用意されています。 This second edition incorporates all known errata as of the publication date. It supersedes the previous W3C Recommendation of 4 February 2004. For the convenience of readers, an XHTML version with color-coded revision indicators is also provided.

この版は広範囲から吟味されてきています。 2009 年 8 月 6 日の勧告改定案からの変更点は小さな編集上のもののみに限られています。 This edition has been widely reviewed. Only minor editorial changes have been made since the 6 August 2009 Proposed Edited Recommendation.

この文書に誤りを見つけられた方は xml-names-editor@w3.org までご報告願います。 公開 アーカイブ もあります。 この文書の正誤表一覧は http://www.w3.org/XML/2009/xml-names-errata http://www.w3.org/XML/2006/xml-names11-errata にあります。 Please report errors in this document to xml-names-editor@w3.org; public archives are available. The errata list for this document is available at http://www.w3.org/XML/2009/xml-names-errata.

この文書は W3C メンバ,ソフトウェア開発者達, W3C グループや関心を持つ団体から吟味され、ディレクターにより W3C 勧告として承認されたものです。 これは安定した文書であり、規範として利用したり、他の文書に引用することができます。 勧告の発行における W3C の役割は、仕様に対する注目を集め、広範囲への普及を促進する所にあります。これはウェブの相互運用性と機能性を向上させるものです。 This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

この文書は W3C Patent Policy Transition Procedure からの訂正により 24 January 2002 CPP の管理下にあります。 W3C はグループの成果物に関連して public list of any patent disclosures を作成し維持管理しています。そのページには特許開示の手引きも含まれます。特許に関する実際的知識を持ち、そこに Essential Claim(s) が含まれていると主張する者は W3C Patent Policy 第 6 節 に従って情報を公開しなければなりません。 This document is governed by the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

1 動機と要約

XML ( Extensible Markup Language )の応用として、単独の XML 文書が、複数種類の “マークアップ語彙” — そのそれぞれが、複数のソフトウェアモジュールのために定義され, それらから利用されるような,要素や属性からなる — を含み得る状況が想定される。 これを想定する動機の一つは、そのモジュール性にある。 そのようなマークアップ語彙が存在し, 十分に理解されていて, 有用なソフトウェアのために利用できるのであれば、新たなマークアップを再発明するよりも,そのマークアップを再利用する方がよい。 We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a "markup vocabulary") that are defined for and used by multiple software modules. One motivation for this is modularity: if such a markup vocabulary exists which is well-understood and for which there is useful software available, it is better to re-use this markup rather than re-invent it.

そのような複数種類のマークアップ語彙が含まれている文書においては、語彙の認識と衝突が問題になる。 ソフトウェアモジュールは,その処理対象として設計された要素や属性を、同じ名前の要素や属性が何らかの他のソフトウェアパッケージのためのマークアップに用いられていることにより,名前の "衝突" に直面したとしても、正確に認識できる必要がある。 Such documents, containing multiple markup vocabularies, pose problems of recognition and collision. Software modules need to be able to recognize the elements and attributes which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element name or attribute name.

これらを考慮するとき、文書の構成子に付与される名前は,異なるマークアップ語彙からの名前との衝突が避けられるように構築されるべきであることが求められる。 この仕様では、要素と属性に 展開名 をあてがうことにより,これを達成する、 XML 名前空間 と呼ばれる仕組みを述べる。 These considerations require that document constructs should have names constructed so as to avoid clashes between names from different markup vocabularies. This specification describes a mechanism, XML namespaces, which accomplishes this by assigning expanded names to elements and attributes.

1.1 表記と語法についての注意点

この文書における次の各キーワード: 〜しなければならない( MUST ), 〜してはならない( MUST NOT ), 要求される( REQUIRED ), 〜すべきである( SHOULD ), 〜すべきでない( SHOULD NOT ), 〜してもよい( MAY )強調 されている所は、 [Keywords] に従って解釈されるものになる。 Where EMPHASIZED, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, MAY in this document are to be interpreted as described in [Keywords].

この仕様に示される生成規則における非終端記号の多くは、ここではなく XML 仕様 [XML] にて定義されることに注意。 ここに定義される非終端記号が XML 仕様の非終端記号と同じ名前を持つ場合、すべての場合において,前者に合致する文字列の集合は後者に合致する文字列の集合の部分集合になる。 Note that many of the nonterminals in the productions in this specification are defined not here but in the XML specification [XML]. When nonterminals defined here have the same names as nonterminals defined in the XML specification, the productions here in all cases match a subset of the strings matched by the corresponding ones there.

この文書の生成規則における NSC とは、 “名前空間制約” ( Namespace Constraint )であり,この仕様に適合する文書が従わなければならない規則になる。 In this document's productions, the NSC is a "Namespace Constraint", one of the rules that documents conforming to this specification MUST follow.

2 XML 名前空間

2.1 基本概念

[定義: XML 名前空間URI 参照 [RFC3986] IRI 参照 [RFC3987] により識別される。 要素名/属性名は、この仕様に述べる仕組みを用いることにより,何らかの XML 名前空間に属し得る。 ] [Definition: An XML namespace is identified by a URI reference [RFC3986] an IRI reference [RFC3987] ; element and attribute names may be placed in an XML namespace using the mechanisms described in this specification. ]

[定義: 展開名 とは、 名前空間名局所名 の組である。 ] [定義: 名前 NURIIRI I により特定される名前空間に属するならば、その 名前空間名I である。 名前 N がどの名前空間にも属さないならば、その 名前空間名 は,値を持たない。 ] [定義: いずれの場合においても、 局所名 は, N である。 ] 大域的に管理される URIIRI としての名前空間と,語彙の局所名との組み合わせにより、名前の衝突が避けられるようになる。 [Definition: An expanded name is a pair consisting of a namespace name and a local name. ] [Definition: For a name N in a namespace identified by a _URI I, the namespace name is I. For a name N that is not in a namespace, the namespace name has no value. ] [Definition: In either case the local name is N. ] It is this combination of the universally managed _URI namespace with the vocabulary's local names that is effective in avoiding name clashes.

URIIRI 参照は名前に許可されない文字を含み得る上,長くて不便なので、展開名が直接的に XML 文書の要素と属性の命名に利用されることはない。 代わりに 修飾名 が用いられる。 [定義: 修飾名 とは、名前空間の解釈の対象になる名前である。 ] この仕様に適合する文書においては、要素名/属性名は修飾名として出現する。 構文としては、それらは 接頭辞付きの名前 または 接頭辞なしの名前 のいずれかであり、 接頭辞を名前空間名に束縛するための, および 接頭辞なしの要素名を既定の名前空間に束縛するための,属性に基づく宣言構文が用意されている。 これらの宣言のスコープ(有効範囲)は、文書の他の部分には異なる束縛を適用し得るようにするため,それが現れる要素下(要素自身とその内容)に限られる。 この仕様に適合するプロセッサは、これらの宣言や接頭辞を認識して 動作しなければならない
【 “スコープ( scope )” — この語の用法には、この段落のように宣言する側から見た場合のその効力が及ぶ範囲(有効範囲)を表すときと, 影響を受ける対象(要素/属性)から見た場合の範囲(可視範囲)を表すときの2通りある。 後者の用法では、その対象に影響し得る宣言の存在範囲,すなわち要素自身またはその先祖において宣言されているかどうかが問題にされる。 】 _URI references can contain characters not allowed in names, and are often inconveniently long, so expanded names are not used directly to name elements and attributes in XML documents. Instead qualified names are used. [Definition: A qualified name is a name subject to namespace interpretation. ] In documents conforming to this specification, element and attribute names appear as qualified names. Syntactically, they are either prefixed names or unprefixed names. An attribute-based declaration syntax is provided to bind prefixes to namespace names and to bind a default namespace that applies to unprefixed element names; these declarations are scoped by the elements on which they appear so that different bindings may apply in different parts of a document. Processors conforming to this specification MUST recognize and act on these declarations and prefixes.

2.2 名前空間名としての URIIRI の利用

空文字列は、 URIIRI 参照としては合法であっても,名前空間名として用いることはできない。 The empty string, though it is a legal URI reference, cannot be used as a namespace name.

名前空間宣言における相対 URIIRI 参照の利用は、同じ文書への参照も含め,廃止予定にある。 The use of relative _URI references, including same-document references, in namespace declarations is deprecated.

注記: この相対 URI 参照の廃止は W3C XML Plenary Ballot [Relative URI deprecation] による決定である。 そこでは、 “DOM, XPath などの後続の仕様においても、それらに対する解釈を定義しないことになる” ことも表明された。 Note: This deprecation of relative URI references was decided on by a W3C XML Plenary Ballot [Relative URI deprecation]. It also declares that "later specifications such as DOM, XPath, etc. will define no interpretation for them".

2.3 URIIRI 参照の比較

名前空間を特定する URIIRI 参照は、ある名前が与えられた名前空間に属するかどうか, および 2つの名前が同じ名前空間に属するかどうかを決定する際に比較される。 [定義: 2つの URIIRI は文字列として扱うものとし、文字列として同一であるとき,すなわち同じ文字の並びであるとき, そのときに限り 同一 とする。 ] 比較においては、文字の大小は区別され, % エスケープの実施や復元も行われない。 _URI references identifying namespaces are compared when determining whether a name belongs to a given namespace, and whether two names belong to the same namespace. [Definition: The two _URIs are treated as strings, and they are identical if and only if the strings are identical, that is, if they are the same sequence of characters. ] The comparison is case-sensitive, and no %-escaping is done or undone.

したがって,この意味において同一でない2つの URIIRI 参照は、同じリソースに解決され得る。 例えば、文字の大小や % エスケープ,あるいは 異なる基底 URI を持つ外部実体参照(相対 URIIRI 参照は名前空間名として廃止予定にあるが) においてのみ異なる, URIIRI 参照など。 A consequence of this is that URI references which are not identical in this sense may resolve to the same resource. Examples include URI references which differ only in case or %-escaping, or which are in external entities which have different base URIs (but note that relative URIs are deprecated as namespace names).

名前空間宣言における URIIRI 参照は,属性の 正規化済みの値 であり、 XML 文字や実体参照の置換は どの比較よりも先に行われる。 In a namespace declaration, the _URI reference is the normalized value of the attribute, so replacement of XML character and entity references has already been done before any comparison.

次の URIIRI 参照は文字の大小が異なるので、名前空間の識別においては,すべて互いに異なる: The _URI references below are all different for the purposes of identifying namespaces, since they differ in case:

  • http://www.example.org/wine
  • http://www.Example.org/wine
  • http://www.example.org/Wine

次の URIIRI 参照も、名前空間の識別においては,すべて互いに異なる: The _URI references below are also all different for the purposes of identifying namespaces:

  • http://www.example.org/rosé
  • http://www.example.org/ros%c3%a9
  • http://www.example.org/ros%c3%A9
  • http://www.example.org/ros%C3%a9
  • http://www.example.org/ros%C3%A9

次も同様である: As are these:

  • http://www.example.org/~wilbur
  • http://www.example.org/%7ewilbur
  • http://www.example.org/%7Ewilbur

実体 eacuteé として定義されているならば,次の開始タグはすべて、接頭辞 p を同じ URIIRI 参照 http://example.org/rosé に束縛する名前空間宣言を含む。 If the entity eacute has been defined to be é, the start tags below all contain namespace declarations binding the prefix p to the same IRI reference, http://example.org/rosé.

  • <p:foo xmlns:p="http://example.org/rosé">
  • <p:foo xmlns:p="http://example.org/ros&#xe9;">
  • <p:foo xmlns:p="http://example.org/ros&#xE9;">
  • <p:foo xmlns:p="http://example.org/ros&#233;">
  • <p:foo xmlns:p="http://example.org/ros&eacute;">

参照の解決後に同値になり得る URIIRI による混乱を避けるため、名前空間名においては, % エスケープを利用しないことが強く奨励される。 Because of the risk of confusion between _URIs that would be equivalent if dereferenced, the use of %-escaped characters in namespace names is strongly discouraged.

3 名前空間の宣言

[定義: 名前空間は(より厳密には名前空間束縛は)、予約済み属性の族を用いて 宣言 される。 その種の属性名は xmlns であるか, または xmlns: から始まるものでなければならない。 これらの属性は、他の XML 属性と同様に,直接的にあるいは 既定 により与え得る。] [Definition: A namespace (or more precisely, a namespace binding) is declared using a family of reserved attributes. Such an attribute's name must either be xmlns or begin xmlns:. These attributes, like any other XML attributes, may be provided directly or by default. ]

[1] NSAttName ::= PrefixedAttName
| DefaultAttName
[2] PrefixedAttName ::= 'xmlns:' NCName [NSC: 予約済みの接頭辞と名前空間名]
[3] DefaultAttName ::= 'xmlns'
[4] NCName ::= Name - (Char* ':' Char*)
NCNameStartChar NCNameChar*
/* XML Name Name から ":" を除外 */
[5] NCNameChar ::= NameChar - ':' 【1.0 過去版の [5][6] は F 節に移動】
[6] NCNameStartChar ::= NameStartChar - ':'

属性の 正規化済みの値 は、名前空間を特定する 名前空間名 としての URIIRI 参照であるか, または 空文字列でなければならない 名前空間名は、その利用目的に鑑みて,一意的かつ永続的になるべきである。 スキーマが存在するとしても,その取得に直接的に利用し得ることは目標ではない。 その種の目標を念頭に設計されたものとしては、統一リソース名 [RFC2141] の例がある。 しかしながら,通常の URL は同じ目標のために管理し得るものになることは注記しておく。 The attribute's normalized value MUST be either a _URI reference — the namespace name identifying the namespace — or an empty string. The namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). Uniform Resource Names [RFC2141] is an example of a syntax that is designed with these goals in mind. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals.

[定義: 属性名が PrefixedAttName に合致するならば、その NCName名前空間接頭辞 を与え,その属性値の 名前空間名 がその宣言が付与された要素のスコープにおいて,名前空間名と要素名/属性名との結び付けに利用される。 ] [Definition: If the attribute name matches PrefixedAttName, then the NCName gives the namespace prefix, used to associate element and attribute names with the namespace name in the attribute value in the scope of the element to which the declaration is attached. ]

[定義: 属性名が DefaultAttName に合致するならば、その属性値の 名前空間名 がその宣言が付与された要素のスコープにおいて, 既定の名前空間 になる。 ] 既定の名前空間, および宣言の上書きについては、 6 要素や属性に対する名前空間の適用 にて述べる。 [Definition: If the attribute name matches DefaultAttName, then the namespace name in the attribute value is that of the default namespace in the scope of the element to which the declaration is attached.] Default namespaces and overriding of declarations are discussed in 6 Applying Namespaces to Elements and Attributes.

次の例は、名前空間接頭辞 edi を名前空間名 http://ecommerce.example.org/schema に結び付ける名前空間宣言である: An example namespace declaration, which associates the namespace prefix edi with the namespace name http://ecommerce.example.org/schema:

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- 接頭辞 "edi" は "x" 要素とその内容において
       http://ecommerce.example.org/schema に束縛される -->

名前空間制約:予約済みの接頭辞と名前空間名 Namespace constraint: Reserved Prefixes and Namespace Names

接頭辞 xml は、定義により,名前空間名 http://www.w3.org/XML/1998/namespace に束縛される。 これは宣言されてもよいが,する必要はない。 また、 宣言が解除されてはならず, 他のいかなる名前空間名にも束縛されてはならない。 他の接頭辞がこの名前空間名に束縛されてはならない。 この名前空間が既定の名前空間として宣言されてはならない The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be undeclared or bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace.

接頭辞 xmlns は,名前空間束縛の宣言のみに用いられ、定義により,名前空間名 http://www.w3.org/2000/xmlns/ に束縛される。 これは宣言されたり,宣言が解除されてはならない。 他の接頭辞がこの名前空間に束縛されてはならない。 この名前空間が既定の名前空間として宣言されてはならない。 要素名は、接頭辞 xmlns を持ってはならない The prefix xmlns is used only to declare namespace bindings and is by definition bound to the namespace name http://www.w3.org/2000/xmlns/. It MUST NOT be declared or undeclared. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace. Element names MUST NOT have the prefix xmlns.

文字の大小を問わず, x, m, l の3文字の並びから始まる他のすべての接頭辞も予約済みである。 したがって: All other prefixes beginning with the three-letter sequence x, m, l, in any case combination, are reserved. This means that:

  • 利用者は将来の仕様において定義される場合を除き、それらを用いるべきではない。 users SHOULD NOT use them except as defined by later specifications

  • プロセッサは、それらを致命的エラーとみなしてはならない processors MUST NOT treat them as fatal errors.

それ自身としては予約済みでないとしても、その LocalPart が文字の大小を問わず,文字 x, m, l から開始されるような接頭辞付きの名前の利用は、接頭辞なしで用いられたときに予約済みになってしまうので勧められない。 Though they are not themselves reserved, it is inadvisable to use prefixed names whose LocalPart begins with the letters x, m, l, in any case combination, as these names would be reserved if used without a prefix.

4 修飾名

この仕様に適合する XML 文書においては、一部の名前(非終端記号 Name Name に対応する構成子)は,次で定義される 修飾名 として与えられなければならない In XML documents conforming to this specification, some names (constructs corresponding to the nonterminal Name) MUST be given as qualified names, defined as follows:

[7] QName ::= PrefixedName
| UnprefixedName
[8] PrefixedName ::= Prefix ':' LocalPart
[9] UnprefixedName ::= LocalPart
[10] Prefix ::= NCName
[11] LocalPart ::= NCName

接頭辞 は,修飾名の 名前空間接頭辞 部を与え、 名前空間宣言 の中の名前空間 URIIRI 参照に結び付けられなければならない[定義: LocalPart は、修飾名の 局所部 を与える。] The Prefix provides the namespace prefix part of the qualified name, and MUST be associated with a namespace _URI reference in a namespace declaration. [Definition: The LocalPart provides the local part of the qualified name.]

接頭辞は名前空間名のプレースホルダとしてのみ機能するものであることに注意。 アプリケーションは、スコープが包含文書を超えるような名前の構築においては、接頭辞ではなく,名前空間名を利用すべきである。 Note that the prefix functions only as a placeholder for a namespace name. Applications SHOULD use the namespace name, not the prefix, in constructing names whose scope extends beyond the containing document.

5 修飾名の利用

この仕様に適合する XML 文書においては、要素は,次のように, 修飾名 として与えられる: In XML documents conforming to this specification, element names are given as qualified names, as follows:

[12] STag ::= '<' QName (S AttributeAttribute)* S? '>' [NSC: 接頭辞は宣言済み]
[13] ETag ::= '</' QName S? '>' [NSC: 接頭辞は宣言済み]
[14] EmptyElemTag ::= '<' QName (S AttributeAttribute)* S? '/>' [NSC: 接頭辞は宣言済み]

要素名として機能する修飾名の例: An example of a qualified name serving as an element name:

  <!-- 'price' 要素が属する名前空間は
         http://ecommerce.example.org/schema になる -->
  <edi:price xmlns:edi='http://ecommerce.example.org/schema'

属性は 名前空間宣言 になるか,または 修飾名 として名前が与えられる: Attributes are either namespace declarations or their names are given as qualified names:

[15] Attribute ::= NSAttName Eq AttValue
| QName Eq AttValue [NSC: 接頭辞は宣言済み]
[NSC: 属性は一意的]
[NSC: 接頭辞宣言は解除不可]

属性名として機能する修飾名の例: An example of a qualified name serving as an attribute name:

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- 'taxClass' 属性が属する名前空間は
         http://ecommerce.example.org/schema になる -->
  <lineItem edi:taxClass="exempt">Baby food</lineItem>

名前空間制約:接頭辞が宣言済みであること Namespace constraint: Prefix Declared

xml または xmlns 以外の名前空間接頭辞は、 その接頭辞が用いられている要素の開始タグか,またはその先祖要素(すなわち,接頭辞によるマークアップがその 内容 に出現している要素)において、 名前空間宣言 属性により宣言されていなければならない 更に、そのような宣言のうち,最も内側のものの属性値が 空文字列であってはならない The namespace prefix, unless it is xml or xmlns, MUST have been declared in a namespace declaration attribute in either the start-tag of the element where the prefix is used or in an ancestor element (i.e., an element in whose content the prefixed markup occurs). Furthermore, the attribute value in the innermost such declaration MUST NOT be an empty string

名前空間制約:接頭辞の宣言は解除できない Namespace constraint: No Prefix Undeclaring

接頭辞 を宣言する 名前空間宣言 においては(すなわち, NSAttNamePrefixedAttName になっている所では)、 属性値 が空であってはならない In a namespace declaration for a prefix (i.e., where the NSAttName is a PrefixedAttName), the attribute value MUST NOT be empty.

この制約により、名前空間宣言属性が XML 文書実体 の中で直接的にではなく,外部実体で宣言された既定の属性を通して与えられている所では、処理上の困難がもたらされ得る。 その種の宣言は、妥当性検証を行わない XML プロセッサに基づくソフトウェアからは読まれない可能性がある。 多くの XML アプリケーションは、おそらく名前空間に影響されるものも含め,妥当性検証を行うプロセッサを必須としてはいない。 その種のアプリケーションにおいて正しい処理が要求される場合、 名前空間宣言は、直接的に, または 内部サブセットの DTD の中で宣言された既定の属性を通して,のいずれかにより与えられなければならない This constraint may lead to operational difficulties in the case where the namespace declaration attribute is provided, not directly in the XML document entity, but via a default attribute declared in an external entity. Such declarations may not be read by software which is based on a non-validating XML processor. Many XML applications, presumably including namespace-sensitive ones, fail to require validating processors. If correct operation with such applications is required, namespace declarations MUST be provided either directly or via default attributes declared in the internal subset of the DTD.

要素名や属性は、 DTD の中の宣言に出現するときには,修飾名としても与えられる: Element names and attribute names are also given as qualified names when they appear in declarations in the DTD:

[16] doctypedecl ::= '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>'
[17] elementdecl ::= '<!ELEMENT' S QName S contentspec S? '>'
[18] cp ::= (QName | choice | seq) ('?' | '*' | '+')?
[19] Mixed ::= '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[20] AttlistDecl ::= '<!ATTLIST' S QName AttDef* S? '>'
[21] AttDef ::= S (QName | NSAttName) S AttType S DefaultDecl

DTD に基づく妥当性検証は、次の意味で名前空間を認識しないものであることに注意: DTD は,文書内に出現してもよい要素や属性を、(名前空間名, 局所名)の組としてではなく,それらの名前の解釈を行わずに制約する。 名前空間を利用する文書の妥当性が DTD に突き合わせて検証される際には、各インスタンスに用いられている接頭辞と同じ接頭辞が DTD の中でも用いられていなければならない。 DTD は,しかしながら、名前空間を宣言する属性に対し #FIXED 値を供することにより,妥当な文書に利用される名前空間を間接的に制約し得る。 Note that DTD-based validation is not namespace-aware in the following sense: a DTD constrains the elements and attributes that may appear in a document by their uninterpreted names, not by (namespace name, local name) pairs. To validate a document that uses namespaces against a DTD, the same prefixes must be used in the DTD as in the instance. A DTD may however indirectly constrain the namespaces used in a valid document by providing #FIXED values for attributes that declare namespaces.

6 要素や属性に対する名前空間の適用

6.1 名前空間のスコープ

接頭辞を宣言する名前空間宣言のスコープ(有効範囲)は、それが出現する開始タグから対応する終了タグまでの範囲から,より内側にあり, 同じ NSAttName 部を持つような すべての[ 接頭辞を宣言する名前空間宣言 ]のスコープを除外した範囲になる。 特に、出現するタグが空タグの場合のスコープは,そのタグ自身になる。 The scope of a namespace declaration declaring a prefix extends from the beginning of the start-tag in which it appears to the end of the corresponding end-tag, excluding the scope of any inner declarations with the same NSAttName part. In the case of an empty tag, the scope is the tag itself.

そのような名前空間宣言は、そのスコープに入り, かつ その宣言で指定された接頭辞に合致する接頭辞を持つような,すべての要素名/属性名に適用される。 Such a namespace declaration applies to all element and attribute names within its scope whose prefix matches that specified in the declaration.

接頭辞付きの要素名/属性名に対応する 展開名 は、その 接頭辞 を束縛する URIIRI名前空間名 に持ち,その 局所部局所名 に持つ。 The expanded name corresponding to a prefixed element or attribute name has the _URI to which the prefix is bound as its namespace name, and the local part as its local name.

<?xml version="1.01.1"?>

<html:html xmlns:html='http://www.w3.org/1999/xhtml'>

  <html:body><html:p>Moved to 
    <html:a href='http://frob.example.com'>here.</html:a></html:p></html:body>

次の例に示すように、単独の要素において複数の名前空間接頭辞を属性として宣言できる: Multiple namespace prefixes can be declared as attributes of a single element, as shown in this example:

<?xml version="1.01.1"?>
<!-- "bk", "isbn" いずれの名前空間接頭辞も利用可能になる -->
<bk:book xmlns:bk='urn:loc.gov:books'
    <bk:title>Cheaper by the Dozen</bk:title>

接頭辞を宣言する名前空間宣言の属性値は、空であってもよい。 これには、その宣言のスコープにおいて,その接頭辞と名前空間名との結び付けを解除する効果がある。 更なる宣言により,接頭辞を再宣言してもよい The attribute value in a namespace declaration for a prefix MAY be empty. This has the effect, within the scope of the declaration, of removing any association of the prefix with a namespace name. Further declarations MAY re-declare the prefix again:

<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
    <n1:a/>           <!-- 合法: 接頭辞 n1 は http://www.w3.org に束縛されている -->
    <x xmlns:n1="">
        <n1:a/>       <!-- 不正: 接頭辞 n1 はここでは束縛されていない -->
	<x xmlns:n1="http://www.w3.org">
            <n1:a/>   <!-- 合法: 接頭辞 n1 は再び束縛されている -->

6.2 既定の名前空間の適用

既定の名前空間 宣言のスコープ(有効範囲)は、より内側の既定の名前空間宣言のスコープを除き,それが出現する開始タグから対応する終了タグまでにわたる。 空タグの場合のスコープはそのタグ自身になる。 The scope of a default namespace declaration extends from the beginning of the start-tag in which it appears to the end of the corresponding end-tag, excluding the scope of any inner default namespace declarations. In the case of an empty tag, the scope is the tag itself.

既定の名前空間宣言は、そのスコープに入る,接頭辞なしの要素名すべてに適用される。 既定の名前空間宣言は属性名には直接的には適用されない。 接頭辞なしの属性の解釈は、それが出現している要素から決定される。 A default namespace declaration applies to all unprefixed element names within its scope. Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear.

接頭辞なしの要素のスコープ(可視範囲)に,既定の名前空間宣言が存在する場合、その要素に対応する 展開名 は、その 既定の名前空間URIIRI名前空間名 に持つ。 スコープに既定の名前空間宣言がなければ,名前空間名は値を持たない。 接頭辞なしの属性名の名前空間名は 常に値を持たない。 いずれの場合も 局所名局所部 になる(もちろん,これは接頭辞なしの名前自身と同じになる)。 If there is a default namespace declaration in scope, the expanded name corresponding to an unprefixed element name has the _URI of the default namespace as its namespace name. If there is no default namespace declaration in scope, the namespace name has no value. The namespace name for an unprefixed attribute name always has no value. In all cases, the local name is local part (which is of course the same as the unprefixed name itself).

<?xml version="1.01.1"?>
<!-- この場合、要素は既定において HTML 名前空間に属する -->
<html xmlns='http://www.w3.org/1999/xhtml'>
  <body><p>Moved to 
    <a href='http://frob.example.com'>here</a>.</p></body>
<?xml version="1.01.1"?>
<!-- 接頭辞なしの要素型は 'urn:loc.gov:books' に属する -->
<book xmlns='urn:loc.gov:books'
    <title>Cheaper by the Dozen</title>

名前空間のスコープをあてがうやや大きめな例: A larger example of namespace scoping:

<?xml version="1.01.1"?>
<!-- 初期時において,既定の名前空間は 'urn:loc.gov:books' -->
<book xmlns='urn:loc.gov:books'
    <title>Cheaper by the Dozen</title>
      <!-- 説明用の内容のために HTML を既定の名前空間にする -->
      <p xmlns='http://www.w3.org/1999/xhtml'>
          This is a <i>funny</i> book!

既定の名前空間宣言における属性値は、空であってもよい。 これは宣言のスコープにおいて,既定の名前空間が存在しないのと同じ効果をもたらす。 The attribute value in a default namespace declaration MAY be empty. This has the same effect, within the scope of the declaration, of there being no default namespace.

<?xml version='1.01.1'?>
  <!-- table 内の既定の名前空間は HTML の名前空間 -->
  <table xmlns='http://www.w3.org/1999/xhtml'>
     <!-- table セル内部には既定の名前空間が存在しない -->
     <td><brandName xmlns="">Huntsman</brandName></td>
     <td><origin xmlns="">Bath, UK</origin></td>
       <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
         <pro>Wonderful hop, light alcohol, good summer beer</pro>
         <con>Fragile; excessive variance pub to pub</con>

6.3 属性の一意性

名前空間制約:属性は一意的であること Namespace constraint: Attributes Unique

この仕様に適合する XML 文書においては、どのタグも,次のような複数個の属性を含んではならない: In XML documents conforming to this specification, no tag may contain two attributes which:

  1. 同一の名前を持つ,または have identical names, or

  2. 同じ 局所部, および 同一名前空間名 に束縛されている 接頭辞 からなる,修飾名を持つ have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.

この制約は、どの要素においても,複数の属性が同じ 展開名 を持ってはならない要求と等価である。 This constraint is equivalent to requiring that no element have two attributes with the same expanded name.

例えば次では、 bad 空要素タグはいずれも不正になる: For example, each of the bad empty-element tags is illegal in the following:

<!-- n1 と n2 はいずれも http://www.w3.org に束縛される -->
<x xmlns:n1="http://www.w3.org" 
   xmlns:n2="http://www.w3.org" >
  <bad a="1"     a="2" />
  <bad n1:a="1"  n2:a="2" />

しかしながら、次のものはいずれも合法になる。 2番目のものは、属性名には既定の名前空間は適用されないので、合法になる: However, each of the following is legal, the second because the default namespace does not apply to attribute names:

<!-- n1 は既定の名前空間 http://www.w3.org に束縛される -->
<x xmlns:n1="http://www.w3.org" 
   xmlns="http://www.w3.org" >
  <good a="1"     b="2" />
  <good a="1"     n1:a="2" />

7 文書の適合性

この仕様は XML 1.01.1 文書に適用される。 この仕様に適合するためには、文書は XML 1.0 仕様 [XML] 1.1 仕様 [XML 1.1] に従って整形式でなければならない This specification applies to XML 1.x documents. To conform to this specification, a document MUST be well-formed according to the XML 1.x specification [XML 1.1].

この仕様に適合する XML 文書においては、要素名/属性名は QName 生成規則に合致しなければならず, かつ “名前空間制約” を満たさなければならない。 XML 1.01.1 整形式であるために XML 生成規則 Name Name に合致することが 要求されている,文書内の他の(要素名/属性名以外の)すべてのトークンは、この仕様の生成規則 NCName に合致しなければならない In XML documents which conform to this specification, element and attribute names MUST match the production for QName and MUST satisfy the "Namespace Constraints". All other tokens in the document which are REQUIRED, for XML 1.x well-formedness, to match the XML production for Name MUST match this specification's production for NCName.

[定義: 文書はこの仕様に適合するとき, 名前空間 整形式 であるとされる。 ] [Definition: A document is namespace-well-formed if it conforms to this specification. ]

したがって,名前空間 整形式である文書においては: It follows that in a namespace-well-formed document:

加えて、名前空間 整形式なる文書は,名前空間において妥当になり得る。 In addition, a namespace-well-formed document may also be namespace-valid.

[定義: 名前空間 整形式である文書は、 XML 1.01.1 において妥当であり,かつ XML 1.01.1 整形式であるために XML 生成規則 Name Name に合致することが 要求されている 文書内の要素名/属性名 以外のすべてのトークンが,この仕様の生成規則 NCName に合致しているとき、 名前空間において妥当である とされる。 ] [Definition: A namespace-well-formed document is namespace-valid if it is valid according to the XML 1.x specification, and all tokens other than element and attribute names which are REQUIRED, for XML 1.x validity, to match the XML production for Name match this specification's production for NCName. ]

したがって、名前空間において妥当な文書においては: It follows that in a namespace-valid document:

8 プロセッサの適合性

この仕様に適合するためには、プロセッサは名前空間 整形式についての違反を報告しなければならない。 ただし,名前空間名が URI 参照 [RFC3986] 合法な IRI であるかどうかの検査は要求されない。 To conform to this specification, a processor MUST report violations of namespace well-formedness, with the exception that it is not REQUIRED to check that namespace names are URI references [RFC3986]legal IRIs.

[定義: この仕様に適合する XML 妥当性検証プロセッサのうち,名前空間妥当性の違反を報告するものを 名前空間妥当性検証 プロセッサと呼ぶ。 ] [Definition: A validating XML processor that conforms to this specification is namespace-validating if in addition it reports violations of namespace validity. ]


RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, ed. IETF (Internet Engineering Task Force), March 1997. Available at http://www.rfc-editor.org/rfc/rfc2119.txt
RFC 2141: URN Syntax, R. Moats, ed. IETF (Internet Engineering Task Force), May 1997. Available at http://www.rfc-editor.org/rfc/rfc2141.txt.
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, and L. Masinter, eds. IETF (Internet Engineering Task Force), January 2005. Available at http://www.rfc-editor.org/rfc/rfc3986.txt
RFC 3629: UTF-8, a transformation format of ISO 10646, F. Yergeau, ed. IETF (Internet Engineering Task Force), November 2003. Available at http://www.rfc-editor.org/rfc/rfc3629.txt
Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard eds. January 2005. Available at http://www.rfc-editor.org/rfc/rfc3987.txt.
Extensible Markup Language (XML) 1.0, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau eds. W3C (World Wide Web Consortium). Available at http://www.w3.org/TR/REC-xml/.
Extensible Markup Language (XML) 1.0 (Fourth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau eds. W3C (World Wide Web Consortium), 16 August 2006. Available at http://www.w3.org/TR/2006/REC-xml-20060816/.
XML 1.1
Extensible Markup Language (XML) 1.1 (Second Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, and John Cowan eds. W3C (World Wide Web Consortium), 16 August 2006. Available at http://www.w3.org/TR/2006/REC-xml11-20060816/.

B 他の参照文献(非規定)

1.0 Errata
Namespaces in XML Errata. W3C (World Wide Web Consortium). Available at http://www.w3.org/XML/xml-names-19990114-errata.
1.0 2e Errata
Namespaces in XML (Second Edition) Errata. W3C (World Wide Web Consortium). Available at http://www.w3.org/XML/2006/xml-names-errata.
1.1 Errata
Namespaces in XML 1.1 Errata. W3C (World Wide Web Consortium). Available at http://www.w3.org/XML/2004/xml-names11-errata.
Relative URI deprecation
Results of W3C XML Plenary Ballot on relative URI References In namespace declarations 3-17 July 2000, Dave Hollander and C. M. Sperberg-McQueen, 6 September 2000. Available at http://www.w3.org/2000/09/xppa.
Namespaces in XML 1.1 Requirements, Jonathan Marsh, ed. W3C (World Wide Web Consortium), March 2002. Available at http://www.w3.org/TR/2002/WD-xml-names11-req-20020403/.

C XML 名前空間の内部構造(非規定)

この付録は削除された。 This appendix has been deleted.

D バージョン 1.0 からの変更点(非規定)

このバージョンには 2009 年 6 月 20 日付の正誤表 [1.0 Errata] [1.0 2e Errata] が統合されている。 This version incorporates the errata as of 20 July 2009 [1.0 Errata] [1.0 2e Errata].

このバージョンには,バージョン 1.0 に対する 2002 年 12 月 6 日付の正誤表 [1.0 Errata] が統合されている。 加えて,2つの本質的な変更点がある: This version incorporates the errata to version 1.0 as of 6 December 2002 [1.0 Errata]. There are two further substantive changes:

一貫性の向上を図るため,いくつかの語法の変更や追加を含む編集上の変更点がある。 非規定の付録 “XML 名前空間の内部構造” は削除された。 第5版を含む XML 1.0 のすべての版と正しく連結されるようにするため、 BNF が調整された。 There are several editorial changes, including a number of terminology changes and additions intended to produce greater consistency. The non-normative appendix "The Internal Structure of XML Namespaces" has been removed. The BNF has been adjusted to interconnect properly with all editions of XML 1.0, including the fifth edition.

D.1 バージョン 1.1 からの変更点

このバージョンにはバージョン 1.1 に対する正誤表 2006 年 6 月 1 日付 [1.1 Errata] が統合されている。 This version incorporates the errata to version 1.1 as of 1 June 2006 [1.1 Errata].

RFC の最終バージョンがまだ発行されていないので、バージョン 1.1 の初版には独自の IRI の定義が含められていた。 これは取り除かれ, RFC への参照に置き換えられた。 Because the final version of the IRI RFC had not yet been published, the first edition of version 1.1 included its own definition of IRIs. This has been removed, and replaced with a reference to the RFC.

E 謝辞(非規定)

この仕事には, World Wide Web Consortium XML Working Group の関係者達, Special Interest Group, W3C Metadata Activity の関係者達も含め,多くの方々の考えが反映されている。 特に Microsoft の Charles Frankston 氏からは貴重な貢献が得られている。 This work reflects input from a very large number of people, including especially the participants in the World Wide Web Consortium XML Working Group and Special Interest Group and the participants in the W3C Metadata Activity. The contributions of Charles Frankston of Microsoft were particularly valuable.

F 過去の生成規則 (非規定)

次の2つの生成規則は、この仕様の前の2つの版において存在していた改変版である。 それらはもう利用されることはないが、この仕様の日付の無いバージョンへの相互参照のために残されている。 【この訳のページではバージョン 1.0, 1.1 の重畳により生じた重複 id を変更しているため(変更はこの節のみ),この相互参照は機能しない。】 The following two productions are modified versions of ones which were present in the first two editions of this specification. They are no longer used, but are retained here to satisfy cross-references to undated versions of this specification.

NCNameStartChar の定義に元々利用されていた XML 1.0 の Letter 生成規則は XML 1.0 第5版からは名前の定義として正しいものではなくなったので、 NCNameStartChar 生成規則は, XML のどの版に対しても正しい結果が得られるようにするため, NCName に基づく定義に変更された。 Because the Letter production of XML 1.0, originally used in the definition of NCNameStartChar, is no longer the correct basis for defining names since XML 1.0 Fifth Edition, the NCNameStartChar production has been modified to give the correct results against any edition of XML, by defining NCNameStartChar in terms of NCName.

[5] NCNameChar ::= NameChar - ':' /* NameChar から ":" を除外 */
[6] NCNameStartChar ::= NCName - ( Char Char Char* ) /* NCName の最初の文字 */

Note: Production NC-NCNameStartChar takes advantage of the fact that a single-character NCName is necessarily an NCNameStartChar, and works by subtracting from the set of NCNames of all lengths the set of all strings of two or more characters, leaving only the NCNames which are one character long.