WR blog

XMLとスキーマ PPL Summer School 2004

via 読書記録ChangeLog

なんだか楽しそうなことが書いてありそうなんだけど、よくわからない・・・orz.

とりあえず気になるところを引用しておく。

スキーマと意味？

スキーマは、文書の意味を規定しない > XML文書全体の集合の部分集合を規定しているだけ > DTDに適合する文書を扱うスタイルシート、ソフトウェア、人間の総体が意味を規定する

スキーマは、世界中にあまたあるXML文書を、

スキーマに合致したXML文書 スキーマに合致しないXML文書

の2つに分類するだけ。

別の見解

スキーマは，integerすら持たないXML文書を、型情報を備えたオブジェクトへと昇華させる > 効率は負ける > 誤ったレイヤリングである

「誤ったレイヤリング」の「こころ」はなんだろう？？？？

スキーマの理論

よくわからない・・・が、楽しそう。キーワードだけ並べておく。

正規木文法 木オートマトン 正規文法 文脈自由（列）文法 Chomsky Hierarchy 局所文法(local grammar)

課題1: スキーマの汎用化と特殊化

広い範囲の人が合意するスキーマは複雑すぎて作れない >

日本の電子政府で必要な範囲の人名スキーマ

狭い範囲の人が合意するスキーマは広範囲の情報交換には使えない

UN/CEFACTやOASISで制定された人名（国際化）されたもの）とどう折り合いをつければいいのか？

双方向変換？

「広い範囲の人が合意するスキーマは複雑すぎて作れない」 うーむ・・・。

「XML処理手法と理論」XML [...]

August 6th, 2005 | Category: XML | Leave a comment

koichikさんのコメント : Csus4.net - Just example. ≫ Blog Archive ≫ PoEAA 4th により書名を教えてたいただき、早速購入したのですが・・・・・

む、むずいっす・・・・。 付録AのOSAの形式的定義の構成を抜粋します・・・。

A.1 ORMから第一階述語と規則への写像

A.1.1 述語 A.1.2 規則

A.2 第一階言語から数学的モデルへの写像 A.3 OSAメタモデル

A.3.1 図A.4における最初の制約の変換 A.3.2 図A.4における二つ目の制約の変換 A.3.3 図A.4における三つ目の制約の変換 A.3.4 図A.4における四つ目の制約の変換

なかなか手ごわそうです・・・オブジェクト指向システム開発―分析・設計・プログラミングへの実践的アプローチ

July 13th, 2005 | Category: Book, ObjectModeling, Think | Comments (2)

会計システムのアーキテクチャ論 - 設計者の発言

制度会計ベースのアーキテクチャについて

まず、現在の主流である「制度会計に管理会計が寄生しているスタイル」というのは、「管理会計上の諸問題を仕訳に組み込んでしまう」というものだ。とりあえずすべての取引を１個ずつ仕訳して決算書を作ると同時に、仕訳データを集計して管理会計上の諸問題を管理しようとする。

管理会計ベースのアーキテクチャについて

いっぽうの「管理会計に制度会計が寄生しているスタイル」では、仕訳テーブルは単純な形をとる。このスタイルにおいて仕訳は、公告用の決算書を出力するためだけのネタなので、必要最小限度の項目さえ載っていればいいからだ。日々の活動はそれぞれの業務データ管理サブシステムによって管理されている。個々の取引毎に仕訳する必要はなく、月次でも、場合によっては四半期毎のサマリーデータからでも仕訳すればいいので、仕訳データ量もずっと少ない。期中の進捗については、仕訳データ経由ではなくそれぞれのサブシステムが保持する数字を直接集計して監視すればよい。システムは基本的に「管理会計システム」で、決算書出力機能が「オマケ」としてついているようなイメージだ。

簿記の枠組み、すなわち、汎用の枠組みに大して、業界・業種・企業に特化したデータ を盛り込むようなアプローチには限界がある。 そして、業界・業種・企業に特化したデータをベースに汎用のデータを生成するアプローチのほうが良いと理解した。

六の日記はここにはないぞ - 仕訳をいつ作るかなあと云う話

確かに仕訳中心で全てを従属させると大統一理論てな塩梅でとても愉快なんだけど、やっぱり計上→訂正→消込とかのフローに沿った部分は債務は債務、債権は債権で別管理にしておいて、仕訳は仕訳でその時々のスナップショットみたいな考えでパカパカ生成するのみにして、「どれに対する消込かって？債権側に聞けや」みたく人任せにする形が、良かったなァ、って設計した人と後から反省した。

の話にも通じるのかなっと。

July 3rd, 2005 | Category: Accounting, Modeling | Leave a comment

＠IT：XMLデータベース開発方法論（1）　1/4 ＠IT：XMLデータベース開発方法論（1）　2/4 ＠IT：XMLデータベース開発方法論（1）　3/4 ＠IT：XMLデータベース開発方法論（1）　4/4

面白い。

from ＠IT：XMLデータベース開発方法論（1）　2/4 :

RDBは「例外的な処理」との相性が悪いということである。きれいに正規化されたデータを扱っている限り、RDBは実に快適で、わずかな手間で素晴らしい成果をもたらしてくれる。しかし、そこから逸脱する例外的なデータや、例外的な処理が発生すると急に扱いにくくなる。そして、例外的なデータや例外的な処理は、多かれ少なかれ、どこかで要求に入り込んでくる。

（筆者を批判するわけでなく・・・）より正確に言えば、上記の批判（というか制約か・・・）はRDB特有のものではない。厳密な意味にでの「データモデル」を扱った場合に一般の問題といえると思う。

from ＠IT：XMLデータベース開発方法論（1）　3/4 : AWK、使い捨てデータ処理の切り札

AWKによるデータ処理は、RDBによるデータ処理の対極に存在するといってよいだろう。RDBによるデータ処理は、専門家によって構築され、大量の定型化された情報を効率よく処理し、日常業務の中で数え切れないほど繰り返し長期にわたって使うことができる。しかし、AWKによるデータ処理は、ユーザー自身が記述し、少量の不定形の情報を効率は悪くとも必要十分な時間で処理し、使い捨てられる。

from ＠IT：XMLデータベース開発方法論（1）　4/4 : RDBとAWKの中間ポイントに位置するXML

XMLとは、テキストでデータを記述するというAWK的テキスト処理の世界を継承しつつ、そこに要素や属性という構造を導入することで、自由を制約した言語であると見ることができる。自由の制約は、利用者がより少ない手間で成果を得られるようにするために導入される。しかし、自由の制約は最小限に抑えられ、RDBと同水準の高い秩序は要求していない。

筆者の立場は、XMLを、厳密な意味での「データモデル」として捕らえたものではない。逆の立場をとっている。（モデルとして）全くの構造を持たないテキストデータに対して、制約を加えたものという立場をとる。まさにボヘミアン。

June 27th, 2005 | Category: RelationalModeling, XML | Leave a comment