XMLSchema/ベストプラクティス

ネット上で閲覧できる XMLSchema のベストプラクティスがいくつかあるが、そのうちの一つ。

XML Schemas: Best Practices

ベストプラクティスのカタログの典型的なものは、個々のプラクティスやパターンを一つのユニットとして、形式を統一して分類し、列挙したようなものが多いが、これはスキーマ設計をする上での判断の分岐点を示してから、採り得る選択肢をメリット・デメリットと共に詳しく解説していく構成になっている。

以下、簡単な紹介。

Default Namespace - targetNamespace or XMLSchema? →原文
デフォルト名前空間（schema 定義の「xmlns=」に指定するやつ）に何を選ぶか。選択肢は以下。

• targetNamespace に指定した名前空間をデフォルトとする

  <xsd:schema targetNamespace="○○" xmlns="○○" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ～/>

• "http://www.w3.org/2001/XMLSchema"をデフォルトとする

  <schema targetNamespace="○○" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:△△="○○" ～/>

• デフォルト名前空間を使わない

  <xsd:schema targetNamespace="○○" xmlns:△△="○○" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ～/>

原文では、どれを選ぶのかについて好みに依存する部分が大きいとされている。個人的には、(3)のパターンでxmlns:tns="○○"として統一するのが、一貫性も可読性もそこそこ維持できると思う。

Hide (Localize) Versus Expose Namespaces →原文
schema 要素の elementFormDefault 属性を"qualified"にするか "unqualified"にするか。

それぞれの長所短所の解説に加えて、qualified 版とunqualified 版の2つのコピーを提供するというプラクティスが紹介されている。（2重管理になる心配をしてしまうが、どうなんだろう。）

Global versus Local →原文
要素や型を、グローバル(<schema>直下に定義)にするかローカルにするか。

以下、三つの選択肢について解説されている。

• Russian Doll design･･･ローカルに定義
• Salami Slice design･･･グローバルに要素を定義
• The Venetian Blind design･･･グローバルに型を定義

Element versus Type
要素として定義するか型として定義するか。迷うくらいなら型として定義する事が推奨されている。

Zero, One, or Many Namespaces →原文
複数のスキーマを定義する際、どのように targetNamespace を指定すればよいか。3つの選択肢について詳説

• Heterogeneous Namespace Design･･･個別に targetNamespace を与える
• Homogeneous Namespace Design･･･一個の targetNamespace で統一
• Chameleon Namespace Design･･･主となるスキーマにtargetNamespaceを与え、従となるものには与えない

Variable Content Containers →原文
複数種の要素を載せるコンテナ要素の定義の仕方。４つのアプローチについて詳説。

• an abstract element and element substitution
• a <choice> element
• an abstract type and type substitution
• a dangling type

Composition versus Subclassing →原文
オブジェクト指向プログラミングにおける「継承かコンポジションか？」という問題と同じで、やはり Composition が強く推奨されている。

Creating Extensible Content Models →原文
スキーマモデルにどのように拡張性を与えるか。

• Extensibility via Type Substitution
• Extensibility via the Element

後者が推奨されているが、Non-Determinism問題への注意が喚起され、<other>要素を用いた回避策の紹介がある。

Extending XML Schemas →原文
ある XML文書をチェックするのに XMLSchemasの文法だけで足りない場合にどうするか。以下3解法の長所短所を解説。

• Supplement with Another Schema Language
  
• Write Code to Express Additional Constraints
  
• Express Additional Constraints with an XSLT/XPath Stylesheet

Should the targetNamespace be a URL or a URN? →原文
URL／URNの使い分けについての考察。本来ユニークな識別子にすぎない名前空間の指定に URL が使われると、これがリソースのロケーションと誤解されることが多いという問題が、まず提起される。この問題を踏まえたうえで、将来性としては URL に分があるとし、回避策として http://の代わりに namespace://やxmlns://を用いるというプラクティスが紹介されている。

What's the best way to version schemas? →原文
スキーマの変更にともなうバージョン管理・使い分けの手法

• Change the (internal) schema version attribute.
• Create a schemaVersion attribute on the root element.
• Change the schema's targetNamespace.
• Change the name/location of the schema.

Achieving Maximum Dynamic Capability in your Schemas →原文
ダイナミックであるほど良い XMLSchema であるという価値観をまず提示。その心得を「postpone decisions as long as possible」として打ち出している。以下の2つのプラクティスが紹介されている。

• targetNamespace を指定しないままにしておく
• <import>のschemaLocationを指定しないままにしておく

targetNamespace は常に指定するべしというプラクティス集もあるが・・・