XML名前空間 1.1
サイトマップ
||
ホーム
XML
XML名前空間 1.1
> REC-20040204
XML名前空間 1.1
この文書は、
W3C
により作成されW3C勧告として公開されている "
Namespaces in XML 1.1
" (
) を、どら猫本舗が翻訳したものです。
最新版の文書は
にあります。
正式な仕様書は
W3Cサイト
にある
英語版
です。この日本語版は参考にすぎません。
この文書には翻訳上の誤りがあるかもしれません。どら猫本舗は翻訳の正確性を保証しません。あくまでご自身の責任でご利用ください。
お気付きの点がありましたら
どら猫本舗
までお知らせください。
XML名前空間 1.1
W3C勧告 2004年2月4日
このバージョン[原文]:
最新のバージョン:
以前のバージョン:
編集者:
Tim Bray, Textuality
Dave Hollander, Contivo, Inc.
Andrew Layman, Microsoft
Richard Tobin, University of Edinburgh and Markup Technology Ltd
- Version 1.1
この文書の
エラッタ
を参照いただきたい。これには、規範性のある改訂が含まれていることがある。
翻訳
を参照すること。
この文書[原文]は、規範性のないこれらのフォーマットでも入手可能である。
XML
W3C
MIT
ERCIM
Keio
), All Rights Reserved. W3Cの免責(
liability
), 商標(
trademark
), 文書利用(
document use
), ソフトウェア使用許諾(
software licensing
)規則が適用される。
概要
XML名前空間は、拡張可能マークアップ言語で使われる要素名や属性名に、
IRI
参照によって識別される名前空間を結合することによって修飾するための単純な手法を提供するものである。
この文書の位置づけ
この節は、この文書の公開時における位置づけを説明したものである。他の文書がこの文書に取って代わることがある。現行のW3C公刊物の一覧およびこの技術レポートの最新版は、http://www.w3.org/TR/ の
W3C技術レポート索引
で見ることができる。
この文書は、W3Cの勧告 (
Recommendation
) である。この文書は、W3C会員およびその他の利害関係者によってレビューされ、ディレクターによってW3C勧告として公布されている。この文書は、安定的な文書であって、参照素材として利用したり、他の文書から規範性ある参照としての引用に用いられてもかまわない。勧告を作成する際のW3Cの役割は、仕様に対する注意を引き、その広範な普及を推進することにある。このことは、ウェブの機能と相互運用性とを高める。
この文書は、
W3C XML Activity
の産物である。この仕様書は、英語版が規範性ある唯一のバージョンである。しかしながら、この文書の翻訳を探しているのであれば、
を見てみること。
この文書に関連することのある知的所有権についての文書は、ワーキンググループの公開の
知的所有権情報開示ページ
で見ること。
既知の実装は、
Namespaces 1.1 実装レポート
に文書化されている。テストスイートも、
XMLテストスイート
ページを経由して入手することができる。
この文書のエラーは
xml-names-editor@w3.org
までレポートいただきたい。公開
アーカイブ
が利用可能である。この文書のエラッタリストは
で入手できる。
目次
動機と要約
1.1
表記法や用例に関する注意
XML名前空間
2.1
基本概念
2.2
名前空間名としてのIRIの使用
2.3
IRI参照の比較
名前空間を宣言する
有修飾名
有修飾名を使う
要素や属性に名前空間を適用する
6.1
名前空間のスコーピング
6.2
名前空間のデフォルト化
6.3
属性の一意性
文書の適合性
プロセッサの適合性
国際化リソース識別子 (IRI)
付録
規範性ある参照
Other references
(規範性なし)
XML名前空間の内部構造
(規範性なし)
バージョン 1.0 以降の変更点
(規範性なし)
謝辞
(規範性なし)
1 動機と要約
我々は、複数のソフトウェアモジュールのために定義されて利用される要素や属性 (ここでは「マークアップ語彙」と呼ばれる。) が単一のXML文書に包含されてもよい拡張可能マークアップ言語 (XML) のアプリケーションを心に描く。その動機の一つは、モジュラ性である。しっかり理解されていて、そのための有益なソフトウェアモジュールがあるようなマークアップ語彙が存在するのであれば、このマークアップを再利用したほうが、それを再創作するよりもよい。
そのような複数のマークアップ語彙を包含する文書は、認識や衝突の問題を突きつける。ソフトウェアモジュールは、それが処理するよう予定されている要素や属性を認識できる必要がある。これは、何か他のソフトウェアパッケージを対象としているマークアップが同じ要素
や属性名を使っているときに起こる「衝突」に直面したときにでもである。
このようなことを考慮すると、文書構造が、異なるマークアップ語彙に由来する名前が衝突することを避けるように名前を構築することが必須となる。この仕様書は、
XML名前空間
というメカニズムを解説する。これは、要素や属性に
拡張名
を割り当てることにより、これを実現するものである。
1.1 表記法や用例に関する注意
強調
されている箇所では、この文書にある
なければならない(MUST)
てはならない(MUST NOT)
必須である(REQUIRED)
べきである(SHOULD)
べきでない(SHOULD NOT)
てもよい(MAY)
、というキーワードは、
[Keywords]
で解説されているとおり解釈されるべきものである。
この仕様書にある非終端生成規則の多くは、ここではなく、XML仕様書
[XML]
で定義されている。ここで定義されている非終端規則が、XML仕様書で定義されている非終端規則と同じ名前を有するときには、すべての場合で、こちらにある生成規則が、そこで対応するものによって照合される文字列のサブセットに合致する。
この文書の生成規則において、
NSC
とは、「名前空間制約 (Namespace Constraint)」である。これは、この仕様書に適合する文書が従わ
なければならない(MUST)
規則の一つである。
2 XML名前空間
2.1 基本概念
定義
XML名前空間 (XML namespace)
は、
IRI参照
によって識別される。要素名や属性名は、この仕様書で解説されているメカニズムを使ってXML名前空間の中に置かれてよい。]
定義
拡張名 (expanded name)
は、
名前空間名
ローカル名
とからなるペアである。] [
定義
というIRIによって識別される名前空間にある
という名前については、
名前空間名
である。名前空間の中にない
という名前については、
名前空間名
は値がない。] [
定義
: どちらの場合でも
ローカル名 (local name)
である。] 大域的に管理されているIRI名前空間と、その語彙のローカル名とという、この組み合わせこそが、名前の衝突を避けるために効力を有するのである。
IRI参照は、名前の中には認められていない文字を包含することができ、また、よく不便に長くなるので、拡張名は、XML文書の中にある要素や属性を直接に命名するためには使われない。その代わりに、
有修飾名 (qualified name)
が使われる。[
定義
有修飾名 (qualified name)
は、名前空間解釈に従う名前である。] この仕様書に適合する文書では、要素名や属性名は有修飾名として出現する。文法的には、それらは
有修飾名
無プリフィックス名
かのいずれかである。プリフィックスを名前空間名に結合したり、無プリフィックス要素名に適用されるデフォルト名前空間を結合するために、属性ベースの宣言文法が用意される。これらの宣言は、一つの文書の中のいろいろな部分にいろいろなバインディングを適用できるよう、その宣言が出現する要素によってスコーピングされる。この仕様書に適合するプロセッサは、これらの宣言やプリフィックスを認識し、かつ、それらに基づいて動作し
なければならない(MUST)
2.2 名前空間名としてのIRIの使用
空文字列は、合法的なIRI参照ではあるが、名前空間名としては使うことができない。
相対IRI参照を名前空間宣言の中で使うことは、同文書参照を含め、廃止方向 (deprecated) である。
註:
このように相対URI参照を廃止方向としたのは、W3C XML Plenary Ballot
[Relative URI deprecation]
による決定である。これはまた、「DOMやXPathなどといったような今後の仕様書は、それら(訳註:相対URI参照)の解釈を定義しないであろう」とも宣言している。
2.3 IRI参照の比較
ある与えられた名前空間に、ある名前が属しているかどうかや、二つの名前が同じ名前空間に属するかを判断するときに、名前空間を識別するIRI参照が比較される。[
定義
: 二つのIRIは文字列として扱われるのであって、その文字列が同一である場合、すなわち、同じキャラクタ列である場合に、かつ、そのような場合にのみ、
同一 (identical)
である。] 比較は、大文字小文字を区別するものであり、また、%-エスケーピングを実施したり復元したりはしない。
この結果、この意味では同一ではないIRI参照が、同じリソースへと解釈参照されることがある。例としては、大文字小文字や%-エスケーピングだけが違うIRI参照や、異なるベースURIをもつ外部実体にあるIRIがある (ただし、相対URIは名前空間名としては廃止方向であることに注意してほしい)。
名前空間宣言では、IRI参照は属性の
既標準化値
であり、そのため、XMLの文字参照や実体参照の置換は、一切の比較よりも先に既に実行されている。
例:
下記のIRI参照は、大文字小文字が異なっているので、名前空間を識別する上では、すべて異なっている。
下記のIRI参照も、名前空間を識別する上では、すべて異なっている。
これらも同様である。
eacute
という実体が
&eatute
であると定義されている場合、下記の開始タグはすべて、プリフィックス
解釈参照された場合に等価となるIRIの間で混乱が起こるリスクがあるので、%-エスケーピングされた文字を名前空間名で使わないことが、強く奨励される。
3 名前空間を宣言する
定義
: 名前空間
(もっと厳密に言うなら、名前空間バインディング)
は、予約済み属性の一族を使って
宣言 (declare)
される。そうした属性の名前は、
xmlns
であるか、
xmlns:
で始まる
ものでなければならない。これらの属性は、他の一切のXML属性のように、直接与えられてもよいし、
デフォルト
によって与えられてもよい。]
名前空間宣言のための属性名
[1]
NSAttName
::=
PrefixedAttName
DefaultAttName
[2]
PrefixedAttName
::=
'xmlns:'
NCName
[NSC: 予約済みのプリフィックスおよび名前空間名]
[3]
DefaultAttName
::=
'xmlns'
[4]
NCName
::=
NCNameStartChar
NCNameChar
/* XMLの
Name
マイナス ":" */
[5]
NCNameChar
::=
NameChar
- ':'
[5a]
NCNameStartChar
::=
NameStartChar
- ':'
属性の
既標準化値
は、IRI参照 - 名前空間を識別する
名前空間名
- であるか、空文字列であるかのいずれかで
なければならない (MUST)
名前空間名は、その意図された目的を果たすため、一意性と永続性という特性を有するものである
べきである(SHOULD)
。これが (スキーマが存在する場合に) スキーマを引き出すために直接利用できることは、目標としていない。統一リソース名 (URN)
[RFC2141]
は、これらの目的を念頭に置いて設計された文法の一例である。しかしながら、普通のURLも、これらの同じ目的を達成するような方法で管理することができることに注意するべきである。
定義
: 属性名が
PrefixedAttName
に合致する場合、
NCName
名前空間プリフィックス (namespace prefix)
を与える。これは、要素名や属性名を、その宣言の添付先である要素のスコープの中にある属性値の
名前空間名
に結合するために使われる。]
定義
: 属性名が
DefaultAttName
に合致する場合、属性値の
名前空間名
は、その宣言の添付先である要素のスコープの中にある
デフォルト名前空間 (default namespace)
のそれである。] デフォルト名前空間や、宣言の上書きについては、
6 要素や属性に名前空間を適用する
で論じる。
名前空間宣言の例。これは、
edi
という名前空間プリフィックスを
という名前空間名に結合するものである。
属性は
名前空間宣言
であるか、あるいは、それらの名前が
有修飾名
として与えられるかのいずれかである。
属性
[12]
Attribute
::=
NSAttName
Eq
AttValue
QName
Eq
AttValue
[NSC: プリフィックスが定義済み]
属性名として機能する有修飾名の一例:
名前空間制約: プリフィックスが定義済み
名前空間プリフィックスは、それが
xml
または
xmlns
であるのでない限り、そのプリフィックスが使われている要素の開始タグか祖先要素 (すなわち、その
内容
の中に、プリフィックスが付けられたマークアップが出現している要素) かのいずれにある
名前空間宣言
で宣言されてい
なければならない(MUST)
。さらに、そうした最内の宣言の属性値は、
空文字列
であっ
てはならない(MUST NOT)
この制約から、名前空間宣言が、XML
文書実体
の中で直接にではなく、外部実体の中で宣言されているデフォルト属性を経由して与えられる場合には、動作上の難点が導かれることがある。そうした宣言は、妥当性検証を行わないXMLプロセッサをベースとするソフトウェアに読んでもらえないことがある。多くのXMLアプリケーションは、おそらく名前空間を認識するものを含め、妥当性検証を行うプロセッサを必須としてはいない。
そうしたアプリケーションで正しい動作が要求される場合
、名前空間宣言は、直接にか、
DTDの内部サブセット
の中で宣言されたデフォルト属性を経由するかのいずれかによって与えられ
なければならない(MUST)
要素名や属性
は、
DTD
の中にある宣言に出現するときには、有修飾名としても与えられる。
宣言の中の有修飾名
[13]
doctypedecl
::=
'QName
ExternalID
)?
? ('[' (
markupdecl
PEReference
)* ']'
?)? '>'
[14]
elementdecl
::=
'QName
contentspec
? '>'
[15]
cp
::=
QName
choice
seq
) ('?' | '*' | '+')?
[16]
Mixed
::=
'('
? '#PCDATA' (
? '|'
QName
)*
? ')*'
| '('
? '#PCDATA'
? ')'
[17]
AttlistDecl
::=
'QName
AttDef
? '>'
[18]
AttDef
::=
QName
NSAttName
AttType
DefaultDecl
DTDベースの妥当性検証が、以下の意味で名前空間を認識しないものであることに注意してほしい。DTDは、文書内に出現してよい要素や属性を、それらの未解釈名によって制約するものであって、(名前空間名、ローカル名の) ペアによって制約するものではない。名前空間を使っている文書をDTDに照らして妥当性検証するためには、インスタンスと同じプリフィックスがDTDで使われなければならない。しかしながら、DTDは、名前空間を宣言する属性に
#FIXED
値を与えることにより、妥当な文書中で使われている名前空間を間接的に制約してもよい。
6 要素や属性に名前空間を適用する
6.1 名前空間のスコーピング
プリフィックスを宣言する名前空間宣言のスコープは、それが出現する開始タグの最初から、対応する終了タグの最後にまで及ぶ。ただし、内側にあって同じ NSAttName 部を有する一切の宣言のスコープは除く。空タグの場合には、スコープはそのタグ自身である。
そうした名前空間宣言は、そのスコープの内部にあり、その宣言で指定されたプリフィックスに合致するプリフィックスをもつすべての要素および属性名に適用される。
有プリフィックス要素名または属性名に対応する
拡張名
は、その
プリフィックス
に結合されているIRIを
名前空間名
としてもち、
ローカル部
をその
ローカル名
としてもつ。
1.1
"?>
この例に示すように、複数の名前空間プリフィックスを、単一の要素の属性として宣言することができる。
1.1
"?>
あるプリフィックスを表す名前空間宣言の属性値は、空であっ
てもよい(MAY)
。これには、その宣言のスコープの内部で、そのプリフィックスと名前空間名との結合を解くという効果がある。さらに宣言をして、プリフィックスを再び宣言し直し
てもよい(MAY)
6.2 名前空間のデフォルト化
デフォルト名前空間
宣言のスコープは、それが出現している開始タグの最初から、対応する終了タグの最後にまで及ぶ。ただし、内側にある一切のデフォルト宣言のスコープは除く。空タグの場合には、スコープはそのタグ自身である。
デフォルト名前空間宣言は、そのスコープの内部にあるすべての無プリフィックス要素名に適用される。デフォルト名前空間宣言は、属性名には直接には適用されない。無プリフィックス属性の解釈は、それが出現している要素によって決定される。
スコープ内にデフォルト名前空間宣言がある場合、無プリフィックス要素名に対応する
展開名
は、
デフォルト名前空間
のIRIを、その
名前空間名
としてもつ。スコープ内にデフォルト名前空間宣言がない場合、名前空間名は、値を有さない。無プリフィックス属性の名前空間名は、つねに値を有さない。すべての場合で、
ローカル名
は、
ローカル部
である (これは、もちろん、無プリフィックス名そのものと同じである)。
1.1
"?>
Moved to
here.
1.1
"?>
大きめの名前空間スコーピングの例:
1.1
"?>
This is a funny book!
デフォルト名前空間宣言の属性値は、空であっ
てもよい(MAY)
。これには、宣言のスコープの内部では、デフォルト名前空間がないのと同じ効果がある。
1.1
'?>
| Name | Origin | Description |
6.3 属性の一意性
この仕様書に適合するXML文書では、どのタグも、つぎのような二つの属性を包含してはならない。
同一の名前を有する、または
同じ
ローカル部
をもち、かつ、
同一
である
名前空間名
に結合されている
プリフィックス
をもつ有修飾名をもつ。
この制約は、どの要素も同じ
展開名
をもつ二つの属性を持っていないことを要求するのと等価である。
たとえば、以下では、
bad
開始タグはそれぞれ違法である。
しかしながら、以下はそれぞれ合法である。2番目のものは、デフォルト名前空間は属性名に適用されないからである。
7 文書の適合性
この仕様書は、XML 1.1 文書に適用される。この仕様書に適合するためには、文書は、XML 1.1 仕様書
[XML 1.1]
に従って整形式で
なければならない(MUST)
この仕様書に適合するXML文書では、要素名や属性名は、
QName
の生成規則に合致し
なければならず(MUST)
、かつ、「名前空間制約」を満たさ
なければならない(MUST)
。XML 1.1 整形式であるために
Name
のXML生成規則に合致することが
必須である(REQUIRED)
この文書中の他のすべてのトークンは、この仕様書の
NCName
の生成規則に合致し
なければならない(MUST)
定義
: 文書は、この仕様書に適合する場合、
名前空間整形式 (namespace-well-formed)
である。]
従って、名前空間整形式の文書では、つぎのようになる。
すべての要素名および属性名は、0個または1個のコロンを包含する。
実体名、処理命令ターゲット、記法名は、コロンを包含しない。
さらに、名前空間整形式の文書は、名前空間妥当であることがある。
定義
: 名前空間整形式の文書は、それが XML 1.1 仕様書により妥当であって、かつ、XML 1.1 妥当であるためにXMLの
Name
の生成規則に合致することが必須とされている要素名及び属性名以外のすべてのトークンが、この仕様書の
NCName
の生成規則に合致する場合、
名前空間妥当 (namespace-valid)
である。]
従って、名前空間妥当な文書では、つぎのようになる。
ID
型、
IDREF(S)
型、
ENTITY(IES)
型、
NOTATION
型の宣言型をもつ属性は、コロンを包含しない。
8 プロセッサの適合性
この仕様書に適合するためには、プロセッサは、名前空間整形式性の違反をレポートし
なければならない(MUST)
。ただし、その名前空間名が合法なIRIであることをチェックすることは、
必須(REQUIRED)
ではない。
定義
: この仕様書に適合する妥当性検証を行うXMLプロセッサは、さらに名前空間妥当性の違反をレポートする場合、
名前空間妥当性検証を行う(namespace-validating)
ものである。]
9 国際化リソース識別子 (IRI)
国際化リソース識別子 (Internationalized Resource Identifier, IRI) を定義するRFCを作成する作業は、現在進行中である。この作業は未完成であるので、この節では、この仕様書に関する限りで、IRIの文法的な定義を与える。XMLコアワーキンググループは、RFCが公開されたときには、この節をそのRFCへの参照で置き換えるエラッタを発行するつもりである。
名前空間を定義するユーザには、RFCが公開され、IRIをサポートするソフトウェアが一般的に利用されるようになるまで、名前空間名を限定するようアドバイスする。実装者には、同様に、認められる文字の点でドラフトに違反する名前空間名を拒絶しないよう、アドバイスする。
IRIについてのもっと一般性のある定義や議論については、
[IRI draft 5]
(進行中の作業) を見ること。
URI参照は、ASCII文字のサブセットに限定される。IRI参照は、#xA0 以上のほとんどのUnicode文字を認める。初期の IRI RFC のドラフト (例.
[IRI draft 3]
) も、認められていないASCII文字をいくつか認めていたが、現行ドラフト (
[IRI draft 5]
) は認めていない。
定義
[IRI draft 5]
によりIRIで認められる
追加文字 (additional character)
は、つぎのものである。]
Unicode 第0面キャラクタ #xA0 - #xD7FF, #xF900-#xFDCF, #xFDF0-#xFFEF
Unicode 第1-14面キャラクタ #x10000-#x1FFFD ... #xD0000-#xDFFFD, #xE1000-#xEFFFD
定義
IRI参照 (IRI reference)
は、以下のステップを適用してURI参照に変換することのできる文字列である。]
ホスト名部が存在する場合には、それを、
[RFC3490]
の Section 4.1 に指定された ToASCII 演算を、UseSTD3ASCIIRules フラグと AllowUnassigned フラグを TRUE に設定して使って変換する。
すべての
追加文字
を、以下のとおりエスケーピングする。
それぞれの追加文字を、1個以上のバイトとして、UTF-8
[RFC3629]
を変換する。
結果として得られたバイトを、URIエスケーピングメカニズムを用いてエスケープする (すなわち、%HH に変換する。ここで HH は、バイト値を十六進表記したものである)。
元の文字を、結果として得られた文字の並びで置き換える。
註:
[IRI draft 5]
のアルゴリズムには、UCS正規化ステップが含まれているが、これは、どの文字列がIRI参照であるかに違いをもたらさない。
A 規範性ある参照
Keywords
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
, S. Bradner, ed. IETF (Internet Engineering Task Force), March 1997. http://www.rfc-editor.org/rfc/rfc2119.txt で入手可能。
RFC2141
RFC 2141: URN Syntax
, R. Moats, ed. IETF (Internet Engineering Task Force), May 1997.
RFC2396
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax
, T. Berners-Lee, R. Fielding, and L. Masinter, eds. IETF (Internet Engineering Task Force), August 1998. http://www.rfc-editor.org/rfc/rfc2396.txt で入手可能。
RFC2732
RFC 2732: Format for Literal IPv6 Addresses in URL's
, R. Hinden, B. Carpenter, and L. Masinter, eds. IETF (Internet Engineering Task Force), December 1999. http://www.rfc-editor.org/rfc/rfc2732.txt で入手可能。
RFC3490
RFC 3490: Internationalizing Domain Names in Applications (IDNA)
, P. Faltstrom, P. Hoffman, and A. Costello, eds. IETF (Internet Engineering Task Force), March 2003. http://www.rfc-editor.org/rfc/rfc3490.txt で入手可能。
RFC3629
RFC 3629: UTF-8, a transformation format of ISO 10646
, F. Yergeau, ed. IETF (Internet Engineering Task Force), November 2003. http://www.rfc-editor.org/rfc/rfc3629.txt で入手可能。
XML
Extensible Markup Language (XML) 1.0 (Third Edition)
, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau eds. W3C (World Wide Web Consortium), 4 February 2004. http://www.w3.org/TR/REC-xml で入手可能。
XML 1.1
Extensible Markup Language (XML) 1.1
, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and John Cowan eds. W3C (World Wide Web Consortium), 4 February 2004. http://www.w3.org/TR/xml11 で入手可能。
B その他の参照 (規範性なし)
IRI draft 3
Internationalized Resource Identifiers (IRIs)
, M. Duerst and M. Suignard eds. March 2, 2003. http://www.w3.org/International/iri-edit/draft-duerst-iri-03.txt で入手可能。
IRI draft 5
Internationalized Resource Identifiers (IRIs)
, M. Duerst and M. Suignard eds. October 26, 2003. http://www.w3.org/International/iri-edit/draft-duerst-iri-05.txt で入手可能。
1.0 Errata
Namespaces in XML Errata
. W3C (World Wide Web Consortium). http://www.w3.org/XML/xml-names-19990114-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. http://www.w3.org/2000/09/xppa で入手可能。
Requirements
Namespaces in XML 1.1 Requirements
, Jonathan Marsh, ed. W3C (World Wide Web Consortium), March 2002. http://www.w3.org/TR/2002/WD-xml-names11-req-20020403/ で入手可能。
C XML名前空間の内部構造 (規範性なし)
この付録は、削除された。
D バージョン 1.0 以降の変更点 (規範性なし)
このバージョンは、2002年12月6日時点のバージョン 1.0 のエラッタ
[1.0 Errata]
を組み込んでいる。本質的な変更点は2つある。
プリフィックスを宣言解除するためのメカニズムを用意した。
名前空間名は、URIではなく、IRIとした。
編集上の変更点は、いくつかある。これには、一貫性を高めることを狙いとした多数の用語の変更や追加が含まれる。規範性のない付録である「XML名前空間の内部構造」が外された。
E 謝辞 (規範性なし)
この作業は、特に、ワールドワイドウェブ=コンソーシアムのXMLワーキンググループや特別インタレストグループの参加者や、W3C メタデータアクティビティの参加者を含め、極めて多数の人々からの入力を反映したものである。Microsoft の Charles Frankston の強力は、特に価値があった。
どら猫本舗 (
webmaster@doraneko.org