読者です 読者をやめる 読者になる 読者になる

僕の考えた最強のデータ交換用フォーマット

データ交換用フォーマットの現状

データ交換用フォーマットとして XML は優秀です。 柔軟な表現が可能であり、一方では厳密な構造を形式的にスキーマで規定することも可能です。 また、考え方は簡潔です。

しかし近頃ではウェブ API では JSON が用いられることが多くなっています。 ウェブを支配している JavaScript との親和性のよさは XML の利点と引き換えにするだけの価値がある場合もあるでしょう。

XML の欠点

XML の難しさのひとつは名前空間にあると私は考えています。 既存の語彙を差し込むことで再利用できる名前空間の有用性はわかりますが (名前空間の機能を持たない) JSON が広く使われている状況を見ると実は無くてもよい場面の方が多いのではないかとも思えます。 また、属性と子要素との区別は HTML (XHTML) などの文章のマークアップには有効に働きますがプログラムがデータ交換するにはあまり意味がありません。

新しいデータ交換用フォーマット SLN の提案

以上を踏まえて、簡単に使えるデータ交換用フォーマットを考えてみました。 人間が読み書きすることを考えず、 XML の面倒な部分を排除したデータ交換用フォーマットです。 XML に似たタグによる構造化を行指向にやることから私はこれに Structured lines notation (略して SLN) と名付けました。 各行が XML で言うところの開始タグ、テキスト要素、終了タグのいずれかであるようなテキストです。

最初に例を示します。 たとえば人物名と年齢の組を XML で表現するとこうなるでしょう。

<members>
 <person>
  <name>James</name>
  <age>16</age>
 </person>
 <person>
  <name>Alice</name>
  <age>10</age>
 </person>
</members>

SLN で表すとこうなります。

+members
+person
+name
.James
-
+age
.16
-
-
+person
+name
.Alice
-
+age
.10
-
-
-

行の最初がプラス記号である場合が XML でいうところの開始タグに相当し、マイナス記号のみの行が終了タグに相当します。 ピリオドで始まる行がテキスト要素です。 プラスの次の要素から改行までがタグ名です。 空白などが含まれる場合はその空白も含めてタグ名として機能します。 同様にピリオドの次の文字から改行までがテキスト要素の内容です。 XML と同じくただひとつのルート要素を持ちます。

SLN では文字コードとしては原則として UTF-8 を採用します。 文字列のエスケープはありません。 特別な解釈をされてしまう文字を普通の文字とした解釈させるためのものがエスケープと考えると、 SLN には行の最初の文字しか特殊な解釈をされる文字がないのでエスケープの必要がないからです。 ただ、以上の仕様だけではタグ名前にもテキスト要素にも改行を含めることができません。 そこでスラッシュで始まる要素は改行を狭んで前要素と繋げるという仕様も追加します。

例として掲示板のデータを考えてみましょう。 XML でいえば以下のようなデータです。

<bbs>
 <message>
  <name>James</name>
  <content>Ladies and gentleman!
How are you?
</content>
 </message>
 <message>
  <name>Alice</name>
  <content>I'm fine.
Thank you.</content>
 </message>
</bbs>

これは SLN では以下のように表現できます。

+bbs
+message
+name
.James
-
+content
.Ladies and gentleman!
/How are you?
-
-
+message
+name
.Alice
-
+content
.I'm fine.
/Thank you.
-
-
-

スラッシュで始まる前の行が開始タグだった場合にはタグ名に改行を含んだものとして処理することも出来ます。

SLN の表現としての改行は 0x0A の 1 バイトのみとしますが、構文解析した結果の改行をどう解釈するかはアプリケーションの裁量とします。 それと、最後の終了タグの行も改行で終わるのは必須とします。

検討を要す事項

終了タグ

マイナスで始まる行は終了タグであると決めましたが、マイナスと改行の間に文字列が有った場合にどのように解釈するべきか決めかねています。 考えられる候補としては以下がありますが、どれも一長一短があるように思います。

  • 認めない。 余計な文字列はエラーである。
  • 開始タグと同じ文字列があるべきである。
  • 開始タグと同じ文字列があるべきであるが、省略することも許す。
  • 単に無視する。

プログラムが読み書きすることだけを想定しているので、エラー検出を目的とした冗長な文字列はあまり意味がないでしょう。 余計な文字列はエラーとするのが望ましいのではないかというのが私なりの考えです。

記号

各行の最初の文字列をプラス、マイナス、ピリオド、スラッシュとしました。 これらは感覚的に妥当でしょうか?

空行

ルート要素の開始タグの前の空行、終了タグの後の空行を許すべきでしょうか?

運用

ルート要素

ルート要素の名前は実質的にフォーマットを表わす名前として機能します。 汎用的なフォーマットはバージョンナンバーまで含めた詳細な名前をルート要素のタグ名にするのが望ましいと考えます。

順序

SLN では連続するテキストを別の行にするだけで複数のテキスト要素とすることが出来ます。 出現順序に意味付けすることでタグを付けずに済ますという方法は考えられます。

つまり、最初の例をこのように表現するというのもひとつの案です。

+members
+person
.James
.16
-
+person
.Alice
.10
-
-

person 要素の子要素として最初に現れるテキスト要素を名前、次に現れるテキスト要素を年齢ということにすればそれぞれをタグで囲わずに済ませることが出来ます。 データ量が多少節約できるかもしれません。

拡張の余地

行の最初の文字でその行が意味するところを表わすという設計なので、適当な文字に意味付けすれば様々なものを入れられるでしょう。 たとえば $ で始まる行に入っているのは数値型とするというようなことも可能です。 私としては (XML がそうであるように) 要素の意味付けはアプリケーションでやるべきだという考えですが、拡張できる余地は有るに越したことはないでしょう。

Document ID: 4326062d3d9bca78c0a03fc9c1d0f19c