DXL Step-by-Step：#20）pardef と par ノードの関係② インポート時

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 20 回です。前回に引き続き、pardef と par ノードの関係の調査なのですが、今回は、テスト的に手書きした DXL を文書としてインポート（保存）させ、より詳しく条件を調査します。

定義位置のテスト

padef の定義の前に id を使用した場合のテストです。次のように、pardef の前後にその礼儀を使用した段落 par を配置してみました。

作成した文書は次の通りで、１行目には行間がセットされず、２～３行目は正しくセットされています。この結果より、pardef の定義は使用する前に設定しないと無視されるようです。

ちなみに、作成した文書をもう一度 DXL に変換すると次のようになりました。１行目の前に pardef ノードが挿入され、id が再付番されています。

この結果より、DXL で記述した通りに保存されるのではなく、ドミノオブジェクトとして正しい状態に調整して保存していること、id は関連付けが目的で番号自体に意味はないことがわかりますね。

定義位置と id

続いては複数の実験をまとめて行います。テスト項目は次の３点です。

1. pardef の定義は直前である必要があるか？
2. pardef は使用する順で定義しなければならないか？
3. id は 1 から連番で付与する必要があるか？

テストする DXL は次の通りです。

この DXL はエラーもなくインポートでき、正常に２～３行目だけ行間が設定されました。

pardef は先頭にまとめても正常に動作するんですね。まとまっているほうが、見やすいですし、書式の種類の確認など簡単になると思うんですけどね...

複数フィールドと id

最後に複数のリッチテキストがある場合についてテストします。前回の確認では、既存文書を DXL に変換すると次のような変わった仕様が確認できました。

• pardef の定義はフィールドごと
• id は文書内でユニーク

これが必須なのか確認するため次のような DXL を作成してみました。各フィールドで同じ id を設定しています。

インポートは正常に終了し、各フィールドとも行間は正しく設定されていました。この結果より、フィールド内で整合性が正しければ正常にインポートできることが確認できました。

まとめ

pardef と par の関係を２回にわたって調査しました。その結果をまとめると次のようになります。インポートでは、今回の実験で最低限守ればよい条件を記述しています。

	エクスポート	インポート
pardef	初回使用の par ノードの直前	使用前に定義すればよい 先頭にまとめてもかまわない
id 付番	文書内で連番	フィールド内でユニークであれば連番でなくてもよい
定義の重複	同じスタイルを複数の pardef で定義しても問題なし

DXL を利用してリッチテキストを含む文書を作成する場合、pardef と par ノードを正しく記述できないと、希望通りのフォーマットで表現できません。

ただ、今回のテストで、思った以上におおらかな仕様であることがわかりました。エクスポートと同じ仕様で DXL を自作するなら大変そうですが、今回の実験で得た最低限の条件を守るだけなら少し楽ができそうですね。

前回

DXL Step-by-Step

次回