Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。
なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。
2008年2月28日
Netscapeの終了と今後の対応
フロントエンド・エンジニア 矢倉
3月1日に、これまで公開されてきたすべてのバージョンを含む、Netscapeブラウザとメーラーの開発・サポートが終了します。
現在Netscapeを使っている方には、後継製品であるMozilla FirefoxやMozilla Thunderbirdへの移行が推奨されています。ブックマークやメールを引き継ぐ方法は利用しているバージョンごとに異なりますが、Mozilla Japanが公開している「Netscape ユーザのための Firefox/Thunderbird 移行ガイド」にて網羅されています。
操作性が変わっても問題ないという方は、Operaなど他のブラウザを試してみるのも良いかもしれません。
さて、日本には未だNetscape 7.1を「推奨ブラウザ」としているサイトが多く存在しています。これはバージョン7.1が、Netscape日本語版の最終バージョンであるからと推測されます。しかしながら、5年前にリリースされた古いブラウザには、数多くの脆弱性が存在しています。Mozilla Japanの移行ガイドにも、Netscape 7.1の持つ危険性について述べています。
アップデートされない製品を使い続けた場合、コンピュータを危険にさらすことになります。特に日本語版に関しては、2003 年 6 月 に公開された Netscape 7.1 以降、100 件以上のセキュリティ脆弱性が確認されているものの、修正版は提供されておらず、非常に危険な状態です。
後継であるFirefoxは日本語版も公開されており、サポートも受けられます。Netscape 7.1を推奨ブラウザとして掲載し続けるのではなく、Firefoxへと切り替えるなどを行うことが好ましいと考えます。
デザインやWebアプリケーションにおいても、古いブラウザへの対応はその開発やサポートにコストがかかるものです。アクセスログなどで利用者の割合を調べ、段階的に推奨環境を更新していくことが良いでしょう。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月28日
今週のW3C (2008-02-28)
フロントエンド・エンジニア 矢倉
今週W3Cから公開された技術仕様の概要です。
XMLHttpRequest Level 2
現在広く利用されているXMLHttpRequestの上位レベルである、XMLHttpRequest Level 2の最初の草案が公開されました。クロスサイトリクエストなどの機能が新たに拡張される予定です。
CSSOM View Module
文書の表示系に関する情報を取得するためのAPIを定義した、CSSOM View Moduleの最初の草案が公開されました。CSSOMはDOM 2 CSSを置き換えるものという位置づけで策定されているようです。
RDFa in XHTML: Syntax and Processing
RDFをXHTMLに埋め込むための拡張語彙と、構文を定義したRDFa in XHTML: Syntax and Processingの最終草案が公開されました。既にW3C Semantic Web FAQで利用されていたり、またValidatorでも対応が行われているようです。
SKOS Simple Knowledge Organization System Primer
シソーラスやタクソノミーなどをRDFで表現するSKOS (Simple Knowledge Organization System)の入門書、SKOS Simple Knowledge Organization System Primerの最初の草案が公開されました。概念やラベルの説明、またOWLとSKOSの違いなどがまとめられています。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月26日
WaSP座談会：IE8のバージョンターゲティングにおけるデフォルト動作
フロントエンド・エンジニア 木達
2008年2月24日
Aaron Gustafson著
（この記事はWeb Standards Project（WaSP）における投稿記事「WaSP Round Table: IE8's Default Version Targeting Behavior」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
一週間前のことですが、何人かのWaSPメンバーがMicrosoftのChris Wilsonとバーチャルな座談会を行い、ブラウザの新しい標準モードを有効にするには選択が必要という、IE8で提案されているデフォルトの動作について話し合いました。
2月16日、Web Standards ProjectメンバーのFaruk Ateş、Porter Glendinningと私は、Internet ExplorerのプラットフォームアーキテクトであるChris Wilsonを迎えて議論をしました。議題は、新しい標準モードは選択する必要があるという、IE8で検討中のバージョンターゲティングにおけるデフォルトの動作です。
覚えておいでだと思いますが、IE8で標準ベースのレイアウトやスクリプティングが改善された恩恵を被るには、開発者は新たにX-UA-Compatibleを指定するHTTPヘッダ（または相応のmeta要素）を使用することが求められます。現在検討されている案によると、そのような指定を行わないいかなるページやサーバでは、たとえIE8やIE9、あるいはIE1000でもって閲覧したとしても、IE7で閲覧しているかのように表示され続けることになります。これはIEチームが後ろ向きだと考える、多くの標準志向の開発者らとそりが合いません。彼らの多くは、コンテンツがより新しいレイアウト/スクリプティングエンジンによって解釈され続ける選択をすべきと考えています。（論争における双方の主張に興味があるなら、A List Apartの最新の記事で、この話題に関しJeremy KeithとJeffrey Zeldmanが互いに意見を表明しているのをチェックすると良いでしょう。）
「座談会」での議論を通じ、IE8の標準モードがより多くの人々に提供されるよう手助けすべくコミュニティから寄せられた、以下のようなアイデアについて話し合いました。
- （IE8がイントラネットやその類に対し破壊的な影響を与えるかもしれない可能性を避けることを期待して）サーバを自動的にIE7に対してのみ接続するようなIIS向けのパッチをMicrosoftが提供するよう働きかける
- 標準モードをデフォルトにしたIE8のベータ版を出荷し、どれだけ多くのサイトで表示崩れが発生するか調べる
- IE8をスタンドアローンなブラウザとし、IE7との同時起動を可能にして、ユーザーが特定のサイトで一方を、それ以外では他方を使える柔軟性を提供する
もし議論の様子を聞いたりそのトランスクリプトを読みたければ、以下にそれらへのリンクを用意しましたので、ご利用ください。
今回の座談会を企画・運営し、またトランスクリプトを作成したWaSPメンバー、Glenda SimsとSteph Troethには特別に感謝の意を表します。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月26日
Microsoftの提案したバージョンターゲティングについて
フロントエンド・エンジニア 木達
2008年1月22日
Drew McLellan著
（この記事はWeb Standards Project（WaSP）における投稿記事「Microsoft's Version Targeting Proposal」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
Aaron Gustafsonが執筆したA List Apartの記事「Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8（DOCTYPEの向こうへ：Web標準、前方互換性とIE8）」のなかで、開発者は制作したページに対応ブラウザのバージョンを確定し始めるべき、とするMicrosoftからの議論を呼ぶ提案が紹介されています。
Web Standards ProjectのMicrosoftタスクフォースに属するメンバーはこの提案に深く関与していますが、WaSPのメンバー全員が支持しているわけではない、ということは重要なので再度強調しておきます。皆さんの多くがそうであるように、私たちの多くはこの提案やそれが現実のものとなったときにWebが被る影響に対し、懸念を抱くことでしょう（そして既に抱いています）。
かといって、それは私たちが直ちに提案を却下すべきという意味ではありません。Web標準に準拠して開発することの意義を知る人々による、多くの検討や研究結果が提案には盛り込まれているのです。提案は提案として、それにふさわしくフィードバックや意見をもって歓迎されるべきです。もしMicrosoftがそれを価値ある解決策と信じているならば、デザイナーや開発者、そしてブラウザベンダーの皆で一緒になってそれをしっかり考察しようではありませんか。この種の議論は、個別に切り分けられるべきではありません。
さぁ、件の記事やそれに付随するEric Meyerの意見を読み、あなたにとってこの提案が何を意味するかを考え、そして議論に参加してください。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月26日
Web標準サポートを選択する、ということ
フロントエンド・エンジニア 木達
2008年1月22日
Aaron Gustafson著
（この記事はWeb Standards Project（WaSP）における投稿記事「Opting-in to standards support」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
今週のA List Apartの掲載記事のなかで、WaSPに所属する何人かと共同で開発された、Microsoftの前方互換性に対する新しい戦略を（ついに）明らかにすることができました。
IE7が登場したとき、表示がおかしくなったサイトがありました。Webコミュニティのあいだでは数多くの理由が語られたものの、Web標準に準拠したレンダリングエンジンのすべては、私たちが親しみを込めて呼ぶところの「DOCTYPEスイッチ」によってモードを切り替える事実に、誰も言及しませんでした。ここで古臭い言い回しを引き合いに出すなら、「仮定はあなたや私を笑いものにすることでしょう」。
一体、DOCTYPEスイッチとは何をする存在なのでしょう？DOCTYPEスイッチは、妥当なDOCTYPEを「モダンな」言語（たとえばHTML 4）に使っているなら、あなたが自分の行いを知っていて、かつブラウザに標準モードで表示して欲しいと考えていると仮定します。
その仮定は何ら問題なかったはずでしたが、私たち（Web標準コミュニティ、とりわけWaSP）からのプレッシャーを受け、それに配慮した結果として、妥当なDOCTYPEを新規作成した文書にデフォルトで挿入するよう決めたオーサーリングツールベンダーにとって、そうではありませんでした。既存のDOCTYPEスイッチが明示的な選択を行うものではなかったゆえに、うまく機能しなかったのです。長きにわたりブラウザシェアにおいて圧倒的な比率を誇ってきたことから、IE6が多くの開発者のテストを行う主要なブラウザとなってきた事実を書き加えれば、あなたは最悪の事態のレシピを思い浮かべることができるでしょう。開発者は、ブラウザの進化に伴いレンダリングエンジンがアップデートされることを受け入れる選択をしたと知らずに、IE6に表示されるレイアウトが正確であると仮定（またこの言葉が出ました）するのです（これらすべては、IE6のレンダリングが5年にわたり変化してこなかったことで強化されました）。
そういうわけで、IE7とそのチューンアップされたレンダリングエンジンは、サイトの表示に崩れをもたらしたわけです。
そのままでは何が起こるか目にしたくなかったMicrosoftは、明示的な選択によって標準サポートを有効にするより良い方法を探し、私たち（WaSP）に助けを求めてきました。A List Apartに書いた記事では、私たちが検討してきた経緯について、より多くを読むことができます。こちらの記事では、WaSPを卒業したEric Meyer（この提案の開発には携わらなかったものの、フィードバックを依頼しました）による解説がなされており、私たちの提案に対して彼が抱いた感情の変遷をたどることができるでしょう。私たちが「バージョンターゲティング」と呼ぶものについての一連のALA掲載記事は、私と同様このテクニックの開発に参加したPeter Paul Kochの書く、IE8以降におけるターゲティング機構のメカニズムを扱う記事でもって、2週間以内に締めくくられる予定です。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月25日
非整形式なXHTMLのエラー表示
フロントエンド・エンジニア 矢倉
タグを閉じ忘れたり、引用符で属性値を囲み忘れたXML文書は、非整形式のエラーとなります。さて、このようなエラーを持つXHTML文書をXMLとしてブラウザに処理させた場合、どのように表示されるのでしょうか。スクリーンショットと共に解説したいと思います。
非整形式のXHTMLソースは、次のようなものとなっています（エラー部分は強調表示しています）。
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<title>An Ill-formed XHTML Document</title>
</head>
<body>
<h1>非整形式 (XMLエラー) なXHTML文書のサンプル</h1>
<div>
<p>段落です。</p>
<p>この段落は終了タグを書き忘れています。
</div>
<p>この段落はきちんと終了タグを記述しています。</p>
</body>
</html>この文書をapplication/xhtml+xmlで送出し、Firefox、Opera、Safari（Windows版）で表示させてみました。
Firefox
Firefoxでは、この文書が整形式のエラーであることを伝え、またエラーを起こしたと考えられるタグを表示しています。また、どこでXMLエラーが発生したのか、その位置を行番号と共に伝えています。
なお、エラーが起こった位置の表示は等幅フォントで表示されていますが、タブでインデントを行うとその位置がずれてしまうようです。
Opera
OperaもFirefoxと同じく、エラーの種類、エラーの起こった位置が表示されます。
しかし、エラーが起こったタグ前後のソースも見ることができ、またエラーに関連するタグがハイライトされています。簡単なチェックツールとして利用できそうです。
さて、特徴的なのがエラーページにある「ページをHTML文書として処理する」というリンクです。これをクリックすると、ページをXMLとして処理するのではなく、HTMLとして処理します。text/htmlでXHTMLを公開したときと同じ処理を行っているものと考えられます。
エラーは最初に表示されてしまいますが、このような「迂回路」が用意されていることはユーザーにとってマイナスではないでしょう。
Safari
Safariのエラー表示はFirefoxやOperaと趣向の異なるものとなっています。エラーの種類や発生位置は他の二つと同じく表示されますが、その後に、エラーが起こった部分まで文書を表示しているのです。
ページのデザインによって、エラーを表示しているボックスが広告やヘッダに見えてしまう可能性はありますが、面白いですね。
XHTML文書はXMLですから、たとえtext/htmlで処理させる場合においても、整形式を維持する必要があります。しかし残念ながら、そのようなXHTML文書はとても少ないものとなっています。W3CのHTML Validatorなどで間違いがないかしっかり検証し、XMLとして処理できる文書を公開してゆくことが重要なのです。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月19日
今週のW3C (2008-02-19)
フロントエンド・エンジニア 矢倉
今週より、HTMLやCSS以外のW3C仕様についても、簡単に紹介を行っていこうと思います。W3Cトップページに掲載されたニュースのうち、仕様に関するものを取り上げていく予定です。
CSS Namespace Module
CSS Namespace Moduleの最終草案が公開されました。このCSS3のモジュールは、CSSで名前空間を宣言する構文を定義するものです。様々な名前空間が混在するXML文書にスタイルシートを適用させたい場合に利用されます。
CSS Namespace Moduleは、CSS Snapshot 2007 (日本語訳)において、今後CSSを構成する仕様のひとつとされています。というわけで、日本語訳を用意しました。
このモジュールには既にほぼ完全に準拠した実装が存在していることから、CSS3モジュールのうち初めての勧告となる可能性が高いと考えています。
Access Control for Cross-site Requests
WebアプリケーションではXMLHttpRequestなどのオブジェクトを利用し非同期通信が行われていますが、セキュリティの制限から異なるサイトとの通信が行えません。Access Controlは通信を受け入れる、または拒否するサイトを指定することにより、安全性を確保した上でクロスサイトリクエストを可能とするものです。Firefox 3（ベータ版）が既に実装しており、今後他のブラウザでも実装が期待される仕様です。
Best Practices for XML Internationalization
XMLの国際化において、設計段階から多言語を意識した文書やスキーマの構築が重要となる場合があります。W3Cは2007年に多言語に関する情報を埋め込む要素・属性を定義したInternationalization Tag Set (ITS) Version 1.0を勧告しています。今回Working Group Noteとして公開されたBest Practices for XML Internationalizationは、XHTMLやXMLとITSをどう組み合わせるかなどを例を交え解説する文書となっています。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月15日
WAI-ARIAの現状と課題
フロントエンド・エンジニア 矢倉
Webアプリケーションでアクセシビリティを確保するための仕様、WAI-ARIAの新しい草案が2月4日に公開されています。
WAI-ARIA Version 1.0と名づけられた新しい仕様は、昨年公開された二つの技術仕様（RolesとStates and Properties）を統合したものです。内容はほとんど完成しているようで、年内にはに完成するとの見解も示されています。技術仕様だけではなく、入門文書やベストプラクティスの草案も公開されています。
仕様の策定だけではなく、ブラウザや支援技術の対応も既に進んできているようです。夏ごろにリリース予定のFirefox 3はWAI-ARIAを完全サポートするようですし、JAWSやWindow-Eyesといったスクリーンリーダーもサポートを表明しています。また、JavaScriptツールキットであるDojoは早くからWAI-ARIAをサポートしています。
しかしながら、ブラウザベンダやツールキットのすべてがWAI-ARIAの対応をしているわけではありません。また、すべての支援技術ベンダがサポートを表明しているわけではありません。日本の支援技術ベンダも同様であり、言語の壁などから実装も遅くなるであろうという懸念があります。サポートを表明できない理由として、WAI-ARIAはOSのアクセシビリティAPIやHTML、DOM、JavaScriptなど関連する技術が多く、また複雑であることから対応が難しいという事情があるようです。
また、WAI-ARIAが普及するのか、という疑問も見られます。WAI-ARIAはブラウザや支援技術が対応すればよいわけではなく、Webアプリケーションを構成するXHTMLにも手を加える必要があります。しかし、一つ一つのコントロールに役割や状態を与える作業は手間のかかる作業ですし、管理のコストも増えてしまいます。
このため、Dojo Toolkitが行っているように、ある程度自動的にWAI-ARIAに対応させるような仕組みがより重要となります。対応への手間を減らすことにより、RIAのアクセシビリティも向上してゆくのです。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月12日
コミュニティベースなCSSリソースのまとめ
フロントエンド・エンジニア 木達
2008年2月4日
Rachel Andrew著
（この記事はWeb Standards Project（WaSP）における投稿記事「Community CSS resources roundup」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
しばらくの間ベータ版だったのですが、Sitepointは先週、新たにCSS Referenceを自身のサイト上に無料のコミュニティ向けリソースとして公開しました。
作者のTommy OlssonとPaul O'Brienは、信じられないくらい細かく完璧なCSSのリファレンスを作り上げました。単にさまざまなプロパティや文法を例と共に示すのではなく、ガイドラインを通じブラウザの互換性にまつわる問題点を詳述、ベストプラクティスをも与えてくれます。これには膨大な量の作業が注ぎ込まれてきました。そしてまた、利用者がコメントを寄せることにより、時を経るにつれさらに優れたリファレンスになろうとしています。もしあなたが特定の問題を解決し、あるいはブラウザに問題を引き起こす特定の書き方を知っていて、それがまだリファレンスに掲載されていなければ、その情報を書き加えることができます。
もしCSSのバグやその対処に奮闘しているなら、AdobeのCSS Advisorもあなたを手助けしてくれる場所の一つでしょう。あるいは、知識の集約に貢献できる場所、かもしれません。Adobe CSS Advisorはコミュニティベースのwikiであり、既に登録された解決策をみつけたり、それに対してコメントを書いたり、ブラウザのバグやその他の問題に対する新たなソリューションを加えることができます。
最後に忘れてならないのがCSS Discuss wikiです。バグへの対処法からレイアウトの事例に至るまで、幅広く多様な情報が文書化されています。
ここで言及されていない、お好みのCSSリソースをもしご存知でしたら、コメント欄で是非お知らせください。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月12日
Acid3、完成間近
フロントエンド・エンジニア 木達
2008年2月5日
Kimberly Blessing著
（この記事はWeb Standards Project（WaSP）における投稿記事「Acid3 nearing completion」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
あなたがAcidブラウザテストのファンなら、既にAcid3が作成中であることはご存知でしょう。それは目下「最終レビュー」の段階にあります。是非チェックして、フィードバックをお寄せください。
以前書きましたように、Ian HicksonはAcid3ブラウザテストの作成に注力してきました。そのテストが完成に近づいていることをお知らせでき、私たちは嬉しく思います。
Acid3は、Acid1やAcid2と比べると複雑なテストになっています。Webは一層、アプリケーション開発のためのプラットフォームとなりつつありますから、マークアップ言語やCSS、SVGやそれ以外の物事に加え、Acid3ではDOM2とECMAScript仕様の多くをテストします。テストする仕様のリストは、テストやそのガイドと同時に公開する予定です。
テストが複雑であるがゆえに、その公平性や正確さを確実なものとするべく、最後のフィードバックを皆さんから募っています。どうかテストをレビューのうえ、コメントを書き込む（訳注：当Blogのコメント欄に日本語でお寄せいただいたものにつきましては、可能な限りこちらで英訳のうえ先方にお伝えします）か、メールで私たちに送ってください。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月12日
Acid3には何が最もふさわしいでしょうか？
フロントエンド・エンジニア 木達
2008年1月16日
Kimberly Blessing著
（この記事はWeb Standards Project（WaSP）における投稿記事「What’s the best test for Acid3?」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
今やすべての主要な（そして多くのマイナーな）ブラウザがAcid2のサポートを誓っており、Ian HicksonはAcid3の準備に入りました。そしてあなたも、その作業を手助けすることができます！
きっとあなたはこのお知らせを楽しみにしていたことでしょうが、IE8がAcid2をパスしたとのニュースがありました。あるいは、最近あったSlashdotへの投稿をご存知であれば、既にちょっと古いニュースとなっているかもしれませんね。いずれにせよ、それは本当です。Acid3はもうすぐ登場します！
Acid2が静的なHTMLやCSSをテストしたのに対し、Acid3はECMAScriptとDOM、すなわちWebの動的な側面にフォーカスすることでしょう。面白く表示するよう意図したいくつかのレンダリングテストのほかは、100個のスクリプティングテストが主要な部分を占めます。
そしてそれこそは、あなたが貢献できる部分です！Ianは100あるうち84のスクリプトを既に集めましたが、残り16のテストを求めています。もしあなたが挑戦したければ、募集要項をお読みのうえテストを作成し、向こう5日間のうちに応募してください（訳注：既に応募期間は終了しています）。
Acid2と同様、Acid3はWeb Standards Projectのサイト上で公開します。テストが完成し次第、またブラウザの進化の模様もお届けします！
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年2月 7日
XMLの10年
フロントエンド・エンジニア 矢倉
2008年の2月10日で、XML 1.0はその勧告から10年を迎えることになります。
XMLは1996年に策定が開始され、2年弱という短い期間で勧告となりました。拡張性と汎用性を兼ね備えたその表現力と、タグで囲んで意味づけするというシンプルな書式は幅広く受け入れられ、今日最も使われる言語フォーマットの一つとなりました。また、XMLを別のXMLやテキストに変換するXSLT、XML文書中の一部分を取り出すXPathなど、関連する仕様も少しずつ広まっているようです。
一方、問題もあります。たとえば、このBlogでも利用しているXHTMLはXML言語の一つなので、XMLとして処理することが可能です。しかし、デザイナーや広告挿入のスクリプトが起こす構文ミスなどから、Webに公開されているXHTML文書のうちXMLとして解釈できるものは、ほとんど無いとの調査結果もでています（参考：「XHTML 2.0の目的と今後のXHTML」）。似たような問題は、この数年間で急速に普及したAtomやRSSにも起こっています。構文エラーに加え、XMLでは定義されていないHTMLの文字実体参照を行っているものが増えているのです。XHTMLやAtom、RSSを利用する際は、XMLとして処理できるかを事前に検証するようにしましょう。
バージョン1.0以降のXMLの動きですが、2006年にバージョン1.1が勧告されています。XML 1.1では名前に利用できる文字の制限を緩和したほか、正規化に関する新しい仕組みが設けられています。しかし、XML 1.1で追加される機能への需要あまり存在しないなどの理由から、1.1の普及や1.0からの移行は行われていません。また、数年前まではXMLの将来像として、DOCTYPEやDTDを廃止し、SGMLのレガシーな部分を取り除いた「XML 2.0」という構想も話されていたものの、その後の進展はないようです。
さて、昨日公開されたXML 1.0 第五版の修正勧告案では、1.1の機能の一部を1.0でも使用可能にするといった変更が加えられています。今後は1.0、1.1という棲み分けではなく、1.0を中心とした処理系に一本化してゆくものと予想されます。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
