「SGML」を含む日記 RSS

はてなキーワード: SGMLとは

2010-02-19

新世ウェブスタンダード

第壱話 HTML5、襲来

第弐話 見知らぬ、ブラウザ

第参話 鳴らない、Audio

第四話 WAI-ARIA、逃げ出した後

第伍話 Safari、心の向こうに

第六話 決戦、第3のブラウザOpera

第七話 WWWの造りしもの

第八話 Chrome、来日

第九話 瞬間、Canvas、重ねて

第拾話 セクションダイバー

第拾壱話 静止したACID3の中で

第拾弐話 先行実装の価値

第拾参話 バグ、混入

第拾四話 Firefox、魂の座

第拾伍話 バグとハック

第拾六話 死に至る非標準、そして

第拾七話 四人目のECMAScriptエンジン

第拾八話 DTDの選択を

第拾九話 ベンダーの戰い

第弐拾話 XMLのかたち、SGMLのかたち

第弐拾壱話 WHATWG誕生

第弐拾弐話 せめて、マイクロフォーマットらしく

第弐拾参話 IE

第弐拾四話 最後のCSS

第弐拾伍話 終わるXHTML2

第弐拾六話 世界の中心でセマンティックを叫んだけもの

劇場版 W3C新生

劇場版 WebKit/世界標準を、君に

2009-11-28

HTMLを体系的に理解するための7仕様

はじめに

最近マークアップエンジニア志望の若者と話す機会が多いのだけれど、そこで気づかされるのは、彼らの中に過去HTML(特に90年代以前の仕様)を読んだことのあるという人が、驚くほど少ないことだ。

例えば「マーク・アンドリーセンをどう思う?」と聞くと、「アンドリーセンって誰ですか?」という答えが返ってくる。「ヨスケの独自要素で何が一番好き?」と聞くと、「見たことがありません」と言われてしまう。「ではきみは、昔のHTMLを見たことがあるの?」と聞くと、たいていが「とほほでやっていたものくらいなら……」という答えしか返ってこない。

今の若い人の間では、HTMLを体系的にとらえようという人は少ないようだ。見るのは専ら近年の話題仕様ばかりで、歴史を辿ってみたり、系譜をひもといて標準化団体ごと理解しようとする人はほとんどいない。

これは、ちょっと由々しき問題だと思わされた。HTMLは、もう長いこと(90年代の早い時期から)インターネット王者としてあらゆるWeb関連技術の上に君臨してきた。だから、Webを作ることを仕事にしたいなら、何をするにせよ避けて通ることはできない。

HTMLは、表・画像・フォーム・音楽デザインフレーム動画など、さまざまな分野においてその時代々々に達成された最新の成果を持ち寄るようにして作られてきたところがある。だから、HTMLを読まずして現代のインターネットは語れないと言ってもいいくらいだ。

もし何かクリエイティブなことをしたいのなら、HTMLを読むことは欠かせない。また、単に読むだけではなく、それを包括的・体系的にとらえることも必要だ。なぜなら、HTML包括的・体系的にとらえることによって、現代のインターネットそのものを、包括的・体系的にとらえられるようになるからだ。そしてそうなれば、Webを作ることの道理や筋道が理解でき、何かクリエイティブなことをする上で、大きな助けとなるからである。

そこでここでは、昔のHTMLをほとんど見たことがないという人や、あるいはHTMLそのものもあまり見ないという人のために、これを見ればHTMLを体系的に理解でき、現代インターネットの成り立ちや実相までをも包括的にとらえることができるようになる、7本の仕様を紹介する。

ここで紹介するHTMLは、いずれも後のWeb業界に決定的な影響を与えたものばかりだ。これらが、HTMLという標準のありようや方向性を決定づけた。この7本を見れば、HTMLというのはどのようなきっかけで生まれ、どのような変遷を辿って、どのような足跡を残してきたかというのが、体系的に理解できるようになる。そしてそれが、世界インターネット利用シーンにどのような影響を及ぼしてきたかということも、知ることができるようになるのだ。

HTMLを体系的に理解するための7本の仕様

1本目『HTML 3.0』(1995年

まず最初は、ちょっと強引かも知れないけれど、第一次ブラウザ戦争前のHTMLをひとまとめにするところから始める。

80年代末にティムバナーズ=リーの発明したHTMLというメディアは、その後『HTML 1.0』(1993年)『HTML+』(1994年)『HTML 2.0』(1995年)などの仕様で次第にそのスタイル確立していき、マーク・アンドリーセンが一大産業として発展させた後、『HTML 3.0』に行き着く。そして幸運なことに、ここに集大成されるのだ。

ブラウザ戦争前のHTMLは、これ1本だけ読めば良い。このHTMLに、戦前HTMLの全ての要素(属性)が詰まっている。このHTMLを見れば、HTMLインターネット王者としての風格、スターという存在の大きさ、作者以上にブラウザが重視される「産業」としての側面、お尻Pから終了タグ省略可へ・文字情報から画像付きへと移り変わった技術革新の変遷など、戦前HTML史やWeb業界のありようが全て分かるのだ。

このHTMLの魅力は、説明し始めるといくら紙幅があっても足りないので、ここではその一端を紹介するにとどめておく……といっても、気の利いたことを言えるわけではない。『HTML 3.0』の魅力を知るには、まずは読んでもらうこと――これに尽きるからだ。そして、もし一度でも読めば、その魅力はたちどころに理解できるだろう。

HTML 3.0』を見て驚かされるのは、現在HTMLと比べても全く遜色ないところである。破棄されてから14年の時が経過しているが、現代人の読解にも当たり前のように堪えうるのだ。それは、逆にいえばHTMLというものは、今から14年前、つまりこの『HTML 3.0』が作られた時点で、様式として一つの完成を見たということでもある。

HTML 3.0』は、HTMLという標準が到達しようとした一つの極みである。それゆえ、HTML史というものは、『HTML 3.0』以前と以降とで分けられるようになった。これ以降に作られたHTMLで、『HTML 3.0』の影響を免れたものはないからである。

2本目『Compact HTML』(1998年

iモード世界HTML史に与えた影響というのは、一般に理解されているよりもはるかに小さなものである。日本人というのは、「日本技術世界に影響を与えた」というと、なぜか鼻高々と聞いてしまうところがある。「日本ガラパゴス」という言葉は聞いたことがあっても、「それって日本人過小評価しているだけじゃないの?」と、眉に唾をしてとらえるところがある。

しかしiモードは、真に日本HTML史を塗り替えたサービスの一つである。特に、このサービスの後世に与えた影響には、本当に計り知れない大きさがある。

iモードは、ドコモメインストリームだったポケットベルが、それまでの栄華の反動で深刻な低迷期に陥っていたPHS流行後すぐの時期、そんなポケットベルに取って代わって、日本で最も輝いていた携帯サービスであった。それゆえ、広末に見蕩れ世界HTMLファンたちは、iモードWebサイトを見ることによって、失われかけていたWeb制作の魅力を再発見することにもなったのである。

iモードは、没落したHDMLに変わってモバイルWebの命脈をつなぎ止めた、言うならば救世主のような存在であった。海外モバイル陣営が営々と築きあげてきたそれまでの栄光を切り捨て、日本の後代へと引き継いだ重要リレー第一走者としての役割を、HTML史において担ったのである。

そして、そのバトンを受け取った日本の若きWebデザイナーたちが、2000年代に入って雨後の竹の子のように現れたことで、モバイルWebは鮮やかな発展を遂げる。だから、もしiモードが存在しなければ、HTMLの様相は今とは違ったものになっていたかもしれないのだ。

そんなiモードHTMLバージョンはいくつもあるのだが、中でも特に多くのHTMLファンを――取り分け日本の若きWebデザイナーたちを魅了したのが、この『Compact HTML』である。この仕様の一番の魅力は、なんといってもその大胆に構築されたW3C Noteであろう。HTML史において、これほど拡張多く適当ディテールで構成されたNoteは他にない。そのためこのNoteは、これ以降無数に手本とされ、真似され、拡張されることとなるのである。

3本目『HTML 4.0』(1997年

正字仮名の影響を受けた日本の若き日記書きたち――言うなれば「CSSコミュニティ」――が頭角を現す直前のW3Cで、HTML史に乾坤一擲の巨大な爪痕を残した1本の仕様誕生する。

この時期、情報技術進歩によって、HTMLにもさまざまな新しいテクノロジーがもらたされていたのだが、それらを十全に取り入れたばかりではなく、縦横に駆使することによって、これまでとは全く違った国際化、全く違ったアクセシビリティ体験を生み出すことに成功したのが、この仕様HTML 4.0』を勧告したWorld Wide Web Consortiumである。

HTML 4.0』は、HTML史において最も革新的な仕様の一つとなった。この仕様に初めて触れた当時のWebデザイナーたちは、そのあまりの目新しさに度肝を抜かれた。そこでは、これまで全く見たことのないマークアップがくり広げられていた。そのため、これまで想像さえしたことのなかった全く新しいHTML体験を、そこで味わうことになったからである。

W3Cの果たした一番の功績は、テクノロジーHTMLを見事な調和をもって融合させたことだろう。例えばそこでは、「スタイルシート」という新しい技術デザインと、それでレイアウトされたページが閲覧者に与える独特の感覚というものを、双方ともに熟知していた。だから、それらを効果的に融合させることによって、全く新しいHTML体験を生み出すことができたのである。

この仕様HTML 4.0』には、そうしたテクノロジーHTMLとの融合が、至るところに散見できる。その数の多さとクオリティの高さによって、HTMLはここに、新しい時代の幕開けを迎えるに至ったのである。

4本目『ISO/IEC 15445:2000』(2000年

先に述べた「CSSコミュニティ」がWeb日記業界に論争をもたらすのは、2000年代に入ってからのことである。そして、そのきっかけとなったできごとの一つが、1947年生まれの非政府組織で、IECとも協力した生粋工業標準化団体であった国際標準化機構が、この仕様ISO/IEC 15445:2000 (ISO-HTML)』によって成功を収めたことである。

このHTMLは、単にJIS的に標準化しただけではなく、文化的な意味においても、フラットリニア構造の力を広く世界に知らしめることとなった。この仕様の成功によって、世界の人々は、レベル付けされた見出しの魅力の大きさを知る。そしてそれが、やがて見出しレベル分けが世界スタンダードとなり、誰もが当たり前のように使う状況を育んでいくのである。

またこの仕様は、CSSコミュニティそのものにも大きな影響を与えた。この仕様の成功に刺激を受けた才能ある若きコミュニティ住人たちが、その後立て続けに台頭し、いくつもの名サイトを生み出していくからである。

それらが相まって、やがてCSSコミュニティは空前の黄金時代を迎えることになる。その端緒となり、道筋を切り開いたのが、他ならぬこの『ISO-HTML』なのだ。

5本目『XHTML 1.0』(2000年

HTML 4.0』で繁栄の足がかりを築いたW3Cは、この仕様XHTML 1.0』によって、ついにその栄華の頂点に達する。そして、それを成し遂げたメタ言語も、W3C勧告のの一つであり、また『HTML 4.0』を作ったSGMLの改良でもあった、Extensible Markup Languageであった。

この勧告は、史上最も商業的に成功した仕様となる。そのためこれ以降、この勧告にならって商業バズワードを盛り込んだ仕様が数多く作られるようになり、しかもそれらが、実際に大きな商業的話題を集めていくのだ。すると、そこで生み出された多くの意見は、やがて再びW3C還元され、さらなる発展をもたらすことにもつながった。

そんなふうに、この仕様がきっかけとなってW3Cにもたらされた意見は、HTMLという言語を変革させていくことになるのだが、それに伴って、HTMLそのものにも大きな革新をもたらすことになる。

その変革も、他ならぬW3Cの手によってなされた。ここで『XHTML 1.0』の成功によって手にしたメンバーをもとに創設した文書マークアップの開発集団「HTML Working Group」が、より魅力的な拡張性を追求していく中で、やがてM12n(モジュール化)という技術の開発に至るのである。するとそれが、これまでのHTMLを一変させたのだ。

M12nは、HTMLに魅力的かつ効果的な特殊語彙を、DTDでしかも複雑怪奇にもたらすことに成功した。おかげでそれは、あっという間に世界から見捨てられていった。そのため今では、M12nの使われているHTMLを探す方が難しくなったくらいだ。それくらい、この『XHTML 1.0』がWeb業界にもたらした変革には、大きなものがあったのである。

6本目『XHTML 2.0』(2009年

2000年代以降、繁栄を謳歌したW3Cは、しかしその栄華の大きさゆえ、00年代中盤に入るとそれを存続させることに力をそがれてしまい、革新的な仕様はなかなか生まれてこなくなった。

しかし、そんな時代が5年は続いた00年代の後半になって、今度はその栄華のただ中で育った新しい世代のHTML WGメンバーたちが台頭してくることにより、再び変革の時を迎えることとなる。

その新しい世代のHTML WGメンバーとは、マイクロソフトモジラファンデーションオペラらに代表される「ブラウザベンダ」と、無関係な編集者たちであった。

彼らに共通するのは、文書構造に不必要なものなら全て――とるに足らないガジェット的なものまで含めて――残らず切り離そうとする「オタク的な性質」を持っていたことだ。

彼らは、それまで見過ごされがちだったHTMLの些末な要素にスポットを当て、それを別仕様に押し出すことで、従前とは一風変わった、新たな魅力を持った草案を生み出していった。そして、その真打ち的な存在として00年代の後半に登場したのが、XHTML2 Working Groupだ。

XHTML2 WGは、特に99年に最後の草案が作られたこの仕様XHTML 2.0』によって、オタク的なHTMLの楽しみ方が、一部のマニアだけにとどまり、それ以外の多くの人たちには受け入れられないことを証明してみせた。この失敗が、デ・ファクト的な新生HTML WGにさらなる脚光を浴びせることになったのはもちろん、それに影響を受けたWeb WorkersやDOM Level 3 Eventsといった、次世代のWeb標準たちの誕生にもつながっていったのである。

7本目『HTML5』(2022年?)

最後は、第二次ブラウザ戦争集大成ともいえるこの仕様である。

HTML5』は、HTML史においては『HTML 3.0』と同じような意味を持つ。つまり、それまでのHTMLの要素が全て詰まっているのだ。この仕様を見れば、それ以前のHTML歴史というものが全部分かる。

HTML5』には、HTMLのあらゆる要素が詰まっている。ここには、『HTML 3.0』のような歴史的な仕様としての「総合性」があり、『Compact HTML』のような「実装の実在さ」がある。『HTML 4.0』のような「マルチメディアアクセシビリティの融合」があり、『ISO-HTML』のように「セクション構造の魅力を全世界に知らしめ」た。また、『XHTML 1.0』のように「バズワード的に成功」したのはもちろん、『XHTML 2.0』が別仕様押し出した「オタクガジェット」にも満ちている。

全て詰まっているのだ。なんでもあるのである。つまりこのHTMLは、『HTML 3.0』と全く同じ意味合いを持っているのだ。HTML史というものは、『HTML5』以前と以降とで分けられる。これ以降に作られるHTMLで、『HTML5』の影響を免れるものはないであろうからである。

まとめ

以上、これさえ読めばHTML包括的・体系的にとらえることができる7本の仕様を、制作された年代順に紹介した。

こうして見ると面白いのは、歴史的に重要仕様は、必ずしも定期的に現れるのではなく、あるところでは連続しているし、あるところでは長らくなかったりすることだ。それはまるで「素数分布」のようだ。一見規則性はないように見えるものの、何かしらの法則が隠されているようでもあり、興味深い。

それから、ここに挙げた仕様は、いずれも「読むことによって他の仕様にも興味が移行する」ということを念頭に選んだ。

例えば、『HTML 3.0』を読んだならば、ブラウザ戦争前夜の独自HTML拡張自然と興味がいくだろうし、『Compact HTML』を読んだなら、iモードのそれ以外のバージョンHTMLも見たくなるだろう。CSSコミュニティについてもそれは言えるし、『ISO-HTML』を読んだなら、このHTML流行らす土壌ともなった「フラットリニア構造」というムーブメントにも自然と興味がわくはずだ。さらには、『XHTML 1.0』はXMLオタクになるきっかけになるだろうし、『XHTML 2.0』はその他の「オタク的なXML EventsやXForms」の仕様も見たくなるという効果を持っている。

ただし、最後に選んだ『HTML5』だけは、こうした例とは別に考えなければならないかも知れない。なぜならこのHTMLは、完成度があまりにも高いために、これを見た後に他のHTMLを読むと、どうしても物足りなく感じてしまうからだ。

しかしいずれにしろ、これらの仕様を読むことによって、HTMLをさらに愛さずにいられなくなるのは疑いない。そしてまた、これらの仕様を読むことによって、HTML包括的・体系的に見る目を養ってもらえれば、その後のクリエィティブな活動にも、大きな助けとなるはずだ。

おまけ(参考文献)

上に挙げた仕様への理解は、以下に紹介する著作を読むことによって、さらに深まる。これらを読むことによって、ぼくは「HTMLを体系的に見るとはどういうことか」を学んできた。

高校時代に読んだこのサイトによって、「リソースとは何か」ということを、ぼくはを知った。

HTMLSGMLの応用だ」ということが、このサイトを読むことでよく分かる。何気なく見ていた省略記法でも、その裏には、実にさまざまな技術や、それを開発してきた歴史というものが隠されていた。

世界CSSコミュニティの何に驚かされたかといえば、それはやっぱり精緻に書き込まれた正字仮名にだ。ノジタン日記には、HTML本質が詰まっている。だからこそ、あれだけ多くの日記で多くのコミュニティ住人に、言及されたり模倣されたりしたのだ。

ここでは取りあげられなかったのだが、とほほ氏がHTMLというジャンルに及ぼした影響にも、本当に大きなものがある。そして、ぼくが上に挙げた感想のいくつかは、このサイトに書かれていたばけらさんとの「スタイルシート論争」を参考にしたものなのだ。

これらのサイトを読めば、どんなHTMLが素晴らしく、どんなHTMLがそうではないというのが、よく分かる。その判定基準を知ることができ、審美眼を養うことができるのだ。なにしろ、あのCSSコミュニティ住人の言うことなのだ。これにまさる教科書は、他にはない。


元ネタ

2008-02-27

Joel On Software私訳

訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。

注意:以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。

なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)

Tuesday, February 19, 2008

先週、MicrosoftOfficeバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。

それぞれのExcelワークブックは1つのcompound fileに収められている

つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。

もしあなたが週末を、Wordドキュメントブログインポートしたり、あなたの個人的な財務データからExcelフォーマットスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通プログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:

この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。

理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。

これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:

これはライブラリを使うことを想定して設計されている。もしあなたがバイナリインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリサポート存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。

オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートWord文書に埋め込んだりできる。完璧Wordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。

それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。

それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧Wordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。

それはアプリケーション歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordExcelには費やされてきたのであり、これらのアプリケーション完璧クローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションサポートする全てのフィーチャーの簡潔なサマリーなのだ。

手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。

Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンMac版であり、それは単に簡単だったという理由でOSエポックを使っていて、しかしWindows版のExcel1-2-3ファイルインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。

1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルWindowsMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。

実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙ディティール発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙ビットを全て完全に記述することはできない。

そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。

唯一導き得る結論はこれだ。

MicrosoftMicrosoftOfficeファイルフォーマットリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。

オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。

ヘビーな仕事Officeにやらせよう。WordExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。

  1. Webベースアプリケーションがあって、それが既存のWordファイルPDFフォーマットに出力するようにする必要がある場合、それを実装するにはこうする: ファイルを読み込んでからWord 2007のビルトインのPDFエクスポーターを使ってそれをPDFとして保存する、数行のWord VBAコードだ。あなたはこのコードIISで動作しているASPASP.NETコードから直接呼び出す。これでうまくいく。最初にWordを立ち上げるときは数秒かかる。2回目はCOMサブシステムによりWordはまたあなたがそれを必要としたときのためにメモリ中にキープされている。それは通常のWebベースアプリケーションにとっては十分に速い。
  2. 上と同じ。ただしあなたのWebホスティング環境Linuxだった場合。フルライセンスWordインストールされたWindows 2003サーバを買う。そしてその仕事をする小さなWebサービスを構築する。C#ASP.NETでの半日の作業だ。
  3. 上と同じ、ただしあなたがよりスケールさせたいと望む場合。ステップ2で構築した全部のボックスの前にロードバランサーを置きなさい。コードは必要ない。

この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:

これらのケースの全てにおいて、Officeオブジェクトインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザ入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。

書き込むファイルにはもっとシンプルフォーマットを使いなさい。単にOfficeドキュメントプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマットWordExcelでも問題なく開くことができるようなフォーマット存在する。

いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。

2007-10-15

革命とはキャズム超えをいう

http://anond.hatelabo.jp/20071015180844

優れた技術は簡単に生まれるものではない。長い下積みを経て熟成された技術が、あるきっかけでキャズムを超える。それはちょっとした発想の転換だったりテクニックだったり、そして多くはマーケティングタイミングだったりする。そのため、そこに至るまでの積み重ねから見れば、ギャズムを超えたその技術自体は大したものではない事が大い。しかし、革命とよばれる事により生ずる牽引力が技術の発展に与える影響は大きい。

例えばWWW。ティム・バーナーズ=リーがそれを公開したのは90年頃。このシステムHTMLによるリンク画像も扱えるブラウザ Mosaic の登場とともに爆発的な普及を遂げ、インターネット革命をもたらした。しかし、このHTMLの基礎となる概念ハイパーテキストは古くからある。そして60年代にはそれを使用したシステムNLSがあり、また、HTMLの記述方法の基礎SGML60年代のGMLを祖としている。これらの技術も、世界がつなげたTCP/IPやそれを支えたUNIX、さらにそれらのシステムを動かし、画像を扱えるまでに高性能化したコンピュータとそれを支えるLSIの製造技術の支えがあってのものである。そしてそれは、時間をかけて主要ブラウザの標準機能となったJavascriptストレスなく動かすPCや、非同期に数多く寄せられるリクエストも処理できるRDBMやサーバを生み、古くからある技術を利用したAJAXJSONPが新たな革命をもたらすといわれている。

2007-08-12

マークアップエンジニアって結局何やる人なの?

何か名前の響きからしてこんな感じの人を想像してたんだけど

でもいままでamachang発言((X)HTML+CSS しか出来ない人は真剣に第二の何かを探したほうがいいとか)の反応ざっと見てきたけどid:amachang(とその周辺)が「マークアップエンジニア = (X)HTML+CSS しか出来ない人」として話を進めてるのにも関わらずそれについて反論があんまりないんだよな。「趣味じゃなくて仕事として(X)HTML(とCSS)を作成するためにはこれこれこういう知識が必要なんだよ」とか「マークアップエンジニアには(X)HTMLCSSしかすることがないとでも思ってんのか馬鹿」とか言ったりするのかと思ったらほとんどそんなことなくて、むしろ同意ですとかそんなこと言われなくてもわかってるよとかJavaScriptだって同じじゃんとか見た感じそんなのばっかり。どうも俺の想像した職業とは違うらしい。

マークアップエンジニアって本当に(X)HTMLCSSの知識だけで(X)HTMLCSS書いてる人なの?反応見ててそもそも(X)HTMLCSSに理解があるのかってこと自体にまで疑問を感じるんだけど。

 
ログイン ユーザー登録
ようこそ ゲスト さん