JSONスキーマ の検索結果:
…er型がありません（JSONスキーマではinteger型があります）。TypeScriptもinteger型を持たないので、「値は整数である」という制約を型システムで保証することができません。「0から255のあいだの整数」という制約もTypeScript型システムではまったく扱えません。TypeScriptに限らず、部分集合型をサポートしている型システムはあまり見かけませんね。8ビット符号なし整数の型があればいいだろう、と思うかも知れませんが、「0から100のあいだの整数」だ…
…e宣言）と同じ内容をJSONスキーマで書くと次のようになります。 { "description": "fontFaces.jsonの内容、フォントフェース情報の集まり\n キー（プロパティ名）はフォントファイル名", "type" : "object", "properties" : {}, "additionalProperties" : { "description": "フォントフェース情報", "type": "object", "properties": { "fo…
…方法がないことです。JSONスキーマの「ハイパースキーマ」という仕様案はあるにはあるのですが、2010年4月の段階ではイマイチでした。 JSONだってハイパーメディア -- JSONハイパースキーマ仕様をなんとかしたい JSONスキーマ仕様は現在ドラフト第3版となり、仕様としての精度は上がってきてます。 A JSON Media Type for Describing the Structure and Meaning of JSON Documents 例えば、以前の mi…
1年半ほど前、「JSONスキーマとユーザーインターフェース」とか「JSONスキーマと列挙型」において、ランチの注文フォームを素材にスキーマとユーザーインターフェースの問題を考えてました。今、2010年末ならこの問題をどう扱うか？まず、データ型の定義は次のようになります。 /** * ランチの注文 */ type LunchOrder = { /** 会員識別情報 */ "ident" : { "name" : string, "memberNum" : integer }, …
前もって定義されたフォーマットの一覧は次にあります。 http://tools.ietf.org/html/draft-zyp-json-schema-02#section-5.20 表にまとめておくと：（[追記]抜け落ちていたフォーマットを追加[/追記]） 名前 説明 date-time This should be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the reco…
…例は後で出てきます。JSONスキーマでは、スキーマ属性で色々な制約が書けます。スカラー型に関するスキーマ属性の例は既に述べました。オブジェクト型に対するスキーマ属性では、処理のタイミングが二箇所考えられます。オブジェクト開始記号 '{' の直後とオブジェクト終了記号 '}' の直後です。上の図のPとQは、スキーマ属性に対応する述語ノードです。どの位置に述語ノードを挿入するのが適切かはスキーマ属性により、また実装により異なります。（図のなかの、白丸の状態ノードとQを結ぶ点線はあ…
「JSONスキーマ属性とその適用対象の一覧 2010年春・編」から引用： 僕は、JSONでもBase64エンコードのbinary型をネイティブ・サポートすべきだと思っています。XML Schema Part 2: Datatypes ではバイナリデータをサポートしてます（http://www.w3.org/TR/xmlschema-2/#base64Binary）。バイナリがあれば、"format" : "image/gif" のようなスキーマ属性指定にも意味を持たせられます…
…様 -- JSON、JSONスキーマ、マイクロフォーマット、WikiCreoleなどは、ISOやW3Cの難解で膨大な仕様への反省と反感に基づいているフシがあります。説明は事例中心です。しかし、事例による記述に終始すると、そもそも仕様としての役割を果たせないのです。軽量仕様では、BNFや型定義（スキーマ）を毛嫌いしているようですが、このテのフォーマルな道具なしに正確さを担保するのはほぼ不可能でしょう。比較的軽量なRFCだってABNFをヘビーに使っているしね。なんだかまるで振り子…
「JSONスキーマ属性とその適用対象の一覧」（2009年6月）の情報を更新します。現状の最新JSONスキーマ仕様を反映させます。 最新JSONスキーマ仕様 http://tools.ietf.org/html/draft-zyp-json-schema-02 ごく最近導入されたuniqueItemsスキーマ属性は以前から欲しくて僕が勝手に導入していたものです（http://d.hatena.ne.jp/m-hiyama/20090616/1245112697、http://d…
…参照型のスキーマ属性JSONスキーマのスキーマ属性は、型を修飾するスカラー値です。例えば、配列の最小長さはminItemsで指定できます。スキーマ属性を書くと、型に制約が加わります。ハイパーリンクの関係の指定はスキーマ属性としましょう。次が例です。 { "fn" : string(minLength=1), "url" : reference<WebSite>?, "adr" : reference<hCardAdr>?, "detail" : reference<hCard…
JSONスキーマで定義できるデータ型の分類をまた載せます。 基本スカラー型： integer, number, string, boolean, null リスト型： 項目がすべて同じ型である配列型、項目の個数は任意 タプル型： 決まった個数の項目を持つ配列型 タプル＋リスト型： 決まった個数の項目と、それに続く同じ型の任意個の項目を持つ配列型 閉じたオブジェクト型： 決まった個数のプロパティを持つオブジェクト型 開いたオブジェクト型： 決まった個数のプロパティと、同じ型の任…
…スキーマ記述言語は、JSONスキーマ仕様（http://tools.ietf.org/html/draft-zyp-json-schema-01）に基づいています。構文は違いますが、できる限り本家JSONスキーマのセマンティクスを保存するように努めています。ですから、JSONスキーマの書き方がなんとなくでも理解できた人なら、Catyスキーマも書けます。そして、Catyスキーマのほうがはるかに簡潔に記述できます。以下では、「最近のJSONスキーマを解説します」と同じ構成で、Ca…
現在、JSONスキーマはIETFのインターネットドラフトとなっています。 http://tools.ietf.org/html/draft-zyp-json-schema-01 僕がはじめてJSONスキーマを紹介した時（2009年4月）と比べて、一番大きな変化はハイパースキーマ（hyper schema）と呼ばれる仕様が加わったことです。ハイパースキーマは、JSONデータをハイパーメディアと見なすための仕様です。個人的には欲しかった機能ですが、ちょっと「こりゃダメかも感」がた…
…。構造的なデータ型はJSONスキーマで表現できます。ここでは、オリジナルのJSONスキーマではなくて、CatyのJSONスキーマ構文を使います。Catyのスキーマ構文は、JSONオブジェクトリテラルと同じ形なので、読めば分かる形をしています（が、厳密な意味論を持っています）。geoの型定義は次のとおり： type geo = {"geo" : geoValue}; type geoValue = { "latitude" : number, "longitude" : num…
… 空なオプション{}、空なプレーン引数[]は、やっぱり省略できたほうがいいですね。 上の例では使ってませんが、API記述で使うにはアノテーションも必要そうです。例えば、読み取り関数には @reader、更新関数には @updater とか。 JSONスキーマの代替構文としてはじまったCaty/Jcentric型定義ですが、IDL（Interface Definition Language）として利用することになりそうです。もう少し拡張すれば、IDLとしての体裁が整うでしょう。
…の変更点 オリジナルJSONスキーマからの拡張と制限 モジュール内のコメント構文 全体構造 属性パラメータ スカラー型 列挙型 基本型構成子 配列型 オブジェクト型 型に働く演算子 頭部 不安定な部分 はじめになぜ型システムに拘るかというと、Catyをある程度は型安全なシステムにしたいからです。型システムがないと型安全もヘッタクレもないからねぇ。でも、あまり精緻な型システムにしてしまうと、学習負担が増えるし、使い勝手も悪くなるので、エエカゲンな妥協点を見つけたいのです。実用上…
… stringなどのJSONスキーマ仕様で定義された型名は予約されている（ユーザー定義では使用不可能）。公開型（public type）プログラムやスキーマから、定義なしに使える大域的な型。公開型名の名前空間はフラットで、階層構造や修飾はない。公開型は型レジストリによって実現されている。ただし、JSONスキーマ仕様で定義された型名は登録なしに公開済みと考える。型レジストリ“公開型名”と、その名前の“型の定義が収められたスキーマモジュール（コンパイルされた形式かもしれない）”と…
…CR方式、JSONとJSONスキーマなどは、Catyの構成要素となる技術です。「簡単でわかりやすい」が第一の目標なので、複雑さをまねく要因は徹底的に排除します。たいして使いもしない機能や親切心でのカスタマイズ可能性／自由度が累積すると、手が付けられない複雑さとなるので、ミニマリズムを貫く態度が必要です。ある段階で導入した機能でも、後で「要らない」と判断すれば容赦なく切り捨てます。もったいないから残しておくなんて事はしません。正直言って「いくらなんでも機能不足かな」と感じること…
…分のことです。また、JSONスキーマ属性を使った制限や修飾は、ここでは触れません。内容： 基本型 型システムの要件 オプショナル型 配列型 タプル型、リスト型 列挙型 有限集合型と複数選択型 オブジェクト型 -- 次の機会 基本型基本のスカラー型は次のとおり。（nullもスカラーとみなすことにします。） integer number string boolean null 型Sのインスタンスが、必ず型Tのインスタンスであるとき、S ⊆ T と書くことにします。関係「⊆」により…
…ue); それと、「JSONスキーマ、さらに別構文」で述べたスキーマ定義でも使います。この「さらに別構文」についてここで敷衍します。以下で述べるスキーマ構文を「パス形式スキーマ」と呼ぶことにします -- パス（正確にはパスパターン）ごとに型を指定するスタイルだからです。パスをもっと単純化するパス形式スキーマ記述で使うために、単純なパスをさらに制限します。 // 余分な空白は入れないとする Path ::= '$' | Name | Path '.' Name | Path '…
…[1] は同じか？ JSONスキーマでは、object型とarray型は排他的（両方に所属するインスタンスはない）と捉えているようです。foo["1"] はオブジェクト（object型のデータ）に対して適用され、foo[1]は配列（array型のデータ）に対して適用されると考えると、次の解釈が妥当でしょう。 foo["1"] と foo[1] は同じではない。 実例を挙げましょう。（[追記]JavaScriptでは、foo["1"] == foo[1] なので、そのままJav…
…本的なことデータ型はJSONスキーマの型なので、次の型が基本となります。 スカラー型 integer number string boolean 複合型 array object 特殊な型 null any JSONスキーマで書いたユーザー定義型も認めます。ここでは、types as sets の立場を採るので*1、「XがYの部分型」とは、Xの値の集合が、Yの値の集合に含まれることです。これを、X⊆Y と書きましょう。例えば、integer⊆number、boolean⊆an…
「JSONスキーマと列挙型」にて： 今、2つの方向から考えていて、1つは現状のスキーマ言語試案に手を入れていく方向、もう1つは別な新しい構文を模索することです。 新しい構文のほうをチョビット紹介しておきます。この構文を使うためには、オブジェクトのプロパティ名に若干の制限を付ける必要があります。特に、ドルマークとピリオドはプロパティ名には使えないとします。そういう条件を付けた上で、ランチ注文のデータ型は次のように記述できます。 "$" : "ランチご注文" ; "ident" …
JSONスキーマを代替する私家版スキーマ言語に関しては： ウゲーッって感じがしますよね。このウゲーッ感をなんとかしないと使いものになりませんね。現状のスキーマ言語試案はまだダメダメなところがあるので、もうちょい考えてみます。 と、自己批判的なことを言ったので、引き続き議論します。今、2つの方向から考えていて、1つは現状のスキーマ言語試案に手を入れていく方向、もう1つは別な新しい構文を模索することです。とりあえず、現試案を改善する方策を述べます。内容： 列挙型の記述がひどすぎる…
…ら可能です。「型」をJSONスキーマで定義できるものに限定すれば、関数＝JSON処理出力系とテンプレートのあいだにJSONスキーマ・バリデータを挿入して、型の違反をとらまえることができます。いったいなんでまた、テンプレートとそのコンテキストに型を導入するのかというと、ここがまさにプログラマとデザイナの契約界面だと思うからです。契約＝仕様＝型に適合したコンテキストデータを供給するのがプログラマの責務だし、与えられたコンテキストデータを使ってプレゼンテーションを構成するのがデザイ…
JSONスキーマ（http://json-schema.org/）を実際に使おうと、あれこれ考えております。 JSONの可能性がグンと拡がるぞ！ JSONスキーマ JSONスキーマの功罪を、印象や感情じゃなくて考えてみようか JSONスキーマのローカル構文に関する思案・試案 JSONスキーマとユーザーインターフェース まず、言語道断に書きにくい／読みにくいという問題には代替構文を作ろうか、と（上の「JSONスキーマのローカル構文に関する思案・試案」参照）。ただし、これはあくま…
JSONスキーマはデータ構造の定義言語ですから、本来ユーザーインターフェースとは何の関係もないはずです。ですが、仕様（http://www.json-schema.org/）には、optionsというスキーマ属性があります。optionsスキーマ属性はインスタンスの妥当性検証には影響しません（The "options" attribute does not affect validation）。ユーザーインターフェースへのヒントとなります（The "options" attr…
http://json-schema.org/ を読んで表にしてみました。疑問符「?」が付いている項目は、いまいちハッキリとしないところです。 スキーマ属性名 プロパティ number string array object optional ○ - - - - additionalProperties - - - - ○ requires ○ - - - - identity ○ - - - - minimum - ○ - - - maximum - ○ - - - min…
…り切ったのですよ。「JSONスキーマのローカル構文に関する思案・試案」で示した型定義構文を使うことにします。ただし、多少構文（つうか気分）が変わってますが、読めばわかると思います。remarkはプログラムには理解できない、人間向けの注釈です。 FileMetadata = object { "contentLength" : integer(minimum = 0), "contentType" : string(optional = true, remark = "MIME…
JSONスキーマについて書いた2つのエントリー「JSONの可能性がグンと拡がるぞ！ JSONスキーマ」と「JSONスキーマの功罪を、印象や感情じゃなくて考えてみようか」において、僕は次のように書きました。 読みにくい／書きにくいのは相当に痛い欠点だと思います。ローカル／インターナルに使用するなら、もう少し簡略な構文でもいいんじゃないかな、とか考えてます。直接手で書いたり目で見たりすることを考えると、あの構文はどうにもいただけません。JSONオブジェクトにスキーマを埋め込む（自…
