このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

JSONスキーマ属性とその適用対象の一覧 2010年春・編

「JSONスキーマ属性とその適用対象の一覧」(2009年6月)の情報を更新します。現状の最新JSONスキーマ仕様を反映させます。

ごく最近導入されたuniqueItemsスキーマ属性は以前から欲しくて僕が勝手に導入していたものです(http://d.hatena.ne.jp/m-hiyama/20090616/1245112697http://d.hatena.ne.jp/m-hiyama/20100408/1270703293)。正式仕様になりそうでうれしい。同じく最新のdivisibleByも使えそうです。

スキーマ属性名 適用対象となる型 意味
minimum number 最小値
maximum number 最大値
minimumCanEqual number 最小値はイコールを許す
maximumCanEqual number 最大値はイコールを許す
maxDecimal number 小数点以下の桁数
divisibleBy number 特定の数で割り切れる
minLength string 文字列の最小長
maxLength string 文字列の最大長
format string, number 文字列と数値のフォーマット
pattern string 正規表現パターン*1
minItems array 配列の最小長
maxItems array 配列の最大長
uniqueItems array 配列項目が全部異なる

formatスキーマ属性の値であるフォーマット名は、テキストか数値で表現可能なMIMEメディアタイプなら何でも指定することができます。例えば、RFC4180(http://tools.ietf.org/html/rfc4180)で定義されているCSV(カンマ区切り)なら、"format" : "text/csv" となります。次に挙げる短いフォーマット名も使えます。(面倒なので原文をそのまま引用。)

  • date-time - This should be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
  • date - This should be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
  • time - This should be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
  • utc-millisec - This should be the difference, measured in milliseconds, between the specified time and midnight, January 1, 1970 UTC. The value should be a number (integer or float).
  • regex - A regular expression.
  • color - This is a CSS color (like "#FF0000" or "red").
  • style - This is a CSS style definition (like "color: red; background-color:#FFF").
  • phone - This should be a phone number (format may follow E.123).
  • uri - This value should be a URI..
  • email - This should be an email address.
  • ip-address - This should be an ip version 4 address.
  • ipv6 - This should be an ip version 6 address.
  • street-address - This should be a street address.
  • locality - This should be a city or town.
  • region - This should be a region (a state in the US, province in Canada, etc.)
  • postal-code - This should be a postal code (AKA zip code).
  • country - This should be the name of a country.

時刻関係はISO 8601、正規表現はPCRE形式でしょう(おそらく)。uri, email, ip-address, ipv6 は対応するRFCで定義されています。phone, street-address, locality, region, postal-code, country はマイクロフォーマット(microformats)のhCardと同じですね。もともとの定義はvcardRFCにあると思います(未確認)。住所関係は日本風の解釈が必要でしょう。それと、金額型がまだ定義されていません。

新しいフォーマットをユーザーが定義するときは、短い名前ではなくてURLをフォーマット名に使うことが推奨されます。

バイナリデータに関する所感

文字列がバイナリデータを表すときは、contentEncodingスキーマ属性でエンコーディングを自由に指定することになってますが、バイナリデータのエンコーディングは固定したほうがいいと思います。Base64エンコーディングを採用し、data:スキームを利用するのが無難そうです。

僕は、JSONでもBase64エンコードのbinary型をネイティブ・サポートすべきだと思っています。XML Schema Part 2: Datatypes ではバイナリデータをサポートしてます(http://www.w3.org/TR/xmlschema-2/#base64Binary)。バイナリがあれば、"format" : "image/gif" のようなスキーマ属性指定にも意味を持たせられます。

JSONスキーマXML Schema Part 2: Datatypes は非常によく似た仕様です。JSONスキーマスキーマ属性とXML Schema Part 2の制約ファセットはほぼ同じ概念です。バイナリに限った話ではないですが、「ほとんど同じだが微妙に違う」のはロクなことにならないので、可能な限り一致させるべきでしょう。出自の異なる仕様を調整するのはそれなりに大変ではありますが。

*1:patternを乱用しないようにご注意。