일부 기술이 "표준"인 경우 무엇을 의미합니까?

Java EE 7을 배우기 시작했고이 용어 "표준"을 자주 접하게되는데 그 의미를 이해하지 못합니다.

예를 들어이 책 에서 인용 한 내용은 다음과 같습니다.

W3C 표준에 의존하는 SOAP 및 WS- * 스택과 달리 REST에는 표준이 없으며 디자인 원칙을 가진 단순한 스타일의 아키텍처입니다. REST 애플리케이션은 HTTP, URI, URL 등 다른 많은 표준에 크게 의존합니다.

나는 그것이 무엇을 의미하는지에 대한 아이디어를 가지고 있지만 확실하지 않습니다.

내가 만난 가장 좋은 설명은 여기 에서의 정의입니다 .

프로그래밍에서 "표준"이라는 용어는 종종 그룹이나 커뮤니티가 관리하는 기술 / 문서를 나타냅니다. 이 그룹의 구성원은 종종 공통 투자 목표를 공유하고 해당 기술을 적극적으로 사용하며 기술을 계속 유지하기를 원합니다.

프로그래밍에는 커뮤니티를 관리하는 많은 "사물"이 있습니다. 이 멤버는 프로그래머부터 회사 대표 (예 : Apple, Microsoft, IBM 등)에 이르기까지 다양합니다.

W3C는 많은 표준을 정의하기 위해 함께 작동하는 매우 큰 그룹입니다.

다음은 회원 목록입니다.

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

REST는 기술의 예이며, 많은 사람들이 대중적으로 사용하는 기술이지만이를 관리하는 그룹이나 커뮤니티는 없습니다. 따라서 손가락을 가리켜 "표준이 그렇게해야한다고 말하는 곳"이 없습니다 .

IBM, Microsoft 및 기타 회사와 같은 회사는 REST를 구현하는 방법에 대한 문서를 공개했습니다. REST를 구현하는 "일반적인 방법"이 있다고 말할 수 있습니다. REST 구현을 설명 하는 신뢰할 수 있는 소스 를 선택하고 해당 참조를 따르도록 주장 할 수 있습니다. 신뢰할 수있는 출처를 사용하는 것은 웹 브라우저의 호환성 문제를 해결하는 한 가지 방법입니다.

표준은 기술의 작동 방식을 지정하는 기술 문서입니다. (일부 기술의 경우 다른 종류의 기술 표준 일 수 있습니다 .) 이것이 전부이며 그 이유는 문서이며 기술을 설명합니다.

이 문서는 기술이 작동하는 방식을 결정하고 사양 문서를 표준으로 공개 할 때 사람들이 관심을 갖도록하는 데 필요한 권한과 신뢰를 가진 관리 기관이 작성합니다. 관리기구는 다른 기술이나 다른 버전의 기술에 대해 많은 표준을 생성 할 수 있습니다. 치리회는 표준의 관리자, 저자, 관리인 등으로도 알려져 있습니다.

(Mathew의 설명과 달리 표준은 치리회 나 기술 자체가 아닙니다 . 기술 이나 특정 버전을 설명 하는 문서 입니다.)

언급 한 기술 (및 기타)에 대한 몇 가지 표준 예 :

• SOAP의 표준은 W3C에 의해 유지했다.
• STD66에 정의 된 URI 표준은 IETF (Internet Engineering Task Force)에 의해 유지 보수되며 다음 작업도 수행합니다.
• HTTP 1.1 사양 의 저술 HTTP 워킹 그룹 . 이들은 RFC (Requests For Comment)이지만 HTTP 작동 방식을 지정합니다. 이러한 표준은 실제로 매우 새롭고 2014 년 6 월에 릴리스 된 것입니다. HTTP 1.1은 이전 에 IETF 네트워크 작업 그룹에 의해 RFC 2616 에서 정의되었습니다 .
• HTML Living Standard에 정의 된 HTML 사양 . 그것은에 의해 작성된 것 웹 하이퍼 텍스트 응용 기술 워킹 그룹 (WHATWG). W3C는이 표준의 다양한 버전을 다시 게시하고 포크하여 다른 버전 중에서 HTML 4 , XHTML 1.0 및 HTML5 로 릴리스합니다 . WHATWG는이 일을하는 것에 대해 불행합니다.
• Java에는 Oracle에서 유지 관리하는 표준이 있습니다. 다양한 버전이 서로 다른 표준을 가지고 있으므로 Java EE 7 표준을 직접 다운로드 할 수 있습니다 .
• Microsoft 팀이 작성한 C # 언어 사양 5.0 이전 버전에는 별도의 사양 문서가 있습니다.

HTML은 다른 버전의 언어가 종종 다른 표준을 가지고 있다는 사실의 좋은 예입니다. 다양한 버전은 다양한 버전의 언어를 처리하는 방법을 설명하는 서로 다른 문서를 가지고 있습니다.

한편, HTTP 는 그룹 간에 이동하는 표준의 많은 예 중 하나입니다 . 먼저 네트워크 작업 그룹에서 HTTP 작업 그룹으로 이동 한 다음 두 그룹 모두 IETF의 일부입니다. 다른 기술은 이동 한 회사 사이에 같은 HTML (다시)로, 버전 2는 그 중 한 RFC1866의 IETF에 의해 작성된 .

표준이 존재하는 이유는 무엇입니까?

그것들은 우리에게 일이 어떻게 작동하는지 보장하기 위해 존재합니다.

HTML5 사양은 다양한 브라우저가 표준을 올바르게 구현한다고 가정했을 때 HTML5 마크 업을 처리하고 표시하는 방법을 알려줍니다 (이전에는 문제가되었습니다). C ++ 11 표준은 내가 작성하거나 수행하지 않을 다양한 C ++ 11 코드에 대해 알려줍니다.

마찬가지로, 브라우저를 작성 하는 경우 HTML5 표준은 사람들이 기대하는 것을 얻을 수 있도록 다양한 HTML5 마크 업을 어떻게 처리해야하는지 알려줍니다. C ++ 11 컴파일러를 작성하는 경우 C ++ 11 표준은 언어를 올바르게 구현하고 사람들의 코드가 예상대로 작동하도록하기 위해 수행해야 할 작업을 알려줍니다.

예를 들어, Microsoft는 C #을 작성합니다. C # Language Specification 5.0 을 직접 다운로드 할 수 있습니다 . 이 문서는 작성한 C # 코드가 실제로 사양을 올바르게 구현하는 모든 컴파일러에서 사양에 설명 된 방식으로 작동해야한다는 약속입니다.

( 사양 이외의 작업을 수행하는 경우 정의되지 않은 영역에 있으며 발생하거나 발생하지 않을 일에 대한 보증이 없습니다.)

역사적으로 표준은 나사산 과 같은 것으로 돌아갑니다 . 따라서 X 타입의 나사를 주문하면 내가 뚫은 구멍에 맞으며 X 타입의 다른 나사와 호환 될 수 있음을 보증 할 수 있습니다.

"standard"이라는 단어의 정의로 되돌아갑니다 .

다른 사람들이 판단하거나 측정하는 것에 대한 승인되거나 승인 된 예 -Collins Dictionary

양적 또는 질적 가치에 대한 인정 된 비교 측정 기준. — American Heritage® Stedman 's Medical Dictionary

즉, 당신이 기대하는 것을 얻을 수 있도록 물건을 비교하는 것.

기술 표준은 동일한 표준의 두 가지 구현이 상호 운용 가능하거나 상호 교환 가능할 것으로 예상되는 사양입니다. 예 : USB, Bluetooth, Java EE7, HTTP

그런 다음 "사실상"표준이 있습니다. 상호 운용성을 가능하게하지만 명시 적으로 합의 된 사양이없는 규칙입니다. 예 : 많은 제품이 DOC를 읽고 쓸 수 있었지만 표준 사양을 사용할 수 없었기 때문에 Microsoft DOC 형식은 역사적으로 사실상 표준이었습니다. 문서는 여전히 모든 수신자가 읽을 수있을 것으로 기대되는 DOC 형식으로 배포되었으므로 사실상 표준이되었습니다.

특정 예를 해결하기 위해 REST에는 명시 적으로 합의 된 사양이 없으므로 실제 표준이 아니며, 실제로 올바르게 수행되어야하는 방식에 상당한 모호함이 있으며, 주요 구현이 존재하지 않기 때문에 사실상의 표준은 아닙니다. 이러한 모호성을 해결합니다. (저는 REST에 반대하지 않습니다. 웹 서비스를 구축하는 매우 좋은 방법입니다)

표준은 공식 규격에 의한 표준 컨벤션이거나 공통 컨벤션이 지배적 일 정도로 인기를 얻었 기 때문에 표준화 된 컨벤션입니다.

A de jure standard는 표준위원회에서 발표 한 사양입니다. 일부 표준위원회는 ISO, ECMA, DIN, ANSI 및 W3C입니다.

예를 de jure standards들어 A4 용지 크기 (ISO 표준 219), c # 언어 (ECMA-334) 등이 있습니다.

'사 법률'이라는 용어는 거의 사용되지 않으며 '사 법률 기준'은 종종 표준이라고합니다.

사실상의 표준은 대중의 수용 또는 시장 세력에 의해 지배적 인 입지를 확보 한 관습, 협약, 제품 또는 시스템입니다. "

(출처 : Wikipedia- 나는 그것을 더 잘 쓸 수 없었다)

사실상의 표준이 반드시 공식적인 사양을 따르지는 않습니다.

Gudmundur Orn 이이 답변 에서 썼 듯이 Microsoft Office DOC 형식은 사실상 표준이었습니다. 그것은 지배적 인 위치에 있었고, 사람들은 MS Word 문서를 읽을 수 있다고 일반적으로 가정했습니다.

JSON은 사실상 표준으로 시작된 재미있는 짐승입니다. 그러나 이후 ECMA-404 로 공식화 되었으므로 이제는 '법정 표준'이되었습니다.

그러나 그것은 또한 HTTP 기반 API와 데이터를 교환하기위한 주된 형식입니다 (내 지식으로). 따라서이 목적을 '사실상 표준'으로 만듭니다.

법적 제품 책임의 경우 결함은 디자인, 제조 또는 문서로 분류됩니다. 표준에 기반을 둔 표준에 결함이 있든 없든 설계에는 결함이 없습니다. 적용되는 표준은 제품을 만들 때의 표준입니다. 표준은 공개 표준 (ISO)이거나 표준 협회에서 공개하지 않은 허용 산업 표준 일 수 있습니다. 따라서 스푸핑과 같은 고유 한 결함이 모두있는 TCP / IP는 표준이며 VOIP와 같은 새로운 기술을 만들고 기본 기술의 알려진 문제로부터 사용자를 보호하기 위해 아무 작업도하지 않으면 신체 상해를 계속하는 것이 안전합니다. 또는 내가 잘못하고 여기에 문서 결함이있을 수 있습니다 ...