5.1 共通
要素、型、そして属性に共通する命名規則を以下に定める。
[GNR 1]
内容： マルチバイト文字（漢字、ひらがな、カタカナなど）は使用してはならない。
説明：
スキーマの標準化および国際的な利用という観点から、作動環境やアプリケーションによって対応 できない可能性のあるマルチバイト文字は避け、アルファベットなどのシングルバイト文字を使用す る。
[GNR 2]
内容：
名前には英単語を使用するのが望ましい。
説明：
標準スキーマとして国際的にも普及させるため日本語を使用したローマ字表記は避け、汎用語とし て英単語を使用する。
[GNR 3]
内容： 冗長な名前は避け、簡潔で情報を的確に識別する名前を付けるべきである。
説明：
理解しやすい標準スキーマを作成するうえで重要な点である。要素名や属性名は、最終的にはスキ ーマに準拠したインスタンスでも使用され、ユーザが読む可能性があるため、読みやすい簡潔な名前 が求められる。
[GNR 4]
内容： 略語の使用は控えるべきである。
説明：
一般的に使用されている略語、例えば識別子を表すIDや番号を表すNumなどを除き、略語の使 用は極力控えるべきである。ただし、専門用語あるいは業界用語として想定利用者間で周知の略語の 場合はこの限りではない。また、本来命名したい名前が非常に長く、略す必要に迫られることもある かもしれない。その場合には、略語の意味が分かるようにxsd:annotationなどを使って説明を加え るべきである。
[GNR 5] 内容：
他の標準スキーマをインポートして使用する場合、他の名前空間で宣言されている要
素、型、また属性と重複した名前を使うことを避けるのが望ましい。
説明：
属する名前空間が異なれば名前（ローカル名）が重複していたとしても問題はない。しかし、混乱 を避けるため、同じ名前を使わないよう心がけるのが望ましい。
5.2 要素名
要素に特有な命名規定を以下に列挙する。
[ETN 1]
内容：
要素名が複数の単語から成る場合、UpperCamelCaseルールを採用するのが望まし い。
説明：
UpperCamelCaseとは、単語の頭文字を大文字で表現することである。そのようにすることによ
り、要素名が読みやすくなる。
例：
組織の損益計算書をXML形式で記述した場合、そのルート要素を<ProfitAndLossAccount>とす るほうが<profitandlossaccount>とするよりも読みやすい。
5.3 型名
型に特有な命名規定を以下に列挙する。
[TDN 1]
内容： 型の場合、型名の最後に"〜Type"と付けるのが望ましい。
説明：
要素宣言と区別し、それが型宣言であることをより分かり易くするためこのような命名規則が必要 となる。この意味では、混乱を避けるため、要素名や属性名に"〜Type"という名前を付けるのを避け るべきである。
例：
<xsd:complexType name="addressType">
<xsd:sequence>
…
</xsd:sequence>
</xsd:complexType>
[TDN 2]
内容：
定義される型が特定の要素だけに使用される場合、その要素名を型名に含めるのが望 ましい。
説明：
定義する型が複数の要素によって参照される場合は一般的な名前を付けることができるが、特定の 要素だけに使用される場合、その要素に特化した型であることを明示的に示すためにこのようにする ことが望ましい。
例：
<xsd:element name="address" type="addressType">
5.4 属性名
属性に特有な命名規定を以下に列挙する。
[ATN 1]
内容：
ローカルな属性を定義する場合、属性を宣言する要素と同じ名前を付けるのは望まし くない。
説明：
標準スキーマに沿って作成されるインスタンスを読みやすくするため要素と属性の名前は分ける のが望ましい。
例：
XMLスキーマ
+---
<xsd:element name="note">
<xsd:complexType>
…
<xsd:attribute name="note" type="xsd:string"/>
</xsd:complexType>
+--- XMLインスタンス +---
<note note="status">
shipping
</note>
+---