●
この分類で考えるとわたしは微妙に「貴族」てことになるでしょうか。
英語が読めればむかしのML読んで話の展開を追うのだけれど、それはちょっと無理かな?
関連する議論で、XMLユーザーズMLから。
この辺の議論。ほんとは参加したいんだけど、自分の言いたいことがまとめられないうちに参加しちゃうと迷惑かけちゃうから、まとまってから、まだ話題がホットだったら。
ふむ……「しもじもが苦労して築き上げたものが見えない人々」「XMLの起源や歴史を重要視しない人々」ですか。わたしもその中に入ってしまうのかなぁ。
きっと「型が無いXML」ていうのは、「決まり事が完全に無いXML」とは違うことだと思うのだけれど、実際はどんなものなのか想像がつきづらい。
インターフェースなどとして用いない、自分の中に閉じこもったデータ表現形式としてXMLを使う場合には「決まりごと」はそれほど必要では無い。それはその通りで、その場にあっては厳密なデータ型なんて何の意味ももたない。それは(簡単な)設定ファイルの書き方なんかを考えればよくわかることでしょうか。
反面、他とのインターフェースを考えて、可搬性のあるXMLを考えようとすると、それは高度に規格化される必要があって、サポートするどのようなアプリケーションでもそれなりに処理できなくちゃいけない。ですからどんなエレメントがどのような順番で出現し、どこに出現したどんなエレメントの値がアプリケーションでどのような意味を持つか――それはXML SchemaであったりRerax(NG)であったり、そういったスキーマ言語を用いて設計される、それは間違ってない……よね。
厳密なSchema言語が不必要だというわけではなくて、厳密なSchema言語に縛られることで厳密な定義をもたないXMLがXMLではなくなってしまう、そのようになってしまってはXMLにとってよろしいものではない――というのが「ボヘミアン」の主張という理解でいいのでしょうか。
結構気になる議論なので、今後の展開に注目です♪
わたしは、XMLデータをXMLデータたらしめているものは「タグ名」ではなくて「階層構造」だと感じています。そして階層構造を定義するのにXML Schemaって便利だから、比較的簡単なXMLデータ表現を作るときでもそれを使います。
ただ値の型定義なんて適当だし、ほとんど文字列型ってことで定義しますけどね。どうせパリデータ通さない(適当なのが存在しない)かんじなので、内部資料扱いで。
うー やっぱ、こういうセミナー行きたいですよう。あと、「ちゃんとわかってるひとたち」の下でお仕事したいな……
わたしのような素人がちょこちょこっと考えた仕様が、下手すりゃ標準になっちゃうような状況はちょっとまずい。
●
お給料が入ったので今月の資金繰り試算
まっかっかですか(なみだ)
えー。圧迫しているのが何かといえば、5月ごろをめどに行われる予定の引越しに備えた貯金と、4月あたりに支払いがやってくると思われる「レ・ミゼラブル」チケット代の貯金でしょうか……
ほぼ同時期に車の契約に伴う頭金支払いなどもあり――
あぁぁぁ。やっぱりちょっと計画に無理があるってっ しかもいろいろオプションつけたら、車代簡単に400近くなっちゃうってっ(なみだ
というわけで食費を削ります。
すいません。わたしが駅前に落ちてたら拾って置いてください > ひろえそうなひと