[26] [DFN[版付け]] ([DFN[[RUBYB[バージョン付け]@en[versioning]]]], [DFN[バージョニング]]) とは、[[データ]]や[[メタデータ]]として仕様や実装の[[バージョン]]の情報を付与し、それによって処理モードを変えることをいいます。 * 版付けの失敗例 [36] [[バージョニング]]は色々な形で技術に歪みをもたらします。 [17] '''[[MIME]]''' は [CODE(MIME)@en[[[MIME-Version:]]]] [[頭欄]]を導入しましたが、 非 [[MIME]] [[メッセージ]]との区別には次第に用いられなくなり、 また新規バージョンも互換性が失われる懸念から導入されずにいます。 [20] '''[[SOAP]]''' は元々広く実装された [[SOAP 1.1]] とそれを数年かけて [[W3C]] で標準化した [[SOAP 1.2]] があり、両者非互換でした。 [[SOAP 1.2]] によって [[SOAP 1.1]] が置き換えられることはなく、どちらも使われました。 [[SOAP]] を下位層とする各種 [[WS-*]] 仕様群は、どちらの版にも対応しなければなりませんでした。 [21] [['''XML''' 1.1]] は [[XML 1.0]] の「[[整形式]]」の定義を変更することとなったため、 新しい版番号が与えられました。各種の [[XML応用]]は個別に [[XML 1.0]] と [[XML 1.1]] の両方に対応することが迫られました。しかし結局 [[XML 1.1]] は普及しませんでした。 そこで [[XML 1.0]] の第5版で [[XML 1.1]] の変更の一部が取り込まれ、 「[[整形式]]」の定義が変わったのに版番号は [CODE(XML)[[[1.0]]]] のままとなりましたw (しかし [[XML 1.1]] も廃止されておらず、 [[XML 1.0]] 第4版以前、[[XML 1.1]]、[[XML 1.0]] 第5版 (以降) の3種類の混ざった混沌だけが残りましたw) [CODE[version]] [[疑似属性]]の取り扱いは幾度も非互換変更が行われ、 将来のバージョンの変更を予測して現在のバージョンのうちにバージョン切り替えメカニズムを設計することの難しさを示しました。 最終的には [CODE(XMLa)@en[[[version]]]] [[擬似属性]]の値が [CODE[1.1]] や [CODE[1.2]] であっても [[XML 1.0]] 第5版 (以降) とみなすことになりました。 [33] [['''XLink''' 1.0]] は [CODE(XMLa)@en[xlink:type]] [[属性]]を必須としていましたが、 現実には省略されることも多く、必須とする強い理由も無いとして、 省略可能に変更されました。この際、技術的な変更が加わっているため、 [[XLink 1.1]] に改番されました。 改訂と同時期には、 [[XLink 1.0]] を引用しながら、 [[XLink 1.1]] が制定中で省略可能になる予定だとして必須にしていない[[仕様書]]も出版されたりしました。 [[XLink 1.1]] の制定後も、それまで [[XLink 1.0]] を引用していた[[仕様書]]のすべてが改版されたわけではなく、 そうした古い[[仕様書]]に基づく技術で [CODE(XMLa)@en[xlink:href]] [[属性]]が必須なのかどうかは不明確です。 また、 [[XLink 1.0]] と [[XLink 1.1]] のどちらが[[文書]]で使われているかは区別できませんから、 実装は両方の挙動に同時に対応することができません。 つまり現実の要求に近づけるための新版制定だったはずなのに、かえって[[相互運用性]]に不安を残す結果となっています。 [27] '''[[HTML]]''' と '''[[CSS]]''' は [[DOCTYPEスイッチ]]により90年代の実装の延長にある[[奇癖モード]]と2000年前後の標準仕様に基づく[[標準モード]] (現在の[[無奇癖モード]]) で処理を分岐させる手法を00年代初頭に取り入れましたが、 00年代後半には既に実装コスト、学習コスト、標準化コストがかかるだけの失敗だったと考えられるようになっています。 00年代末には [[IE8]] が同様の異なる仕組みである[[文書モード]] ([CODE(HTTP)@en[[[X-UA-Compatible:]]]]) を導入しましたが、10年代前半の [[IE11]] はこれを非推奨としていて、 [[Edge]] では放棄されました。 加えて [[CSS]] では[[標準化]]の過程にある実験的な機能を [[vendor prefix]] によって区別して実装開始する手法を取り入れましたが、結局は最終的な標準版とその過程の [[vendor prefix]] 版を恒久的に (他の [[vendor]] も) 実装しなければならないことになり ([CITE[Compatibility Standard]])、バージョンを区別して最終版以外は切り捨てるとの目論見は破綻しました。 つまり標準化して実施しても単一ベンダーで独自に実施しても、 全体レベルでも機能レベルでも、[[バージョニング]]は失敗しています。 [60] [[CSS2]]/[[CSS 2.1]]/[[CSS 2.2]]/[[CSS3]] のカオスな状況のように、 [[CSS]] は[[仕様書]]の[[バージョニング]]の面でも失敗しています。 [28] [['''XHTML'''2]] は [[XHTML1]] と非互換なことから異なる[[名前空間]]を採用し、 事実上の[[バージョニング]]を行っていました。しかし [[XHTML1]] への機能追加の要求が強まり、徐々に新機能を [[XHTML1]] へと[[バックポート]]していきました。 その流れは最終的に [[XHTML2]] プロジェクト全体を崩壊させるに至りました。 [29] '''[[XPath]]''' と '''[[XSLT]]''' は 2.0 で大きな非互換変更を行い、 [CODE(XML)@en[[[version]]]] を指定することで動作モードを切り替えるようにしましたが、 [[Webブラウザー]]を含む多くの実装が 2.0 の実装を嫌がり、普及の障壁となりました。 ;; これは[[セカンドシステム症候群]]の例とも言えそうです。 [37] '''[[XForms]]'''、'''[[XML Events]]'''、'''[[XFrames]]''' は、 [[HTML]] の一部機能を改良することを目指したものでしたが、 互換性が一切無く異なる[[名前空間]]を採用していました。 [[XHTML2]] と共に [[HTML]] の新バージョンとして置き換えることを狙っていましたが、 誰も使いたがりませんでした。 ;; これは[[セカンドシステム症候群]]の典型例でもあります。 [30] '''[[JavaScript]]''' は [CODE(HTMLa)@en[[[language]]]] [[属性]]や [[MIME型]]でバージョンの区別ができることになっていましたが、 [[Webブラウザー]]の実装も[[著者]]側の利用も正しく行えず、 次第にその意味するところが曖昧になっていきました。 最終的にはバージョンの区別はすべて無視されるようになりました。 [35] '''[[DOM]]''' は[[特徴][DOM特徴]]という形で[[アプリケーション]]が[[実装]]の版を判定できる仕組みを用意していましたが、 有効に機能しませんでした。 [38] '''[[RSS]]''' と '''[[Atom]]''' は、色々なバージョンが乱立しました。 各バージョンは互換性が全くなかったり、一見互換性がありそうだったり色々でした。 (各項を参照。) 実世界では、バージョンが正確に使い分けられず、 他のバージョンの機能が混在させて用いられたりしました。 バージョン番号だけを新しいバージョンに書き換えてそれ以外は旧バージョンのままの[[フィード]]もあったりします。 結局すべてのバージョンが混在したどの[[仕様書]]でも説明されていないものが現実に用いられているものであり、 [[相互運用性]]に大きな課題を抱えています。 @@ [34] [['''TLS''' 1.3]] では、バージョン欄が... (というかすぐに廃止予定だった [[SSL 2.0]] が十数年間削除できなかった時点で...) [54] [[HTTP]] は[[プロトコルの版]]で将来の版と [[HTTP/1.x]] を区別することを企図していましたが、 実際の [[HTTP/2]] はそれを実質的に利用せず、 [[ALPN]] で切り替えています。 将来のバージョンがどのような設計を選択するかの予測は的中するとは限らず、 現在のバージョンに組み込んだバージョン切り替え機構が実際に採用されるかどうかは、 その時までわからないのです。 [68] [F[[CODE[xAvgCharWidth]]]] は版によって計算方法が違いますが、版を更新したのに旧版で計算した値をそのまま変更せずに使い続けているため新版なのに古い計算方法の値、 というものが混在しているという状況です。 もちろん版は新版に更新されてしまっているので、新旧どちらかを判定する方法はありません。 * 版付けの失敗理由 [39] こうした実例から、失敗の理由は次のように整理できそうです。 [FIG(list)[ - [40] 複数のバージョンが混在する時、どう処理するべきかが[[仕様書]]に明記されないことが多い。 [[仕様書]]はいずれかのバージョンのみを規定することが多いので、 バージョン間の相互作用は規定から漏れがちである。 - [41] バージョン間の相互作用が規定されたとしても、 旧バージョン時代に新バージョンを予測するのは困難で、 曖昧な規定になりやすい。しかも旧バージョン時代の実装による新バージョンの扱い ([[仕様書]]通りに実装されるとも限らない。) が新バージョン制定時の制約になってしまう。 - [42] 新バージョンが制定されると旧バージョンの[[仕様書]]は放置されることがほとんどである。 ところが現実世界では旧バージョンも残ることが多い。 新バージョンの[[仕様書]]で解決されている問題が旧バージョンの[[仕様書]]で未解決の場合、 実装と[[仕様書]]が乖離するか、色々な実装が混在してしまう。 - [43] 新バージョンで多くの課題を解決しようとして旧バージョンとかけ離れたものを作ってしまうが、 実装者や[[著者]]は現状より少し良くなったものを求めているだけでしかない。 新バージョンが出るたびに全部作り直したくはない。 - [44] ほとんど同じ機能の複数のバージョンの実装をメンテナンスし続けるのはつらい。 旧バージョンの仕様であってもバグ修正などは続けなければならないから、 バージョンが変わるたびにメンテナンスコストがどんどん増えていく。 - [45] [[仕様書]]の開発スケジュールと[[実装]]のリリース時期が一致していない。 「[[仕様書]]バージョンαの[[実装]]」は実際にはあまり無く、 「[[仕様書]]バージョンαの[VAR[p]] % + [[仕様書]]バージョンβの新機能の [VAR[q]] % の[[実装]]」 のような形になるので、[[仕様書]]の機能単位のバージョニングと整合しない。 - [69] 仕様の開発者が新版を設計した問題意識を、実装者が共有しているとは限らず、 仕様の開発者の思った通りに使ってもらえるとは限らない。 ]FIG] [65] ソフトウェアの版の使い方を誤った失敗事例: - [[Heroku]] - [[Vercel]] [66] [[版番号]]の比較の失敗事案: [[version sniffing]], [[年問題]] * 比較的うまく移行できた例 @@ [[WebSocket]]、 [[SPDY]] * Web API におけるバージョニング [48] [[Web APIの悪い設計]]を参照。 * プロファイルとスキーマとバージョニング @@ [49] [[XML名前空間]]と[[カメレオン名前空間]]の失敗も参照。 * 版番号の命名規則 [SEE[ [[版番号]] ]] * プロトコル [SEE[ [[版番号]] ]] * その他の事例 [64] [[OpenType]] * メモ [1] [CITE@en-US[David Baron's weblog: March 2007]] ([CODE[2007-03-26 09:31:27 +09:00]] 版) ([[名無しさん]] [WEAK[2007-03-26 00:33:42 +00:00]]) [2] [CITE@en[Re: Doctypes and the dialects of HTML 5]] ([[Henri Sivonen]] 著, [CODE[2007-03-25 18:16:51 +09:00]] 版) ([[名無しさん]] [WEAK[2007-03-26 10:16:32 +00:00]]) [3] [CITE@en[Re: Doctypes and the dialects of HTML 5]] ([[Henri Sivonen]] 著, [CODE[2007-03-25 18:16:51 +09:00]] 版) ([[名無しさん]] [WEAK[2007-03-26 10:17:07 +00:00]]) [4] [CITE@en[XForms document versioning]] ([[Mark Birbeck]] 著, [CODE[2007-04-05 01:02:12 +09:00]] 版) Versioning ここに極まれり的な提案でつね。 ([[名無しさん]]) [5] [CITE[IRC logs: w3c / #html-wg / 20070404]] ([CODE[2007-04-06 23:18:21 +09:00]] 版) そりゃぁこういう冗談もいいたくなってくるわ。 ;; [[言語札]]は本当に版付けが必要な気がするがw ([[名無しさん]]) [6] [CITE@en-US[David Baron's weblog: April 2007]] ([CODE[2007-04-07 22:16:48 +09:00]] 版) ([[名無しさん]] [WEAK[2007-04-07 13:19:03 +00:00]]) [7] [CITE@en[Versioning and html'''['''5''']''']] ([[Chris Wilson]] 著, [CODE[2007-04-13 01:40:07 +09:00]] 版) ([[名無しさん]] [WEAK[2007-04-14 05:57:29 +00:00]]) [8] [CITE@en[Sam Ruby: Form Follows Function]] ([CODE[2007-04-16 20:51:51 +09:00]] 版) ([[名無しさん]] [WEAK[2007-04-17 00:29:21 +00:00]]) [9] [CITE@en[Version information (was Re: HTML5 vs HTML6)]] ([[L. David Baron]] 著, [CODE[2007-04-06 09:27:21 +09:00]] 版) ([[名無しさん]]) [10] [CITE@en[Technical Architecture Group -- 16 Apr 2007]] ([CODE[2007-04-17 02:29:18 +09:00]] 版) [11] [CITE@en[crisp's blog » Blog Archive » HTML5: Microsoft and the opt-in catch]] ([CODE[2007-04-23 09:43:54 +09:00]] 版) ([[名無しさん]] [WEAK[2007-04-23 00:50:52 +00:00]]) [12] [CITE@en[HTML and version mechanisms - W3C QA Weblog]] ([CODE[2007-05-01 12:13:23 +09:00]] 版) ([[名無しさん]] [WEAK[2007-05-02 01:25:30 +00:00]]) [13] [CITE@en[Version information (was Re: HTML5 vs HTML6)]] ([[L. David Baron]] 著, [CODE[2007-04-06 09:27:21 +09:00]] 版) ([[名無しさん]]) [14] [CITE[Todd Ditchendorf’s Blog. XML, Cocoa, JavaScript, Java. » Blog Archive » IE 8 and standards support confusion]] ([CODE[2007-07-01 22:38:08 +09:00]] 版) ([[名無しさん]] [WEAK[2007-07-01 13:40:16 +00:00]]) [15] [CITE@en[Ajaxian » IE 8: Opt-in for standards compliance]] ([CODE[2007-07-01 22:37:58 +09:00]] 版) ([[名無しさん]] [WEAK[2007-07-01 13:41:17 +00:00]]) [16] [CITE@en[Re: '''['''validator''']''' the @profile at-rule]] ([[fantasai]] 著, [TIME[2008-10-02 09:17:51 +09:00]] 版) [67] [CITE[Versioning and HTML]], [TIME[2009-06-11T14:05:44.000Z]], [TIME[2024-09-24T14:54:44.917Z]] [18] [CITE['''['''whatwg''']''' HTML6 Doctype]] ([TIME[2010-12-07 10:18:00 +09:00]] 版) [19] [PRE(XML example code)[ ]PRE] DTD が無いと言われた。4.4まではローカルにあったけど、4.5は無かった。カタログでローカル・ファイル・システムに写像されていて、ファイルが無いからエラーになっていたらしい。当該部分を削除したら、今度はネットワーク経由で実体を取りにいこうとしているとエラーになった。馬鹿か。何のために URL を使っているんだ。というわけで 4.5 のURLを 4.4 に書き換えたら動いた。なんのためのバージョンなんだ。実に馬鹿らしい。 [22] [CITE@ja[IE9ヤバイ。IE9の文字間隔・互換モード・DOCTYPE宣言について]] ([TIME[2011-05-09 16:55:35 +09:00]] 版) [23] [CITE[IRC logs: freenode / #whatwg / 20140108]] ( ([TIME[2014-01-09 22:07:16 +09:00]] 版)) [24] [CITE@ja[You don't need API version 2 - yohei's diary]] ( ([TIME[2014-03-12 01:07:05 +09:00]] 版)) [25] [CITE@en-US[Internationalization Tag Set (ITS) Version 2.0]] ( ([TIME[2013-10-27 19:39:43 +09:00]] 版)) [31] [CITE@en-US[How are REST APIs versioned? | Lexical Scope]] ([TIME[2015-03-14 16:56:48 +09:00]] 版) [32] [CITE@ja[PowerShell の ps1 ファイルは 何故 1なのか - tech.guitarrapc.cóm]] ([TIME[2015-11-07 15:37:57 +09:00]] 版) [46] [CITE@en[Re: Update the Editor's Draft Specification Page]] ([[Ilya Grigorik]]著, [TIME[2017-02-11 17:19:04 +09:00]]) [47] [CITE@en[Re: Add ability to specify the version of used CSP]] ([[Bil Corry]]著, [TIME[2017-03-09 23:43:42 +09:00]]) [50] [CITE@en[Re: Add ability to specify the version of used CSP]] ([[Mike West]]著, [TIME[2017-03-20 23:00:02 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [51] [CITE@EN[XSL Transformations (XSLT) Version 3.0]] ([TIME[2017-04-17 18:39:00 +09:00]]) ]FIGCAPTION] > XSLT 3.0 requires support for XPath 3.0 augmented by a selection of features from XPath 3.1 which are described in 21 Maps and 22 Processing JSON Data. XSLT 3.0 in addition allows a processor to support the whole of XPath 3.1, in which case it must do so as described in 27.7 XPath 3.1 Feature. ]FIG] [52] つまり世の中には「XPath 3.0」、「XPath 3.0 と追加機能」、「XPath 3.1」 の3種類の XPath3 があって、後2者が [[XSLT 3.0]] で使えるということだ。 2つが使えるというか、どちらでもいい (= どちらかは実際使ってみないとわからない)。破綻してるだろこれ。 [53] [CITE@en[RFC 8170 - Planning for Protocol Adoption and Subsequent Transitions]] ([TIME[2017-05-25 22:30:49 +09:00]]) [55] [CITE@en[CSP, not CSP2.]] ([[mikewest]]著, [TIME[2017-06-07 16:31:02 +09:00]]) [56] [CITE@en[Do not version the ECMAScript spec used]] ([[TimothyGu]]著, [TIME[2017-09-07 09:28:14 +09:00]]) [57] [CITE@en[Re: !important: css versioning, and a semantic shift]] ([[Florian Rivoal]]著, [TIME[2018-01-16 09:29:35 +09:00]]) [58] [[versioning]] を主張する人は後を絶たないのなんでだろうなあ。[[リセット]]信仰のバリエーションなのかなあ。 [59] [CITE@en[RFC 6709 - Design Considerations for Protocol Extensions]] ([TIME[2018-04-05 17:00:08 +09:00]]) [61] [CITE@ja[Chromeが6週間毎にTLSバージョン番号を変更していくかもしれない - ASnoKaze blog]] ([TIME[2018-10-14 14:28:17 +09:00]]) [62] [CITE@en[Versioning · Issue #17 · tc39/proposal-built-in-modules · GitHub]], [TIME[2021-06-05T08:17:46.000Z]] [63] [CITE@en[rfc3920]], [TIME[2021-06-22T06:15:28.000Z]]