cloudy and rain

UNIXやLINUX、時事放談など気になったことを無作為に書きつらねています。 The topic which becomes matter of concern of UNIX and LINUX and society is written on world wide.

Friday, August 24, 2007

久々に頭に来た。どうしてこうあたま悪いんだ?

先日、GIGAZINEを見ていたら、あるサイトに非常に頭に来ているコトを書いてらしたので、私も見てみました。http://www.jassa.jp/association/special_bk/007/index.html私もこの人まともな頭あんのか?記事全文を掲載。私の反論も載せます。
まずは問題のコイツの記事から。

ここのところ、「格差社会」という言葉が定着し、「格差の是正」が国会でも大きく取り上げられるに至っており、派遣がワーキングプアを生み、格差社会の元凶であるかのような論調しばしば見られる。これは、非常に一面的な見方であり、我々としては、派遣が我が国経済社会の中で果たしている役割を正しく認識し、評価して頂きたいと思っている。
労働者派遣法が1986年7月に施行されて20年を経過し、売上高4兆円強、派遣労働者数約130万人、受け入れ事業所数66万、派遣業の事業所数4万8千となり、派遣業は、労働力需給システムの重要な機能の1つとして、我が国労働市場の活性化、効率化にとって欠かせない存在となりつつある。にもかかわらず、ここに来て、派遣業に対して逆風が吹くに至った。なぜかと考えると、次のような理由が考えられる。「実感がない」といわれながらも景気拡大が続く中で、雇用、処遇の改善圧力が強まってきている。その実現を妨げているのが、「国際競争力の強化」などと並んで「派遣の存在」も理由の1つととらえられているのではないかと思われる。

派遣が非正規労働者の大層を占めていると思われている。派遣という働き方が、「正社員になれないから仕方なしに選択したもの。」と思われている。昨今、偽装請負の問題が大きく取り上げられ、派遣への切り替えも進んでいるが、請負と派遣が混同されているケースも多い。
これらが主な理由と思われるが、いわば誤解である。
まず、(1)についてであるが、「派遣」がなかったら、常用が増えるかと言うとそうではない。最近、派遣の浸透に伴って、企業が派遣を活用する場面がノンコア業務から一歩踏み込んでコアの周辺業務まで拡がりつつあることからすると、若干はそうした事も考えられる。

しかし、派遣にはそもそも「常用代替の防止」ということで、制度上、種々の措置がとられている。そして、次に見るようにいわゆる非正規に占める派遣の割合
がかなり小さい。これらから、派遣がなかった場合でも、パート、アルバイト、契約社員などが増えていただけと思われる
次に(2)については、派遣労働者数は下記のように140万人であり、これに対してパート、アルバイトは1100万人、契約社員らは300万人いる。いわゆる「非正規(この言葉自体適切な表現とは思われないが。)」の中に占める割合は8%、雇用者全体では2%に過ぎない。ところが、規制緩和などもあって急速に拡大し、注目を集めたために、格差社会の象徴のようなイメージが形成されたのではないかと思われる。

(3)については、後述のように、派遣労働者が働く動機は千差万別であり、賃金もまた千差万別である。にもかかわらず、これらを単純平均して、働き方がほぼ一定している常用労働者と比較するため、その差が強調されている。常用労働者と同様の働き方をしている派遣労働者の賃金は、責任範囲の違いや賞与など、制度上の違いを考慮すると、直接働いたことへの対価という点では、言われるほど大きな差はないと思われる。

(4)については、2005年10月に厚生労働省が行った「労働力需給制度についてのアンケート調査」の結果によれば、派遣を選択した理由に「正社員として就職先が見つからなかった。」が33%あるものの、「働きたい仕事内容が選べる」が40%とこれを上回っている。派遣は働き方の一つとして、定着しつつある。
 正社員への登用ばかりを求める論調が多くなっている。正規雇用だけが好ましいものでそれ以外は良くないものとするならば、上のようなフレキシブルな働き
方は否定され、結果として経済活動は停滞し、失業者も増加することとなる。

 また、「正社員としての就職先が見つかるまで」つなぎとして派遣で働く者もいて、派遣会社はこうした者に就業の機会を提供している。

さらに、紹介予定派遣が制度化されたことにより、正規雇用を望む派遣労働者の安定雇用の機会が増大している。
(3)能力開発の推進
一般的に派遣労働者は正社員に比べて能力開発の機会が乏しいとの指摘がある。ビジネスマナーやパソコンのエクセル・ワードの基礎的なものから専門的なものまで、スキル向上やキャリア形成に各派遣会社は努力している。労働者の視点から見れば、派遣労働者として多くの職場を経験し、あるいは、自分が身に付けたいスキルの習得が可能な仕事を選ぶことで、早期に的確なスキルを習得することができ、エンプロイアビリティー(就業可能性)を高められる。

(4)企業活動への人的支援
派遣先企業が派遣労働者を受け入れる理由として、コストの面が強調されがちであるが、既述の厚生労働省のアンケート調査によれば、「コストが割安なた
め」は32%で、最も多いのは「欠員補充など、必要な人員を迅速に確保できる」(50%)であり、さらに、「一時的業務量の変化への対応」、「特別な知
識・技術が必要なため」などとなっている。
 サービスや商品のライフサイクルが短くなり、また、個別ニーズへの対応が迅速に求められる中、各企業は必要な者を自社でじっくり養成することが困難に
なっており、派遣会社は企業が求める能力を持つ者を的確、迅速に供給している。


以上のように、派遣業は、日本の経済社会に重要な役割を果たしているし、今後も果たしていくはずだ。正規、非正規、アウトソーシングなど、それぞれに特長と役割がある。二者択一的に、正規は良くて非正規はダメ、などと決め付けるべきものではない。これらを経営戦略に基づいて、どうミックスさせて活用していくかが企業にとって重要であるし、労働者にとっても働くうえで多様な選択肢が持てることとなる。

労働政策研究・研修機構による「日本人の働き方総合調査」(2005年)でもあきらかなように、派遣労働者の満足度は正規社員はもちろん、パートなど他の非正規社員より概して高いことも付け加えておきたい。企業と労働者の多様なニーズの受け皿として、派遣業が今後とも機能していくためには、派遣労働者が安心して働ける就労環境を引き続き整え、派遣元と派遣先の良好な関係を引き続き構築していくことが求められる。業界としては、次の点に注力していきたい。

コンプライアンス(法令順守)を一層徹底し、受け入れ企業に対しても法令順守を働きかけていく。派遣労働者にまつわるトラブルは、雇用主である派遣元との間にも起こるが、働く現場である派遣先においても多く発生している。このため、派遣元に対してコンプライアンスの徹底を図るとともに、行政の協力も求めながら、派遣先に対して必要なお願いを続けていく。派遣労働者に対する各種社会保険の全面適用を徹底する。社会保険の全面適用は安定就労の前提として、徹底を図る。一方で、社会保険を始めとする各種制度は、常用労働者を前提に整備されているため、派遣(短期、断続、移動)に適した制度改革を求めていく。

職業能力開発の情報・機会の付与に努める。
派遣労働者のキャリア開発及びエンプロイアビリティーの向上のため、職業能力開発の情報・機会の提供に努める。
正社員を希望する派遣労働者に対しては、それに向けた必要な援助を行う。<
均衡待遇への配慮を進める。
派遣労働者の就業環境、福利厚生などについて、派遣先が、自ら雇用する労働者との均衡に配慮し、便宜を図ってくれるよう求めていく。
派遣先に理解を求め、安全衛生やリーガルコストについて、派遣元と派遣先の責任分担を整理する。
派遣業が人を扱うビジネスであることの再認識、徹底を図り、上記の対策を浸透させることにより、派遣元、派遣先そして働くスタッフの3者が、共にハッピーになる派遣業を実現していきたい。
(ただし、一部総務省統計局の数字は7~9月の数字を10~12月の数字に置き換えている)

最期はもはや絵に描いたモチ。派遣先が、自ら雇用する労働者との均衡に配慮し、便宜を図ってくれるよう求めていく。----------コトがないように企業努力をして、規制緩和になるコトで雇用拡大だといって、雛形を造り事実は自由な解雇をみとめたのである。国の方針の逆を上手く点いた盲点に何も触れないで理想論を語る。こんなバカがまだいるのか?

これが私の反論。

別にあなた達のような団体が、いたところでどのような影響力があるのか知りませんが、派遣労働者数は下記のように140万人であり、これに対してパート、アルバイトは1100万人、契約社員らは300万人いる。割合は8%、雇用者全体では2%に過ぎない。といっていますが、それはあくまで机上の上でのデータであって、実体は何もお判りではないようですね。格差問題の引き金がドコにあるのかをキチンとお考えになったことはあるのでしょうか?
あなたのいっている労働者派遣法が1986年7月に施行されて20年を経過というのは、現在でも機能しているとお思いなんだとしたら、なにも判っていないことになります。確かに,日本企業は,戦後の高度経済成長の時代を経て,雇用保障を前提とした日本的雇用ルールを作ってきました。雇用保障と引き替えに,年功的賃金制度,柔軟な配転などの人事処遇,協調的な労使関係があったのでしょう。敗戦直後の激烈な労働争議を経験した「階級的妥協」という側面があったと言われていますよね?しかし,この雇用保障を前提とした雇用ルールは大企業と中堅企業で妥当していただけで,中小零細企業では「建前」にしかすぎず,現実ではありませんでした(労働者の7割は中小零細に雇用されていた)。あなたがいっているのは、この零細企業が既にアルバイト代わりに不正労働している実態が、表面化していないコトが問題なんです。だからデータなんぞいくら持ち出しても、意味などありません。それはまるで、昼間労働人口画増加する、オフィスITアカウントを含めて「ネット人口8000万」とかいってる馬鹿げた通産省と同じです。基準が誤っているのに、そんなのはでたらめな会計処理と変らない。同時に,日本企業は,昔から,雇用保障を受けない季節工,臨時工,社外工などを活用してきましたし。どですかね?そんなところが、「素直に申告などしますか?」。非正規労働者を拡大しようと思えば,過去においても十分に拡大して活用できたはず。今までは、正社員による技術の承継や労働意欲の維持・向上,多能工化による柔軟な生産組織を維持することができたから、企業にとってメリットがあった。日本企業は,けっして「解雇規制が緩やかだったから/解雇規制が厳しかったから」,正社員を雇い続けてきたわけではないはずです。つまり,当時の客観的な経済情勢から,正社員を中心とした生産組織を維持することが企業経営上,適切であった(もうかる)からにほかなりません。とどのつまりは、企業の論理。それだけ。現在,企業が正社員の採用をできるだけ抑制しているのは,「解雇規制が厳しいから、とか,厳しくなりそうだから」ではないと思います。割高な正社員を雇用しなければならないほど価値のある生産組織=労働組織を日本企業が今、持っていないからなのでしょう。日本のITはアメリカに比べ12年は遅れているんですよ。基礎開発の遅れなんて惨憺たるものですよね?研究だけは好きですけど、実現できる予算はない。正社員を雇い入れて,雇用を蓄えなければならないほど利益をあげるような新技術や新製品の開発などの売上げを伸ばす見通しが企業にないからです。現実を直視して下さい。解雇規制を緩和すれば,より一層,非正規雇用が増大するだけです。解雇規制を緩和しても,大企業が正社員を増やすとは到底思えません。(そう思える人はお人好し?=合理的な愚か者?)。あなたがなぜこの解雇規制が変ってしまったことに言及しないのか不思議。雇用が増えたんではなく、いつどのように止めさせても自由、ということが重大な欠陥であるということで、ここに格差の温床があるんじゃないですか?何寝言いってんですか?今更ながら、人手不足だからと、高卒入れたって時既に遅し。もうベテランは去る一方ですよね?もっとも,経済学者は,「解雇規制緩和により,労務コストが低くなる。したがって,起業が活発化し,新技術の開発も活性化する。そして,新産業も起こり,雇用が創出されるのだ。」と言うんでしょうな。つまり,要するに狙いは「労務コストの低減」なんです。
あなたね、そんなことを今度、掲示板にでもいいなさい。世間の評価をちっとは浴びた方がいいですよ。

実名をあげますが、あのOOOOでさえ、雇用の35%以上は「非正規雇用」ですよ。現に御手洗が親分に昇格した際、多くの非正規雇用を解雇しまくりましたが、そのうち二重派遣の実体が表面化するのを恐れた会社側が、一方の派遣会社に頼んで首にしたなんてコトを口止めまでするんですから。そんな立派な団体なら、もうちょっと社会勉強して下さいね。

以上。

大人げないかも知れんが、OOOOOは実名入りだ。問題の本質は雇用拡大ではなくて、解雇の解禁、つまり保証がないやつはどんどん使い捨てて良いという国のお墨付きをもらった、派遣会社へ対してのバッシングであって、「雇用」などという話ではなく、保証がないやつはどんどん使い捨てて良いという状態のことを問題にしているのが、今の現実。
大企業がピンハネしても、自由競争だからで済ます体質だろ?お国は一旦決めておいて、「解釈は人それぞれ」の無責任ぶり。そら大敗するわな。
どいつもこいつもバカ丸出しでこの国は良いのか?

無料カウンター

Friday, August 17, 2007

混乱を招く方法でXMLをややこしくしない事が重要

鶏が先か卵が先かの話ではありませんが、前回はXMLは単独で開発するものではなく、必ずスキーマと共に開発することで、データは確実な実用性の高い保証が出来るということを書きました。単なるXMLの”構造”についての妥当性が確認できても、何の意味もありません。DTDで使われる要素の種類やその役割を示す属性の付与、これにより構造を保証、XML Schemaはその内容までに深く言及することで、インターフェイスに入力プログラムがあれば「確実におかしな入力を防ぐ」事が可能になります。実際スキーマの設計はXMLの中でもその大半であると言っていいでしょう。そもそもはじめから「対象実体外参照名前空間」などまったく意識する必要はありません。DTDであればELEMENT、XML Schemaであれば、最初からxsd:で設計していけば良いだけです。必要に迫られるまでATTLISTも、simpleTypeも考える必要はありません。まずはできあがりのXMLなど思い浮かべることを止めることです。どうしてもXMLを扱うシステムでは、そこに注視しがちですが、データに確実な保証を与えるつまり、信頼できるデーターとして定義できてないXMLは、とんちんかんな注文書を渡され推測しながら品だしを行うようなものです。(頭の悪い人のために努力することはとても疲れます。何せ理解できていない人のために意味のない指令に従うのですから)RELAX NGには、敢えて触れてはいませんが、これはDTDさえ理解できれば、記述に悩む仕様ではないからです。仕様書はXML Schemaに比べ、わかりやすいと言うよりやたらと”長い”ですが。(対象実体外参照名前空間の概念は理解しておいた方が良いでしょう)重要なのは「構造」ではなく「内容」です。妙な例ですがパスワードを内容に保つといった「気が違った」要素を考えてみましょう。この場合はじめは単なる文字列つまりCDATA(string)ですが、類推を容易にするようなものは避けたいと考え、少なくとも文字の中に数字を含んでいないとダメとすると、要素の結合を利用し2種類の内容を保証する定義を考えれば良いでしょうし、空白も含めるとなれば配列として考えることにもなるでしょう。このコンテナを複合型としたものを単純型に再定義して再利用・・・など、内容から始めると自然と構造のアイデアは出てきます。XMLSchemaは内容に関する制限に対し柔軟で階層的ではなく、コンテナとして保持できるのが特徴です。再利用する際も個別に考えることが出来、内容に対しより注視して考慮できます。余談ですがそれはそれは判りやすいXMLとしてはSOAPがありますね。プロトコルバインディングヘッダに基本的な情報、プロトコル、ホスト情報等があり、内容として要素に囲まれた内容が記述、要素定義を原始に対象外実体参照を利用し要素を定義するといった具合です。これをサーバ側で定義に基づき記述して、HTTPプロトコルでデータを記述に基づきクライアントプログラムと通信というシステムですが、結局XMLを利用するプログラムが複雑である割に出来ることが「期待したほど成果がない」のが実体ではないでしょうか。サーバの処理とクライアントの処理が同じAPIとは限らないので、実用的ではありません。(環境を整備しないと使えない。)形はシンプルですが処理方法に課題が多すぎですね。XMLの可用性ではなく単なるインターフェイスとしてしか捉えていないので、当たり前といえば当たり前です。大学での研究発表とは違って、何が出来るかではなく実現出来る成果の結果が価値を決めるのですから。(実現するのは事業ですから)
話がそれましたが、構造に注視すると、XMLをデータを入れておく入れ物としてしか見られなくなり、処理が多様化するだけで意味は全くありません。スキーマを考えたXMLからスタートすればかなり絞り込まれた内容でも、構造を辿ってより多くの情報を保つことが出来るのです。

Labels:

実際の利用価値としてXMLを再評価する

XMLについて特にスキーマなどは、詳しく解説するほど難解ではありません。そこで、システムの組み立てとしてどう設計すべきなのかを考えてみましょう。ヘンなハナシですが、既存のXML、これを利用するというのであるなら、そもそもこんな考えは必要ありません。つまりおかしな構造でないとしても、意味のない構造のHTMLがまかり通っている現在、同じようなXMLを利用するなら、平たくいえば定義が緩いことで成立している文書、それをパーサで拾い上げようとするなら、アプリの方で苦労すればいいことなのです。単純構造で属性が原始の要素に付与されてあり、内包している要素と内容がツリーのような階層として整然と並んでいることで、保証出来ているといった場合など。しかしデーターベースのような構造としてシンプルなデーターの階層など、むしろランダムに格納できるからこそ本来の役割をするはず。実際データベースの管理以外、なるべくなら利用の際に手間取るのだけはご免でしょうから。すると格納されるデータ形式がフォーマットとして確立してあれば、少ない手順と簡単なキーワードを元に要素の属性を手がかりに、内容などにとらわれず抽出、利用、再加工が容易になります。となると重要なのは、簡単な構造からスタートし最終的に複雑になってもその構造をシンプル、且つ階層を維持できる設計をし、そのスキーマのメンテナンスを容易に出来ることが要求されます。となると、実はXMLとスキーマは同時というか、平行で開発する必要があります。幸いにも構造が理解できれば、単なるエディタ(高価なIDEも有りますが、根本的にエディタ一丁で充分です)で記述してオンラインで検証結果を確認できる時代になりましたから。無料カウンター




Powered by ScribeFire.

Wednesday, August 15, 2007

XMLパーサでなくとも、やれることはやれる。

XML第3弾。DTDについて、前回は実体参照関係について、DocBookを例にこうなっていると書きましたが、そもそもプログラムから使うためのXMLを他のスキーマなりルールに則った形がとても面倒。あらかじめ申しておきますが、ここは1からスキーマを設計する事を説明しています。妥当性を検証するのは、何もXML自体を記述するためではありません。要するの構造を理解する上で、XSLTとアプリを組み合わせて他のアプリのインターフェイスにするということです。DTDは要素中心のXML仕様なら、W3CXMLSchemaの方は真価を発揮するのは、複合型をどう取り扱うかです。そういえば、このW3CXMLSchemaの組み込みの固有要素にallというのがありますが、http://www.horobi.com/xml/XMLSchemaDosAndDONTs.ja.htmlnの中に

基底型:
&lt;xs:all&gt;
&lt;xs:element name="a" /&gt;
&lt;xs:element name="b" /&gt;
&lt;xs:element name="c" minOccurs="0" /&gt;
&lt;/xs:all&gt;

制限による派生型:
&lt;xs:all&gt;
&lt;xs:element name="b" /&gt;
&lt;xs:element name="a" /&gt;
&lt;/xs:all&gt;

という記述があり、後者は不正なのが「せっかく制限を正しく書いても」と書いてあったがこれは、仕様書にキチンと記載があります。xs:allは謂わばコンテナの親にあたるので、この要素には、例えるならminOccurs="1"という属性を子に与える制限を保っているので、必ずこの要素の内容は全て出現するのが、前提です。この要素の属性は、親に対して上書きなど出来ないので、これは定義そのものが間違っていますね。

こんなのもありました。

&lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMSchema"
targetNamespace="http://example.com"&gt;
&lt;!-- attribute whose name is foo --&gt;
&lt;xs:attribute name="foo" type="xs:float" /&gt;

&lt;xs:element name="root"&gt;
&lt;xs:complexType&gt;
&lt;xs:attribute ref="foo" /&gt;
&lt;/xs:complexType&gt;
&lt;/xs:element&gt;
&lt;/xs:schema&gt;

ここでは名前空間をルート要素として属性を与えていること自体、誤りです。
名前空間にあるtargetNamespace="http://example.com"ですが、文中ではXML全体に属性を与えたいということの意味で書かれたのだと思いますが、スキーマ定義の中で名前無し複合型で属性が宣言してあります。

これでは、始めにxs:attribute ref="foo"が読み込まれてしまい、グローバルがそれを上書きするのでおかしな事になるでしょう。宣言にattributeFormDefalt=の記述が足らないと考えるのが妥当でしょう。
後述している記述もあまり管理しにくい構成だと思いますね。わざわざグループ化するメリットはないのではないでしょうか。根本的に要素に限って利用した方が効率的です。属性は制約を受けないので、根本的にいくらでも子にローカルで与えられますし、グローバルで管理できます。

ヘタな工夫をするくらいなら、XMLでの記述は管理を煩雑にするだけです。

パーサーとはXMLを操作したり、値を削除挿入したりなどをする際に、そのプログラムのもつクラスライブラリを取り込んだり、またそのプログラムを利用する方法の事ですが、それをを組み合わせたアプリの設計も効率の悪いものになるでしょう。
しかしながら、スキーマに対してのドキュメントは少ないですね。冗長で意味のない要素だらけのトコロからお目当ての要素を拾い出すくらいなら、目で見てすぐに内容が判る短い記述と、外部参照を多用し双方から値を抜き出す仕組みの方が、遙かに簡単で済むように思います。

仕様書をよく熟読し、概要はオライリー XML入門でも、かなり理解は出来ます。
とにかく煩雑に考えるより、構造に注視することが何より前述のような、一種の誤解は防げるでしょう。





Powered by ScribeFire.

Monday, August 13, 2007

本当に戦後じゃないと断言できるの?




城山三郎の特集をやっていた。


太平洋戦争に至る昭和初期、外務省の官僚として活躍した広田弘毅の一生をテーマにした歴史小説の作者。広田は戦争責任について一切の自己弁護をしない。しかし極東裁判はどうもスッキリしない歴史。近衛文麿・杉山元といった重要決定に参加した指導者の中に自殺者がいるのもそうだが、いかにして戦争に向かったのかという過程が十分に明らかにされなかったということが、あまりにも重い比重となって今重くのしかかっている。同じ同盟としていた元ナチスのドイツとは大きく異なる処理である。今だ「悪事をはたらいた責任」は誰もとっていない。

真珠湾は卑怯な行為とされているが、実行に移した責任者はあくまで非開戦派の山本五十六で、開戦2年後、援護のない一式陸上攻撃機で隠密に出発、最前線ラバウルの捨て石となったブーゲンビル島上空で撃墜され戦死した。戦後レジュームの脱却とかいう言葉。レジュームって何だ?要するに戦後すぐに制定した法律は、そろそろ見直そうということを「脱却」という限定的的な表現に書き換えたもの・・である。ココが所謂野党が「憲法改正」として反対する根拠となっている。

別の意味で捉えると、実はこの日本にも言論の自由は未だにない。これはもう、戦争責任論と同じで、エライ立場になればなるほど、日本では「責任」は軽くできる構造にある。この「脱却」は是非とも必要だが、「教育」自体に成功例が見当たらないほど、戦前教育は今に生きている。今の教育は「エライ人、何か特別な地位になること、またはそれを敬うように」煽動している。これは正に戦争の影。最も重要なのはあの戦争において、裁判で死罪を言い渡されて「終結」に対し従っていたのは、誰であろう人間宣言をしたその人である。あの裁判では何も解決していない。戦争の真実は誰も語らなかったし、「死ねばいいんだろ」とはいわないまでも、「仁義」を押し通したような美徳で終始通されてしまった。私達は「戦争肯定論者の固まりのような世論」に何の疑問を持たず、「洗脳」されていたが、兵士も家族も何も報われず「戦争被害者」で締めくくられてしまった。現在はその子孫である。未だに何かひとつのヒーローを見つけヒロイズムに浸り、それを否定する者を排除しようとする傾向が残っている。しかしその裏側で「仕組み」をつくっていたことには誰も気がつかないような、巧妙な仕掛けがあった。今は、個人の意見であるはずの「テレビコメンテーターの一部のデータ」があたかも「普遍的であるかのように」取り扱われ、誤解を生じたまま「無抵抗な庶民を抹殺」してしまう。好例がオウムの松本サリン事件。犯人を誰もあの人と信じて疑わない報道で、責任をとった者は一人もいない。そして「庶民に罪はない」の決まり文句で締めくくろうと誰もが思うようになってしまっている。人生を人一人台無しにしても、世間は無視できる仕組みが生きている。戦争が残した本当の爪痕は実はココに残っている。

個人のただの吐露にすぎない「読み物」であるはずのブログも、アクセス数が世論と何か「勘違い」するのか、目的が変質し「誰もが納得する内容」が正しいと、戦前の思考に回帰している。ブログをビジネスなどは正にその典型で、「作られた口コミ」を宣伝するようなブログは星の数ほど存在して、「お見合いブログ」などという現実と垣根の高さを争っている例もある。仮想が人を殺せる様になったかのようだが、匿名であればブラウザを閉じれば何もかも終了する。現に有名であればあるほど、コメントは出来ないようになっているのは、「現実に襲われる」可能性がある立場によるからで、完全に名前を伏せればブログの価値は下がり、ヒロイズムを公表できなくなる。企業であればその所属するタレントが、匿名で書いていたらポータルサイトは何の利益も生み出せない。WEB2.0は匿名だからこそ「共有」が成立する。結局、ブログは何も生み出せはしない。成果は、凄いことをした人が公表できる場所があるからで、それに自由に意見を言えるというところで、世間とは違う「場」が生まれるが、現在の日本のネットは残念だが戦後レジュームから脱却できない戦後が息づいている。

失言が止まないのは、体質ではない。「自民党がエライ」からである。今の教育は「エライ人、何か特別な地位になること、またはそれを敬うように」煽動しているため、勉強して偉い地位になることを名誉とし、セレブとして憧れている。何でも出来るし、わがまま放題の見本がそこにあり、偉ければ消費者を騙して牛肉を偽装してもよいし、国民を偽り、公的資金を流用してもいいし、誤らなくても良い。心にあることをそのまま語って、本音を後から誤解であると主張すれば禊ぎは済んだと言い出す始末だ。誰かが辞めれば、後は何をやっても自由という”風潮”を巧妙につくった。庶民の「モラル」は単なるポーズで、公害被害はなぜだかみんなが、まき散らした方の正当性を主張することをまず、いの一番に始める。

旗という詩があり、「旗要らず 旗降るな 旗振らすな 旗たため」の言葉がある。
今年は戦後従軍した人は、皆超高齢である。本当は時間がない。

しかし、「感想」の意味での”戦争反対”の主張があっても、そこに「旗」があると危険である。皆日章旗のために死んだ。苦しんだ。耐えた。それを戦後は「偽教育」であると一言で終わらせてしまった。自決を無駄死にという人がいる。その無駄死があって私達は、海外旅行を楽しみ、その屍が今だふるさとに帰還できずにいる太平洋の上を楽しそうに横切っている。彼等は一体何のために死んだのだろうか?
全体が個人を凌駕すると、弱者を燃やす。
そして作られたヒーローを尊ぶ。

彼等が虚偽であるのなら、当時の人は皆同罪であるはずだ。
残念なことに、この国ではあの大罪の責任を誰もとっていない。

叫べ、断罪させろ!とわめくのではない。私達の信じてる「平和って良いね」などという軽い言葉が、戦車に踏みつぶされた死体の中に潜り込み、死体のフリをして生き延び、飢えた空腹を炭で満たし、仲間の死体の蛆を食べて生き延びてまで、上官の指示を守らねばならなかった人達の「生きる意味」っていったい何だったのか?という問いかけのそれが”答え”になるだろうか?誰がその後を「救って」くれるのか?それが「青春の全て」だった人に対してのなぐさみなのか?

うかつにその言葉を口にしていいのか、私は思わずためらってしまう。

日航機墜落事故の時。
阪神淡路大地震の時。
新潟県中部地震の時。
サリン事件の時。
幼児、妻殺害事件の時。
飲酒運転の過失殺人事件の時。

広島、長崎の核兵器投下の瞬間。

時が過ぎた時間の中で「平和」とただ脈絡もなく信奉していると疑わないのは何故だ?
皆、自分じゃないから・・言い換えればそれは「私は平和」という心である。
被爆者は今でも決して幸せではない。殺人の被害者も。被災者も。
”皆”という言葉は当てはめるべきではない。「個人の人権」は時に横暴であると私は思う。何か自分が他人に影響を与える者でありたいと願いがちだ。しかしそれが戦中の”正体”でもある。あの”旗”は正にその象徴である。この旗は今でもある「ブーム」「セレブ」「ホワイトカラー」名前が変っているだけで、いつでも悪夢を生み出せる仕組みが出来上がっている。それは音もなく忍び寄っている。時代が変ればいつでも「万歳」とすげ替えられるように。

戦争前、日露戦争以降ひたひたと忍び寄る黒いヒロイズムにだれも
その後に起こる「核兵器」の始まりなど予測できるわけはなかったと思う。
情報が多くても、何の足しにもならない。
戦時中は情報過多の状態であったはず。全て仕組まれたものではあったが。今そこから62年を経て、何が生まれ、何が育ち、何を生み出せたのだろうか?果たしてそれは、肥大し個性を駆逐する個人主義という怪物?

Powered by ScribeFire.



無料カウンター

Friday, August 10, 2007

タグが表現できないとスゴク見づらいですがDTDパート3

画像で表せば良いんですが、めんどくさがり屋なので。つまり前々回の駄目といっているパラメータ実体、わかりやすく言えば別名で表した名前。これを表現する利点は、まず内容によってタグの要素をかえるが、内容つまりタグに挟まれた”内容”が同じ意味である場合、わざわざ要素として指定するのは、どうかと思う。どうせ対応するタグはひとつであるし。HTMLのタグは、タグで表現する事と内容の定義が曖昧で前に書いたとおり、段落の内容が2行として小さなタイトルとして表すために、前後に改行を入れてしまっても何も違反ではない。要は順番が重要なだけだ。段落はタイトルを表しているタグの下にただ単にあれば良いだけである。だからこの点をXHTMLのルールとしてDTDまではいい。だが内容はCDATAつまり単純に文字列。内容にimg-"URI"としようが、なにも文書に変化はない。DTDはくどいがタグに挟まれた内容に言及しない。ENTITYとは実体参照ということで、タグの要素名、属性などの別名を定義する。ということは、代わりとして何を参照させるかで、多くの意味を要素に持たせることも出来る。前回、.modというDocBookの外部DTDを例に出したが、画像などはその典型である。あれほどフォーマットがあるクセに表示は単なる「画像」である。だから画像を確実に表す要素を定義すればいいというわけで、最初のパラメータ実体参照では何が出てきても良いように、画像形式を列挙してあり”|”でどれかひとつ出現すればいいとし、その実体はその後の外部解析対象外実体で、それぞれ識別子+URIで示して参照している。これをDTD側でパラメータ実体を利用し、条件セクションで有効無効を制御しているというわけ。単一な要素しか表せないが、画像に限って扱うことになっている。ということは.modを新たにつくるとカスタマイズは非常に簡単である。しかもDTDは条件で読み込ませないことも可能だ。DTDは必要最小限で済ませられる。実体参照に単一の内容を示す要素を実体に指定するべきではない。それはELEMENTで指定してることと変わりがない。だったら.modでパラメータの実体として列挙し、DTDからシステム識別子で読み込ませればDTDをプリントアウトして10数ページになるような重いモノにもならない。本来ここがDTDがDTDたらしめているところである。HTMLの拡張だろうが何だろうが、基本のタグは多くはない。体裁はCSSで外部ファイルとしてXSLTに任せればいいということ。XMLは単体では何の意味も持たない文書である。データを保持しているに過ぎない。DTDはXMLを記述する”決まり”だ。
なのに文書として意味を持たせようとDTDを使うのは馬鹿げている。

XML W3C Schemaの様に要素定義(指定ではなく)がいっぱいになるなら、そのDTDは間違いで別のスキーマをつかえ。


Powered by ScribeFire.

DTDについてその2

というわけで、つまらないDTDはさておき、伝統的にシンプルで実用的というか、シンプルだがとても応用が利くDocBookである。コメントを除くと、以下のようになっている。

&lt;!--&lt;!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2
//EN""http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"
[...]&gt;Or,if
you have a higher-level driver file that customizes DocBook,
use the FPI in the parameter entity declaration:&lt;!ENTITY % DocBookDTD PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN""http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"&gt;
%DocBookDTD;

See the documentation for detailed information on the parameter entity and module scheme used in DocBook, customizing DocBook and planning for interchange, and changes made since the last release of DocBook.--&gt;&lt;!ENTITY % dbnotn.module "INCLUDE"&gt;
&lt;![%dbnotn.module;[
&lt;!ENTITY % dbnotn PUBLIC
"-//OASIS//ENTITIES DocBook XML Notations V4.1.2//EN"
"dbnotnx.mod"&gt;
%dbnotn;
]]&gt;



&lt;!ENTITY % dbcent.module "INCLUDE"&gt;
&lt;![%dbcent.module;[
&lt;!ENTITY euro "&#x20AC;"&gt;&lt;!-- euro sign, U+20AC NEW --&gt;
&lt;!ENTITY % dbcent PUBLIC
"-//OASIS//ENTITIES DocBook XML Character Entities V4.1.2//EN"
"dbcentx.mod"&gt;
%dbcent;
]]&gt;



&lt;!ENTITY % dbpool.module "INCLUDE"&gt;
&lt;![ %dbpool.module; [
&lt;!ENTITY % dbpool PUBLIC
"-//OASIS//ELEMENTS DocBook XML Information Pool V4.1.2//EN"
"dbpoolx.mod"&gt;
%dbpool;
]]&gt;



&lt;!ENTITY % intermod.redecl.module "IGNORE"&gt;
&lt;![%intermod.redecl.module;[
&lt;!-- Defining rdbmods here makes some buggy XML parsers happy. --&gt;
&lt;!ENTITY % rdbmods ""&gt;
%rdbmods;


&lt;!ENTITY % dbhier.module "INCLUDE"&gt;
&lt;![ %dbhier.module; [
&lt;!ENTITY % dbhier PUBLIC
"-//OASIS//ELEMENTS DocBook XML Document Hierarchy V4.1.2//EN"
"dbhierx.mod"&gt;
%dbhier;
]]&gt;



&lt;!ENTITY % dbgenent.module "INCLUDE"&gt;
&lt;![ %dbgenent.module; [
&lt;!ENTITY % dbgenent PUBLIC
"-//OASIS//ENTITIES DocBook XML Additional General Entities V4.1.2//EN"
"dbgenent.mod"&gt;
%dbgenent;
]]&gt;

簡単な話、全部外部参照で済ませている。条件によって振り分けて、扱われる内容によってどう振る舞うかを決めている様子はドシロートでもわかりやすいと思う。

で、結果のXMLが

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"&gt;
&lt;article lang="en-US"&gt;&lt;sect1&gt;&lt;title&gt;これはタイトルですが本文だろうとHTMLでは関係ありません&lt;/title&gt;本文だろうとHTMLでは関係ありません&lt;sect2&gt;&lt;title&gt;これは見出しですがHTMLでは関係ありません&lt;/title&gt;見出しですがHTMLでは関係ありません&lt;orderedlist&gt;
&lt;listitem&gt;
&lt;para&gt;これは箇条書きですがHTMLのスタイル指定で、いわゆる拡張です&lt;/para&gt;
&lt;/listitem&gt;
&lt;listitem&gt;
&lt;para&gt;これは箇条書きですがHTMLのスタイル指定で、いわゆる拡張です&lt;/para&gt;
&lt;/listitem&gt;
&lt;listitem&gt;
&lt;para&gt;これは箇条書きですがHTMLのスタイル指定で、いわゆる拡張です&lt;/para&gt;
&lt;/listitem&gt;
&lt;/orderedlist&gt;
&lt;para&gt;これも本文&lt;/para&gt;
&lt;para&gt;こ&lt;/para&gt;
&lt;para&gt;れも&lt;/para&gt;
&lt;para&gt;html&lt;/para&gt;
&lt;para&gt;では本文&lt;/para&gt;
&lt;para&gt;です&lt;/para&gt;
&lt;para&gt;これが意味あると思いますか?&lt;/para&gt;&lt;/sect2&gt;&lt;/sect1&gt;&lt;/article&gt;

で、HTML

%&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"&gt;
&lt;HTML&gt;
&lt;HEAD&gt;
&lt;META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=shift_jis"&gt;
&lt;TITLE&gt;&lt;/TITLE&gt;
&lt;META NAME="GENERATOR" CONTENT="OpenOffice.org 2.2 (Win32)"&gt;
&lt;META NAME="CREATED" CONTENT="20020715;12385300"&gt;
&lt;META NAME="CHANGEDBY" CONTENT="kuniaki muroran"&gt;
&lt;META NAME="CHANGED" CONTENT="20070809;23013803"&gt;
&lt;STYLE TYPE="text/css"&gt;
&lt;!--
@page { size: 21cm 29.7cm; margin-left: 3.18cm; margin-right: 3.18cm; margin-top: 2.54cm; margin-bottom: 2.54cm }
P { margin-bottom: 0.21cm }
H1 { margin-bottom: 0.21cm }
H1.western { font-family: "Thorndale", serif; font-size: 16pt }
H1.cjk { font-family: "Andale Sans UI"; font-size: 16pt }
H1.ctl { font-family: "Tahoma"; font-size: 16pt }
H2 { margin-bottom: 0.21cm }
H2.western { font-family: "Thorndale", serif; font-size: 14pt; font-style: italic }
H2.cjk { font-family: "Andale Sans UI"; font-size: 14pt; font-style: italic }
H2.ctl { font-family: "Tahoma"; font-size: 14pt; font-style: italic }
--&gt;
&lt;/STYLE&gt;
&lt;/HEAD&gt;
&lt;BODY LANG="zxx" DIR="LTR"&gt;
&lt;H1 CLASS="cjk"&gt;これはタイトルですが本文だろうとHTMLでは関係ありません&lt;/H1&gt;
&lt;H2 CLASS="cjk"&gt;これは見出しですがHTMLでは関係ありません&lt;/H2&gt;
&lt;UL&gt;
&lt;LI&gt;&lt;P STYLE="margin-bottom: 0cm"&gt;これは箇条書きですがHTMLのスタイル指定で、いわゆる拡張です&lt;/P&gt;
&lt;LI&gt;&lt;P STYLE="margin-bottom: 0cm"&gt;これは箇条書きですがHTMLのスタイル指定で、いわゆる拡張です&lt;/P&gt;
&lt;LI&gt;&lt;P STYLE="margin-bottom: 0cm"&gt;これは箇条書きですがHTMLのスタイル指定で、いわゆる拡張です&lt;/P&gt;
&lt;/UL&gt;
&lt;P&gt;これも本文&lt;/P&gt;
&lt;P&gt;こ&lt;/P&gt;
&lt;P&gt;れも&lt;/P&gt;
&lt;P&gt;html&lt;/P&gt;
&lt;P&gt;では本文&lt;/P&gt;
&lt;P&gt;です&lt;/P&gt;
&lt;P&gt;これが意味あると思いますか?&lt;/P&gt;
&lt;/BODY&gt;
&lt;/HTML&gt;%

アプリはopen office.orgである。実際XMLからは、まんまhtml化しようとしても、h1とかは指定しないと駄目だ。というかそこまでDTDは関与すべきではない。

頭の要素もパラメータ参照で、dbと名前から察するにデータベースからELEMENTで前回のようにどれかひとつが出るよう実体を列挙してパラメータとし、実体名としていることが判る。
XMLは書式に関与してはならず、構造として保持しているということが、DTDが主眼としているゆえんである。ちなみに文中の&gt;などは正規表現である。ブログではXMLをそのままでは表示できんからね。構造が判りやすいことにDTDもなっていることが、コメントも生きてくるというモノ。実体参照と要素の数が同じなのは馬鹿馬鹿しいのが普通である。

では一番上の.modを見てみよう。
例のごとくコメント抜きだ。&lt;!--  &lt;!ENTITY % dbnotn PUBLIC
"-//OASIS//ENTITIES DocBook XML Notations V4.1.2//EN"
"dbnotnx.mod"&gt;
%dbnotn;
--&gt;これもコメントだが、まあ一応そのままにしておいた。

&lt;!ENTITY % local.notation.class ""&gt;
&lt;!ENTITY % notation.class
"BMP| CGM-CHAR | CGM-BINARY | CGM-CLEAR | DITROFF | DVI
| EPS | EQN | FAX | GIF | GIF87a | GIF89a
| JPG | JPEG | IGES | PCX
| PIC | PNG | PS | SGML | TBL | TEX | TIFF | WMF | WPG
| linespecific
%local.notation.class;"&gt;

&lt;!NOTATION BMP PUBLIC
"+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION Microsoft Windows bitmap//EN"&gt;
&lt;!NOTATION CGM-CHAR PUBLIC "ISO 8632/2//NOTATION Character encoding//EN"&gt;
&lt;!NOTATION CGM-BINARY PUBLIC "ISO 8632/3//NOTATION Binary encoding//EN"&gt;
&lt;!NOTATION CGM-CLEAR PUBLIC "ISO 8632/4//NOTATION Clear text encoding//EN"&gt;
&lt;!NOTATION DITROFF SYSTEM "DITROFF"&gt;
&lt;!NOTATION DVI SYSTEM "DVI"&gt;
&lt;!NOTATION EPS PUBLIC
"+//ISBN 0-201-18127-4::Adobe//NOTATION PostScript Language Ref. Manual//EN"&gt;
&lt;!NOTATION EQN SYSTEM "EQN"&gt;
&lt;!NOTATION FAX PUBLIC
"-//USA-DOD//NOTATION CCITT Group 4 Facsimile Type 1 Untiled Raster//EN"&gt;
&lt;!NOTATION GIF SYSTEM "GIF"&gt;
&lt;!NOTATION GIF87a PUBLIC
"-//CompuServe//NOTATION Graphics Interchange Format 87a//EN"&gt;

&lt;!NOTATION GIF89a PUBLIC
"-//CompuServe//NOTATION Graphics Interchange Format 89a//EN"&gt;
&lt;!NOTATION JPG SYSTEM "JPG"&gt;
&lt;!NOTATION JPEG SYSTEM "JPG"&gt;
&lt;!NOTATION IGES PUBLIC
"-//USA-DOD//NOTATION (ASME/ANSI Y14.26M-1987) Initial Graphics Exchange Specification//EN"&gt;
&lt;!NOTATION PCX PUBLIC
"+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION ZSoft PCX bitmap//EN"&gt;
&lt;!NOTATION PIC SYSTEM "PIC"&gt;
&lt;!NOTATION PNG SYSTEM "http://www.w3.org/TR/REC-png"&gt;
&lt;!NOTATION PS SYSTEM "PS"&gt;
&lt;!NOTATION SGML PUBLIC
"ISO 8879:1986//NOTATION Standard Generalized Markup Language//EN"&gt;
&lt;!NOTATION TBL SYSTEM "TBL"&gt;
&lt;!NOTATION TEX PUBLIC
"+//ISBN 0-201-13448-9::Knuth//NOTATION The TeXbook//EN"&gt;
&lt;!NOTATION TIFF SYSTEM "TIFF"&gt;
&lt;!NOTATION WMF PUBLIC
"+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION Microsoft Windows Metafile//EN"&gt;
&lt;!NOTATION WPG SYSTEM "WPG"&gt; &lt;!--WordPerfect Graphic format--&gt;
&lt;!NOTATION linespecific SYSTEM "linespecific"&gt;

思った通りパラメータ実体で、実体を列挙してある。その後外部解析対象外実体つまり外部にあるルールを記述した文書にある実体を公開識別子、とシステム識別子で参照している。最初のパラメータ実体には実体がないことに注意しよう。システム識別子にもURIがあるが、公式なので動くこともないということである。見りゃわかるが、画像に関する扱いで要素にそいつが現れた場合の対応として、何を”あて”にしたらいいのか記述してあるわけだ。
要素に意味を持たせたけりゃどういう事をすればいいのか、実は至極簡単ですよね。Microsoft社のWindowsが標準でサポートしているベクター画像のファイル形式。WMFとタグに書いても意味はないが、参照は+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION Microsoft Windows Metafile//ENとしてしてあるのでWMFとは画像ファイル形式であると。ユーザーがウィンドウズ100%なら、Internet Explorerでもいいけど。DTDはウダウダ考える必要の無いようににするべきであると思いますねぇ。

Powered by ScribeFire.



無料カウンター

Thursday, August 09, 2007

DTDについて

前回、DTDはライセンスの記述程度なら良いんじゃないかと書きましたが、それというのもDTDは、スキーマの中でも、要素の出現回数だとか、要素定義を外部に参照する程度で柔軟性に乏しい。しかし共通の文書などは出力するのにたいしたスタイルシートは用意したくないので、ドキュメントとしてなら要素の回数や属性でページも管理しやすいだろうと・・。で、実際XHTMLのDTDを見たが、&lt;!ENTITY % 実体名 ”実体”>の中で実体に文字列が書いてあるモノがズラズラ・・。???意味無いんじゃないかなと正直思いました。うーん・・CDATAってねぇ。内容としては要素の間には冗長な文字列が来るのがHTMLだからかまわないんだろうけど、
!--================== Imported Names ====================================--&gt;

%&lt;!ENTITY % ContentType "CDATA"&gt;
&lt;!-- media type, as per [RFC2045] --&gt;

&lt;!ENTITY % ContentTypes "CDATA"&gt;
&lt;!-- comma-separated list of media types, as per [RFC2045] --&gt;

&lt;!ENTITY % Charset "CDATA"&gt;
&lt;!-- a character encoding, as per [RFC2045] --&gt;

&lt;!ENTITY % Charsets "CDATA"&gt;
&lt;!-- a space separated list of character encodings, as per [RFC2045] --&gt;

&lt;!ENTITY % LanguageCode "NMTOKEN"&gt;
&lt;!-- a language code, as per [RFC3066] --&gt;

&lt;!ENTITY % Character "CDATA"&gt;
&lt;!-- a single character, as per section 2.2 of [XML] --&gt;

&lt;!ENTITY % Number "CDATA"&gt;
&lt;!-- one or more digits --&gt;

&lt;!ENTITY % LinkTypes "CDATA"&gt;
&lt;!-- space-separated list of link types --&gt;

&lt;!ENTITY % MediaDesc "CDATA"&gt;
&lt;!-- single or comma-separated list of media descriptors --&gt;

&lt;!ENTITY % URI "CDATA"&gt;
&lt;!-- a Uniform Resource Identifier, see [RFC2396] --&gt;%
とこの辺りを見るにつけ、要素に対して実体が共通なのばっかしってやっぱりおかしい。
パラメータで指定する内容じゃない。

DTDは内容には一切関知しない仕様なのにこれじゃアベコベじゃねえか?
<!ELEMENT 要素 パラメータ>として要素指定でやればいいのに。HTMLの変換はdtdの仕事じゃない。ウーン何を目的にxmlを作ろうとしてんだか・・。

XMLをXHTMLとして利用するのに限定しようというのなら、タグがクソいっぱいあるんだから、全部外部で要素として、.modでDTDで呼び出せばいいことで、頭1行で済むハナシじゃねえのかな?これじゃ実際DTDがクソ重いだけジャン。

なんで
&lt;!ENTITY % 実体名
              |実体

              |実体
        
              |実体 


として出力の方はどうせインラインもクソもねえxhtmlだし。

パラメータ実体参照なのに実体が共通でしかも単なる文字列なら、ELEMENTとして外部.modとしてもまったくおなじことだわな。

XHTMLだけの仕様に限っての定義でしょうけど、これじゃカスタマイズもクソもないね。無駄じゃないけど凡庸じゃない上に転用が無理。xmlとしてこれじゃあんまりですな。

DTDは正直言って内容ではなくあくまでも”要素”の指定だけに限った仕様です。
要素の数が多いのに、内容が共通なら指定する意味はありません。当たり前ですよ。要素の内容は文字列がデフォルトですから。混在は一切出来ません。

DTDはルールの規定を定めるモノですが、回数とか出現する順番ですとか、ある条件で出現する要素を決めるとかそういったことしか出来ません。だから単なる文書は良いんですよ。
例えばHTMLの<p>というのはありますが、これは別にその内容がタイトルだろうが、本文だろうが関係ありません。普通なら200字のタイトルとか、一文字の段落なんてありえませんよね?でも拡張に過ぎないXHTMLは結局その結果として、タグの内容に関しては何の制約もありません。順番だけ。
だから、PDFで書式を定めようとか、ある会計フォーマットのみで済むような純粋なドキュメント、それも文字だけの”読み物”なら簡単にxmlからXSLTで加工できます。だから、DTDはXMLが参照するモノではあるけれども、(言い換えればそういうことと同じです。XMLは共通の書式を制定する仕組みですから)複雑で冗長なら、他のスキーマの方が実用的なのはいうまでもありません。
常識で済むようなハナシは定義するだけ無駄だ。ということ。モジュール化すればいいだけなら、実体参照乱用は単に文書を重くするだけです。
悪しき一例として上記をあげました。ホントに何故、.modをつかわんのか不思議です。

何かを参照したんでしょうが、オリジナルをかなりねじ曲げて解釈しています。
逆に考えることはそんなに難しいことでしょうか? 

Powered by ScribeFire.

Thursday, August 02, 2007

もの悲しい現実。VRMLの未来を垣間見た。

スキーマについて書こうとおもって、RELAX NG(スキーマ言語のひとつ)の日本語ポータルを見たら、既にそこは乾涸らびてカビがはえた状態だった。そもそもXMLの可用性が今ひとつはっきりしていないのに、妥当かどうかの検証の仕組みを整理するというのが間違いかも知れない。で、少し前に話題になったらしいVRMLは更に酷い状況だ。3Dゲームの今更ながらつたないポリゴン画面を見て心躍らせる研究者はいないだろう。専用ビューワが必要なんてこれ以上私になをさせたいのか?と尋ねたくもなる。魅力は感じない。XMLの活用としてはデータとしての扱いをより幅広く活用できるよう、文書を統一しないまでもある一意のルールに則って記述すること。それが根本である。目的は綺麗な文書を書くことではない。あくまでもその文書の利用において真価を発揮するモノであって、XML自体はデータの集まりでしかない。スキーマについてかこうとおもったら、いきなり出鼻をくじかれた感がある。まあ、DTDをうまくプログラムすれば結局あーだこーだ、ルールに縛られる必要もない。DTDをRELAX NGに変換できたからといって、取引先に入れろと頼めるわけもない。ハッキリ言って利点がないので「廃れて当然である」。自分だけ判る文章を作っても理解は得られない。残念だが学者はココが頭が固い。「利用」されなければいくら良い技術であろうとも価値はない。で、肝心のスキーマだが、やはり確実で柔軟なDTDが一番取っつきやすい。そもそも標準的な仕組みとしてある程度動作に信頼がある。こんなシチュエーションに出くわした。PPTP、つまりVPNネットワークを組んでいたときである。回線にも問題はないし、ゲートウェイもプロトコルが通過できることを確認したが、繋がらない。どうやらネットワークアプリの問題らしいと判った。しかしそれはUNIXを基本にしたMAC。Perfarenceをテキストエディタでいじっていたときのこと。そういやアレは紛れもなくXML。宣言こそ省略してはあったが・・。で、UNIXでアプリにデーターを格納するとき、柔軟に細かく制御したい場面が来たとき、やたらと設定ファイルをviで開き、パラメーターを入れるのが死ぬほど億劫になったのを思い出した。大体同じ値が入るのに、扱う書式がバラバラだからいちいち手作業なのはなんとかならんか?こんなのに信憑性もないOSのバージョンが違えば動作がどうだかのスクリプトなんてのに、任せて良いのかと疑問を抱いた。
で、ちょろちょろApacheを2ついれローカルとWWWとして切り分けていたMACはしばらく放っておいた。XMLでフロー(データのセクション)ごとにエディタで開いて変更して、あとでそれこそスクリプトで処理してアプリで格納すれば楽じゃないかと思ったわけ。ということは、エディタは開発しなくて良いから、そこそこ良い文書に専念してうまくXSLでテンプレートをつくればいいと思った。DTDは、この開発の著作権、版権みたいなモノ。エディタは誰でも扱えるし、何より操作が楽だからと思ってたら、Frickerが既にそのようなサービスをやっている。だろね。じゃあ・・というわけでもないが、データベースにもちっと人に優しいインターフェイスはないのかと思ってたら、XMLが使えそうである。簡単に説明すれば、データ、それを操作、加工等に統一した書式とルールを与えようというのがXMLである。データ抽出、追加、削除はプログラムに任せようという仕様である。(というかそれが一般的だ)JAVAを利用した方法が書かれた本が多い。でも本当は計算より抽出、追加、削除が一番使うことだろう。年間通じてそう何回も棚卸しをするのじゃなければ。データー入力に無効な数字をエラーとして吐き出すとき、その文書の妥当性が必要となるこれが、DTDである。売り上げの入れるべきトコロに名前を書いて保存したら「駄目ですよ」と。顧客データを切り取ろうとしたら、そのままでは違反となって保存できませんとエラーが出れば、危険は回避できそうな気がする。あまり複雑な処理系を選ぶのは賢明ではない。ココはインタプリタが良いでしょうね。MACでは、階層を表示し値を変更できるエディタがある。(Property List Editor)コレもまたMAC限定ではあるが、XMLエディタとして機能する。作成にはopen officeであれば、実際XMLとJAVAで構成した文書作成系、しかも妥当なXML文書を生成するので、加工はし易い。DOMはNVUでも実装して、外部からインポート出来るようになっている。開発環境は手軽だ。ここらでXMLというのが、処理系というよりインターフェイスとしてのアプリとの中間に位置しているということがお判りだろうか?次回は実際の文書について言及しよう。DTDはそれからの方が理解しやすいからだ。


Powered by ScribeFire.