XML Schema問題の要約の要約

大ざっぱで当てにならないW3C XML Schema問題の要約

### 過剰な複雑さと基本構造のいびつさ > W3Cという組織は、自らがXML Schemaを勧告している関係上、建前としてスキーマをXML Schemaで書かねばなりません。その結果、W3Cで行われている多くの言語作成活動においてXML Schemaによるスキーマ作成が行われ、その結果として上手く書けない事例がいくつも発生しているとされています。

XMLのプロフェッショナルであるはずのW3Cに関与する人間すら、XML Schemaを使えていない現実!

### PSVI問題 Post Schema Validation Infoset問題。 同じXML文書でも、XML Schemaを通さなかった場合と、XML Schemaを通した場合でInfosetが変わってきてしまう問題(XML Schemaのデフォルト値の適用)

* 参考 : 『XMLにおける「ボヘミアンと貴族の階級闘争」を読み解く』を読み解いてみたら例示が欲しくなりました – XML & SOA

### 特定される単一のスキーマ > XML Schemaは、1つの名前空間に対応するスキーマが1つ存在するという前提を取るアーキテクチャであると言われています。

たしかに1つの文書に複数のスキーマを割り当てたいケースもあるかも。 データと妥当性を分離した、妥当かどうかもContextに依存させるような疎結合なアーキテクチャを実現したいケースもありそう。

### 貴族とボヘミアンの対立問題 > XML Schemaは、全てのXML文書に対応するスキーマが存在し、読み込む際には必ず検証を行うアーキテクチャを前提としていると言われます。つまり、検証しない使用法を全て認めないことを理想としていると考えられます。

> ここで注意すべき点は、ボヘミアンの立場がスキーマ不要論ではないことです。スキーマには、使うべき時と、使わない方が良い時がある、という立場です。

現場では、柔軟にXMLを使用したいはず。

### W3Cの権威 > 世界におけるISOにせよ、日本国内におけるJISにせよ、その権威は本来W3Cより高いものであるにも関わらず、WWWの世界ではW3Cが最も権威を持つかのような錯覚が一部にあって、それが盲目的なXML Schema支持につながっている面があります。

W3Cが論理的で理性的な判断を下せない理由は何か?

【匠に聞く】モデリングが「道具」になるには専門領域に特化しなければならない──Executable UMLの考案者Stephen J. Mellor氏 : IT Pro ニュース

【匠に聞く】モデリングが「道具」になるには専門領域に特化しなければならない──Executable UMLの考案者Stephen J. Mellor氏 : IT Pro ニュース

via Stephen J. Mellor氏のインタビュー記事 | 日々精進 – スパークスシステムズ ジャパン代表のBlog

> ──UMLは,用途ごとの言語仕様を定義するために「プロファイル」という枠組みを用意している。UMLをベースにしたDSLは,プロファイルとして作られていくことになるのか。 > > 私個人は,そうならないことを望んでいる。UMLのプロファイルは,あくまでもUMLの範囲内で定義されるものだ。これでは,その業界に存在する独自の記号を利用できない。その業界で長年積み上げられてきた資産が切り捨てられてしまう。これはとてもばかげた話だ。その業界に適した記号を使った表記法にすべきだ。

Mellor氏はDSL派のようだ。

PoEAA 3rd

PoEAA読書会 第3回に参加した。まとまりなく書いてみる。

* 発表資料はこちら

### 駆け込みで前夜に資料作成 前夜1:00am-6:00amぐらいで3章のサマリをPPTで作成し、持参&発表。 直前に駆け込みで作ったこともあり、内容はイマイチだったけど、議論のベースとして機能したので結果オーライ。ということにする。んで、質は量に転化する。ということにする。(これまでも、これからも)

あ、資料作成の際には昔WOMeetingで使った資料を流用したりした。継承の実装方式の図や、RDBMSのイメージとかEnterpriseObject(笑)とか。ちょっと手を抜けた。

### 進め方など 当初、15?25分程度でさくっと進めるつもりだったのだけど、実際始めてみると、 発表しつつ、議論しつつな感じで進めたほうがよさそうな印象を受けたので、そうすることにした。 自分が2部以降をキチンと読み込んでいなかったため、議論についていけなかったり、議論の整理がうまくなかったりした部分があったのは反省点。でも、読み込む時間がないのよねー。あと、情報を体系化して、脳みそへ定着するための時間が。

議論に参加してくれた方、感謝。いろいろ話して、楽しくやりましょう。 特に、ひがさんには感謝!感謝!有益なネタ振りをたくさんしてくれた。しかも、カナリ読み込んでるし! つーか、発表者のくせしてあまり読み込んでなくてごめんなさい。たたき台として存在する意味があると自分に言い聞かせる。

### UnitOfWork EOEditingContext! EOF最強! 楽○○○○○○御が実質的に機能しない点を除いては!(苦笑)

### 外部キー制約、参照整合性 外部キー制約付けない派が大多数。なるほど。確かに実務上は付けないほうがよさそうではあるのだけど。 ちょっと意外ではあった。

### 依存 依存概念をCASCADE ON XXX制約でカバーできるかどうか?については良くわからない。 EOFの場合、(確か) 親Objectと子Objectのリレーションシップを切断すると、子Objectが削除されたはず。 というわけで、Objectの世界で依存概念の意味をどこまで規定するかに依存すると思われる。 ただ、たいていの場合、CASCADE ON XXX制約で十分な気がしている。

一瞬、ER図にも依存概念を導入したほうが良いかなと妄想した。うーん、IDEF1xとかだと入ってそうだな。でも、あれを理解する気にはなれない・・・。ま、いいや。

### EOF/WebObjects 発表が終わって、ogijunさんとボソボソ。 やっぱ、EOFはいけてるねーとか。

O/Rマッパーに必要な概念のほとんどを実装しているからねぇ。 Apple買収後も、XML対応とかいろいろ適切な方向に進化してくれたら面白かったのに!とか思う。

あと、Webフレームワークがステートフルな方向に行くのなら、WebObjectsフレームワークも・・・って、完全に脱線だなコリャ。

ちょっとWebobjectsに興味をもたれたかたは、ここらへんとか、suzukiさんの有益な資料(spice-of-life.net – WebObjects)などをごらんくださいまし。

### 概念をビジュアル化することの効能 余談だけど、概念を脳みそへ定着させるために発表スライドをつくるというのは結構有益。 ソフトウェアをビジュアル化する作業は、モデリング技術の延長上にある。複雑なもの・見えないものをある側面に着目して、表現することに相当する。短期的・長期的に有益。 というわけで、誰か、次回のサマリ担当に立候補してくれないかなーと。

* ポジションペーパ

[…]

Russian Doll と Salami Slice

スキーマ設計とクラス図 | ノート

なるほど。興味深い。

同じことを書くのに、ちょっと自由度があるのがイヤンなかんじもするな。

エラーの分類とエラーハンドリング戦略

エラーの種類を簡単に。

* ビジネスロジックエラー(代替フロー) * システムエラー * 入力エラー * プログラミングエラー * 内部状態不整合エラー * (他にある?)

### ビジネスロジックエラー * ユースケースにおける、いわゆる代替フロー。

* 残高1000円なのに、2000円引き出そうとしたときの処理フローに相当 * 機能定義・論理設計・基本設計段階で洗い出される必要がある。 * 機能の一部として、エラー発生時の処理が明確に洗い出されている必要がある。 * アプリケーションは、エラー内容に応じた処理を実行するように実装されている必要がある。

### システムエラー * 動作環境などが正常に動いていない場合のエラー

* ATMシステムで、ATMとバックエンドシステムのネットワークが疎通していない場合や、バックエンドシステムにおいて、RDBMSが動作していない場合などに相当 * 基本設計・詳細設計段階で洗い出されている必要がある。 * 要件にも依存するが、致命的エラーであることをユーザーに通知できれば良い。エラーの種別毎に処理を行うなどは求められないケースが多い。 * 適切に不具合情報を入れ込んだロギングが重要。 * 2重化など、システムエラーが起こる原因自体を排除するor発生頻度を低める取り組みについては、ここでは触れない。

### 入力エラー * いわゆるvalidationエラー。入力したデータが、まずい場合

* (機能定義・)論理設計・基本設計段階で洗い出される必要がある。 * 金額入力欄にアルファベットが入力された場合など * (ビジネスロジックと同様?)

### プログラミングエラー * API・クラスライブラリ・フレームワーク・ユーティリティクラスを適切に使用していないために生じるエラー。

* 基本的に、詳細設計・プログラミング作業中にしか発生しない。 […]

XAエミュレート対象となるリソースマネージャの扱い

from S2.2.9 リリース – koichikのひとりごと > 例えば XA に対応した Oracle (Oracle が提供する XADataSource を使用する) と対応していない HSQLDB (S2 が提供する XADataSource で XA をエミュレートする) を同一のトランザクション中で更新する場合,最初に HSQLDB からコネクションを取得することで,二つの DB がどちらもコミットされるかどちらもロールバックされるかという原子性 (ACID の A) が実現できます.

なるほどーそういうことか。理解できました! ありがとうございます! koichikさん。

### 昨日の質問 昨日のJ2EE勉強会(仮)で、以下の質問をさせていただいた。(若干、わかりやすく整理しています。昨日はもっと要領を得ない質問な感じ(苦笑)でした。)

> S2JTAの枠組みの中で、XA非対応のリソースマネージャを扱う場合、XAをエミューレートするラッパ経由で扱うことになるようだが、その場合、 > XA非対応のリソースマネージャ1つがJTA配下のトランザクションに参加している場合、1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ1つの場合、通常の1フェーズコミットプロトコルを使用する > XA対応のリソースマネージャ2つ以上の場合、2フェーズコミットプロトコルを使用する >

> という理解でよいか?

なるほど、S2JTAの実装はLast Resource Commit Optimizationの機構を持っているため、 1番目、2番目の内容は正しいようだ。ただ、koichikさんの日記にかかれてあるように、

> Last […]

J2EE勉強会(仮)

J2EE勉強会(仮) – ひがやすを blog

参加してきた。

内容は、

* Seasar2のJTA実装、コネクションプール実装をソースコード中心に追っかける * JSFの特徴・アーキテクチャをPPTで説明する

でした。説明はすべてひがさん。お疲れ様でした&ありがとうございました。

[…]

リアルタイム・システムの構造化分析 リアルタイム・システムの仕様書作成手法

* リアルタイム・システムの構造化分析 リアルタイム・システムの仕様書作成手法 – 電脳書房在庫目録

昔から読んでみたく思っていたのだけど、いまさら・・・・って感じだな。高いし。

なぜ読みたいと思っていたのか?というと、分析のためのツールキットはたくさん持っていたほうがよいと考えるから。 コンサルタントが経営分析などのテンプレートをたくさん用意しているように、 設計者・分析者はソフトウェアの分析のためのある程度のツールキットを用意すべきと考えるから。

ほんたったがほしいがいじんさん

仕事を終えてから、明日のズラ会に備えてファミレスでJava Transaction Processingを読んでいた。 いつもと同じように、X31と書見台:ほんたった、ポストイットがお供。 そして、本の内容や目次、不明な用語などをExcelにまとめつつ、読み進めた。

この本の対象はトランザクションという分野であるため内容が多少概念的だし、英語で書かれているから、読むのにちょっと時間がかかる。今日は無理に読み進めることはせず、JDBCとXAResouceの関係、JTAの代表的なインタフェースであるUserTransaction, TransactionManager, Transactionの関係と、UserTransactionとTransactionManagerの相違点に触れている箇所を抜粋して読んだ。 これらの位置づけを大体理解したので、明日のズラ会で不明な点、理解があいまいな点がクリアになることを期待しようかなと。

さて、本題。

自分は、よくファミレスで本を読むのだけど、そのときは、

* Thinkpad X31をたたきながら、 * 本を書見台:ほんたったに載せて、 * ポストイットを手元に置いて

という感じでやっている。結構大掛かりな感じであって、ちょっと目立つ。でも便利なので、気にしないことにしている。

当然、今日もこんな感じでやっていた。

今日は遠くから熱い視線を感じる・・・。と思ったら、遠くの席の外人さんにチェックされているようだ。 そんなに物珍しいかね? ま、気にせずに本を読んでいたのだけど、2時になったので帰宅することにした。 レジに向かう途中、その外人さんが近寄ってきて、たどたどしい日本語で・・・

Java Transaction Processing

さて、土曜日までにどこまで読めるかなー