一部の技術が「標準」であるとはどういう意味ですか?


16

私はJava EE 7を学び始めましたが、この「標準」という用語に頻繁に出くわしますが、その意味がわかりません。

したがって、たとえば、この本からの引用は次のとおりです。

W3C標準に依存するSOAPおよびWS- *スタックとは異なり、RESTには標準がなく、設計原則を備えたアーキテクチャのスタイルにすぎません。RESTアプリケーションは、他の多くの標準に大きく依存しています:HTTP、URI、URL ...

私はそれが何を意味するのかについていくつかの考えを持っていますが、私にはわかりません。

私が出会った最も良い説明はここからの定義です


7
技術標準に関するウィキページをお読みください。しかし、それは実際には流行語かもしれません。標準は一般に仕様です。したがって、C ++ 11Posixは標準です。
バジルスタリンケビッチ14

それは、それを押している人があなたにそれを(に)購入するように説得しようとしていることを意味します。
bmargulies 14

回答:


21

プログラミングの「標準」という用語は、多くの場合、グループまたはコミュニティによって管理されるテクノロジー/ドキュメントを指します。そのグループのメンバーは、多くの場合、共通の投資目標を共有し、そのテクノロジーのアクティブユーザーであり、テクノロジーの継続を保証したいと考えています。

プログラミングには、それらを管理するコミュニティを持つ多くの「もの」があります。これらのメンバーは、プログラマーから企業の代表者(Apple、Microsoft、IBMなど)まで多岐にわたります。

W3Cは、多くの標準を定義するために協力する非常に大きなグループです。

メンバーのリストは次のとおりです。

http://www.w3.org/Consortium/Member/List

RESTは技術の例であり、その人気は多くの人々に使用されていますが、それを管理するグループやコミュニティはありません。したがって、指を指して「標準がそれを行うべきだと言っていると言う場所はありません。

IBM、Microsoft、その他の企業は、RESTの実装方法に関するドキュメントを公開しています。RESTを実装する「一般的な方法」があると言えます。RESTの実装を説明する信頼できるソースを選択し、その参照に従うことを主張できます。信頼できるソースの使用は、Webブラウザーの互換性の問題に対処してきた1つの方法です。


4
また、標準を見つけるために場所のリストにRFCを追加します。たとえば、

2
@Snowman すべてのRFCが標準化されているわけではないことに注意してください。ほとんどそうでないと思う。また、リンクされたページの上部を見るとわかるように、RFC 2616はRFC 7230-7235によって廃止されています。RFC7230-7235は代わりに参照する必要があります。ちなみに、その1つは「インターネット標準」ではなく「提案された標準」にすぎません(どちらも標準化過程ですが、後者ははるかに成熟しており、変更される可能性は低いと考えられます)。
ボブ14

@Snowman:あなたのコメントは、実際に最も重要なことを示しています。標準とは、人々がそれを標準に同意することです。実際にRRFページを見ると、RFCの数が数百あることを確認できますが、実際には78の標準しかありません。そして、あなたが述べたHTTPは、実際に標準ではありません!それは「ただの」Request For Comments、つまり誰かが議論したいアイデアを持っているということです。HTTPを標準にしているのは、一部の統治機関がそれを公開しているのではなく(問題の統治機関が実際に「標準」と呼んでいないため)、人々がHTTPを1つとして扱うためです。
ヨルグWミットタグ14

@JörgWMittag私は常に、あるべき姿を示す権威あるソースから発行されたドキュメントであるという基準を採用しています。問題は、人々が権威ある情報源であることに異議を唱えることができる一方で、他の人が権威ある権力を濫用することです(つまり、MicrosoftとAppleは良い例です)。どちらもしばしば標準を無視するか、強制しようとします。多くの場合、標準は、大企業が適用しないと感じるものです。
Reactgular 2014

1
@Mathew 「私は常に、あるものがどうあるべきかを示す権威あるソースから発行された文書になるための基準をとってきました。」-あなたのコメントのこの文に同意しますが、あなたの答えは現在「標準」という用語は技術そのものを指していると言っています。(たとえば、Javaは標準であり、Java EE 7仕様は標準ではありません。)前のバージョンでは、OracleやW3Cなどの組織は「標準」の意味であると述べました。ここであなたが何を意味するかを言うために、あなたの答えを更新する必要があります。そのまま書かれて、あなたの答えには誤った情報が含まれています。:(
doppelgreener 14

10

標準とは、テクノロジーの動作を指定する技術文書です。(一部の技術では、他の種類の技術標準である可能性があります。)それがすべてであり、それらが存在する理由です。それらは文書であり、技術を説明しています。

これらの文書は、技術がどのように機能するかを決定するために必要な権限と信頼を持ち、標準として仕様文書をリリースするときに人々が気にかけるために必要な権限と信頼を持つ管理機関によって作成されます。統治体は、さまざまなテクノロジーまたはテクノロジーのさまざまなバージョンに対して、多くの標準を作成できます。統治体は、標準のメンテナー、著者、カストディアンなどとしても知られています。

(マシューは説明するものとは異なり、標準ではありません統治体技術そのもの。それは、文書の記述技術、またはそれの特定のバージョンを。)

あなたが言及した技術の標準の例(およびその他):

HTMLは、言語のバージョンによって標準が異なることが多いという事実の良い例です。さまざまなバージョンには、さまざまなバージョンの言語を処理する方法を説明するさまざまなドキュメントがあります。

一方、HTTPは、グループ間を移動する標準の多くの例の1つです。最初はネットワークワーキンググループによって、次にHTTPワーキンググループに移動しますが、どちらのグループもIETFの一部でした。HTML(再度)など、RFC1866のIETFによって作成されたバージョン2など他の技術も企業間を移動しました

なぜ標準が存在するのですか?

これらは、物事がどのように機能するかを保証するために存在します。

HTML5仕様では、さまざまなブラウザーが標準を正しく実装していることを前提に、筆者が記述したHTML5マークアップを処理および表示する方法を教えてくれます(これまでは問題でした)。C ++ 11標準は、私が書くさまざまなC ++ 11コードが何をするか、またはしないかについて教えてくれます。

同様に、私がブラウザを書いている場合、HTML5標準は、人々が期待するものを得るために、HTML5マークアップのさまざまな部分を処理する方法を教えてくれます。C ++ 11コンパイラを書いている場合、C ++ 11標準は、言語を正しく実装し、人々のコードが期待どおりに機能するようにするために必要なことを教えてくれます。

たとえば、MicrosoftはC#を作成しています。C#言語仕様5.0は自分でダウンロードできます。このドキュメントは、仕様を実際に正しく実装するコンパイラで、作成するC#コードが仕様で記述されているとおりに動作することを約束します。

仕様以外のことを行うと、未定義の領域にいることになり、何が起こるか、または起こらないかについての保証はありません。)

歴史的に、標準はネジ山のようなものに戻っているため、タイプXのネジを注文すると、ドリルした穴に適合し、タイプXの他のネジと交換できることを保証できます。

「標準」という言葉の定義に戻ります。

他人が判断または測定される対象の容認または承認された例— Collins Dictionary

定量的または定性的価値の認められた比較尺度。基準。— AmericanHeritage®ステッドマン医学辞典

すなわち、あなたがあなたが期待するものを確実に手に入れるために、あなたのものを比較するもの。


1
ECMAによって公開されたC#、. NET、CLR、およびC ++ / CLRの標準もあり、その後ISOに迅速に追跡されました。ISOにはHTMLの標準もあり、ISO HTML 1.0はW3C HTML 4.01 Strictのサブセットです。
ヨルグWミットタグ14

4

技術標準は、同じ標準の2つの実装が相互運用可能または交換可能であることが期待されるような仕様です。例:USB、Bluetooth、Java EE7、HTTP。

次に、「事実上の」標準があります。相互運用性を可能にする規則ですが、明示的に合意された仕様はありません。例:多くの製品がDOCを読み書きできるので、Microsoft DOC形式は歴史的に事実上の標準でしたが、標準仕様は(かなり後まで)利用できませんでした。文書は一般にDOC形式で配布されていましたが、どの受信者でも読むことができると予想されていたため、事実上の標準になりました。

あなたの特定の例に対処するために、RESTには明示的に合意された仕様がなく、したがって真の標準ではなく、正しく行う方法にかなりの曖昧性があり、支配的な実装が存在しないため、事実上の標準ではありませんこれらのあいまいさを解決します。(私はRESTに反対ではありません。Webサービスを構築するのに非常に良い方法です)


1

標準は標準化された規則です-正式な仕様によるか、単に一般的な規則が十分な人気を獲得したためです。

A de jure standardは、標準委員会によって発行された仕様です。一部の標準委員会は、ISO、ECMA、DIN、ANSI、およびW3Cです。

たとえば de jure standards、A4用紙サイズ(ISO標準219)、c#言語(ECMA-334)などです。

「de jure」という用語はめったに使用されず、「de jure standard」はしばしば単に標準と呼ばれます。

事実上の標準とは、一般の受け入れや市場の力によって支配的な地位を獲得したカスタム、慣習、製品、またはシステムです」

(ソース:ウィキペディア -自分でもっとうまく書けなかった)

事実上の標準は、必ずしも正式な仕様に従うとは限りません。

Gudmundur Ornがこの回答で書いたように、Microsoft Office DOC形式は事実上の標準でした。支配的な地位にあり、通常は人々がMS Word文書を読むことができると想定されていました。

JSONは事実上の標準として始まったため、面白い獣です。しかし、それはその後ECMA-404として正式化されたため、今では「デジュレ標準」になっています。

ただし、これは(私の知る限り)HTTPベースのAPIとデータを交換するための主要な形式でもあるため、この目的の「事実上の標準」にもなっています。


-4

法的製造物責任については、欠陥は設計、製造、または文書に分類されます。規格に基づいている場合、その規格に欠陥があるかどうかに関係なく、設計に欠陥はありません。適用される標準は、製品の作成時に設定されたものです。標準は、公開された標準(ISO)または標準協会によって公開されていない業界標準として認められています。したがって、スプーフィングのような固有の欠陥をすべて備えたTCP / IPは標準であり、VOIPのような新しいテクノロジーを作成し、基礎となるテクノロジーの既知の問題からユーザーを保護するために何もしなければ、騒乱を続けても安全です。または私は間違っている可能性があり、ここにドキュメントの欠陥があります...


3
定義上、標準に欠陥はありません。ただし、標準を正しく実装している製品には欠陥がある可能性があり、目的に適合していません。どれだけ多く、またはどれだけ標準に準拠しているかは関係ありません。製品が意図した目的の要件を満たさない場合、欠陥があります。
ライライアン14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.