W3C logo
slanted W3C logo

Cover page images (keys)

インターネット技術の
標準化

佐々木フェリクス, W3C

資料

本講義の目的

「インターネット技術」はアプリケーションの標準を中心とする

「標準の紹介」は標準化の違いを中心とする

本講義の構造

月曜日

本講義の構造

月曜日(続き)

本講義の構造

水曜日まで提出期限の宿題

宿題をメールで送ってください。

本講義の構造

木曜日

本講義の構造

金曜日

成績評価

3-5ページを書いてください。枚数は重要ではありません。

自己紹介

本講義でWeb標準として紹介する三つの例

BCP 47、Web Services Policy、Unicode

本講義でWeb標準として紹介する三つの例

本講義でWeb標準として紹介する三つの例

本講義でWeb標準として紹介する三つの例

本講義の構造

月曜日

標準化の意味について

標準化の目的

アメリカの鉄道の標準化の一例(スライドはJacek Kopeckýが提供)

標準化の目的

アメリカの鉄道とHTMLの違い

標準化の目的

標準化の意味について

標準の種類

The wonderful thing about standards is that there are so many of them to choose from

標準の「素晴らしい」特徴は標準がたくさんあり、その中から相応しいものを選ばざるを得ない、ということです。

グレース・ホッパー アメリカ軍の計算機科学者)

デファクトスタンダードとデジュリスタンダード

デファクトスタンダードとデジュリスタンダード

プロプライエタリとオープン

プロプライエタリとオープン

標準化の意味について

「BCP 47」

<p xml:lang="zh-CN" lang="zh-CN">雪 zh-CN</p>
<p xml:lang="ja" lang="ja">雪 ja</p> 
<p xml:lang="ko" lang="ko">雪 ko</p>

雪 zh-CN

雪 ja

雪 ko

「BCP 47」

「BCP 47」を定義するワーキングループの会員になるのには

「Web Services Policy 1.5」

「ISO/IEC 10646(Unicode)」

本講義の構造

月曜日

標準化の組織

ITU、IEC、ISO

新しい組織

「10間」存在する組織

標準化の組織

国内と国際的な組織

国内の標準と国際的な標準

  1. 国際的な標準の例「ISO/IEC 10646(Unicode)」
  2. XMLがUnicodeを適用
  3. 国内の標準XML 日本語プロファイル(JIS TR X 0015)
  4. JIS TR X 0015が英語訳される、W3Cの文書XML Japanese Profile (Second Edition)

1)国際標準2)それを使用する国際標準3)それを使用する国内標準4)それを使用する文書

注意!「標準」と「文書」の違い

注意!「標準」と「文書」の違い

違いは合意「consensus」の範囲

Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it.XML Japanese Profileから)

デジュリスタンダードにとって重要な違いで、デファクトスタンダードにとっては重要ではない

国内の標準と国際的な標準

標準化の組織

NSBとSDOの関係

標準の参照することについて

標準化の組織

組織の分析に重要なポイント

ISO/IEC、JISC

W3C

OASIS

Organization for the Advancement of Structured Information Standards

IETF

We reject kings, presidents and voting. We believe in rough consensus and running code
デービッド・ダナ・クラーク、アメリカのコンピューター学者)

標準組織かどうか「WS-I」

Web Services-Interoperability Organization

標準組織かどうか「WHAT-WG」

Web Hypertext Application Technology Working Group

WS-IとWHAT-WGの共通点

ある標準を担当する組織が業界、又はユーザーのコミュニティー が望まない標準化活動を行う

その結果、新しい「標準化」活動が始まる

それは「標準化」かどうかは不明

本講義の構造

月曜日(続き)

標準化の一般的な過程

charterのー例

目的の記述

ワーキングループ(TC)が作成する文書

対象外のテーマ

Liaison(共同作業)

過程を定める標準組織ごとの規則

過程を定める標準組織ごとの規則

過程を定める標準組織ごとの規則

過程を定める標準組織ごとの規則

標準化組織によって問題の種類と対策が違う

水曜日まで提出期限の宿題

水曜日まで提出期限の宿題

宿題をメールで送ってください。

本講義の構造

木曜日

宿題の分析

宿題をチェックするとき、感動しました!

charterの質は非常に良かったが、いくつかの気を付けた方がいいところがある

宿題の分析(続き)

皆が興味のある標準化の分野は

本講義の構造

木曜日

標準化のツール

標準化のツール(続き)

標準化のツール

注意!W3Cのワーキングループによって、ツールの「好み」が違うこともある

コミュニケーションのツール「メール」

コミュニケーションのツール「メール」

MLの読み方

コミュニケーションの手段「電話会議」

コミュニケーションの手段「face-to-face meeting」

電話会議と「face-to-face meeting」の問題点

W3Cの解決方法は「IRC」がメーン

コミュニケーションのツール「IRC」

IRC」(Internet Relay Chat)の役割は様々

IRCの基本

IRCのBOT「zakim」

IRCのBOT「rrsagent」

rrsagentのログの一例議事録の一例

IRCのBOT「tracker」

話題の管理「Issue tracking」の重要性

そういう証明は、「Disposition of Comments」という

(「Web Service Policy」の「Last Call Working Draft」の一例

「Issue tracking」の基になる「Bugzilla」

BugzillaのBugの一例

「Balloting」と出席の関係

「Web Service Policy」ワーキングループの参加者の一覧

標準化のツール(続き)

文書の作成、編集

文書とデーターの管理、配布

文書の「diff」と文書のチェック

本講義の構造

木曜日

標準の「言葉」と「スタイル」

標準の「言葉」と「スタイル」(続き)

標準の「言葉」と「スタイル」(続き)

文書の識別、バージョン情報

例「http://www.w3.org/TR/2007/CR-ws-policy-20070605」の草案

This version:
    http://www.w3.org/TR/2007/CR-ws-policy-20070605
Latest version:
    http://www.w3.org/TR/ws-policy
Previous version:
    http://www.w3.org/TR/2007/CR-ws-policy-20070330/

URIの安定性「cool URI's don't change!」

Cool URIs don't change」から

What makes a cool URI?
A cool URI is one which does not change.
What sorts of URI change?
URIs don't change: people change them.

URIの重要性でW3Cの草案に「checklink」のツールが必要

URIの安定性「cool URI's don't change!」?!?

但し、他の標準化組織はURIに関する態度が違う

Internet-Drafts are not an archival document series.
These documents should not be cited or quoted in any formal document.
Unrevised documents placed in the Internet-Drafts directories have a maximum life of
six months. After that time, they must be updated, or they will be deleted.

名前空間の重要性

名前空間「namespace」の例(Web Service Policyの草案から)

<wsp:Policy
 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
 xmlns:wsp="http://www.w3.org/ns/ws-policy" >
 <wsp:ExactlyOne>
...
  <sp:SignedParts>
...
  </sp:SignedParts/>
...
 </wsp:ExactlyOne>
</wsp:Policy>

URIs for W3C Namespaces

URIs for W3C Namespacesの規則

名前空間を変える、ということは…

新しい草案で名前空間を変えることが大変!

「Web Services Policy 1.5 Namespace」名前空間の記述から

should the specifications revert to Working Draft status, and a
subsequent revision, published as a WD, CR or PR draft, results in non-backwardly
compatible changes from a previously published WD, CR or PR draft of the specification,
the namespace URI will be changed accordingly

「cool」ではないURIの例

Reserved Top Level DNS Names(IETFの「BCP 32」から )

four domain names are reserved ...
     .test
  .example
  .invalid
.localhost

「cool」ではないURIの例は草案の中で「.example」と企業の名前を混乱してしまう

http://myCompany.example.com

mycompanyは本当に存在するので著作権の問題が起こってしまう!

国際化の要求

Unicodeの使用が必要。Unicodeの文字コードを参照する方法

国際化の要求

日時の書き方

国際化の要求

文書を翻訳するときは注意した方がいいところがある

The <code>title</code> attribute ...

文章の構造

例は「Web Services Policy 1.5 - Framework

文章の構造(続き)

必要な章

W3Cの草案の「status section」の読み方

例は「Web Services Policy 1.5 - Framework

W3Cの草案の「status section」の読み方(続き)

例は「Web Services Policy 1.5 - Framework

The Working Group expects to advance
this Working Draft to Recommendation Status.

マーク付けの使い方

<link rel="stylesheet" type="text/css" href=
"http://www.w3.org/StyleSheets/TR/W3C-CR.css"/>

正誤表「Errata」

RFC2119のケーワード

RFC2119から(日本語訳もある)

RFC2119を参照することが多い

Normativeとnon-normativeの違い

Web Service Policy」からの例

Normative text within this specification takes precedence over normative 
outlines, which in turn take precedence over the
XML Schema descriptions.

草案の附属書から

A. The application/wspolicy+xml Media Type
...
B. References
...
C. Acknowledgements (Non-Normative)
...

Normativeとnon-normativeの違い(続き)

正式的な記法

正式的な記法の種類と記法を使うか使わないかは考え方は様々だ

参考文献と参照

草案と草案の間にある依存関係の例

WS-Addressing Metadataという草案が「Web Services Policy」を参照する

Web Services Policy 1.5 - Framework, A. S. Vedamuthu, ... Editors.
World Wide Web Consortium, 05, June 2007. This version of the specification of the
Web Services Policy 1.5 - Framework specification is
http://www.w3.org/TR/2007/CR-ws-policy-20070605. The latest version of Web Services
Policy 1.5 - Framework is available at http://www.w3.org/TR/ws-policy.

「WS-Addressing Metadata」のワーキングループの参加者は、「Web Services Policy」の草案が早く進歩できるようと願っている…

参考文献と参照(続き)

参考文献の例

<cite><a href="http://www.w3.org/TR/2007/CR-ws-policy-20070605">Web Services
Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F.
Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors.
World Wide Web Consortium, 05, June 2007. This version of the
specification of the Web Services Policy 1.5 - Framework
specification is http://www.w3.org/TR/2007/CR-ws-policy-20070605.
The <a href="http://www.w3.org/TR/ws-policy">latest version of Web
Services Policy 1.5 - Framework</a> is available at
http://www.w3.org/TR/ws-policy.

Web Services Policy 1.5 - Framework, A. S. Vedamuthu, D. Orchard, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors. World Wide Web Consortium, 05, June 2007. This version of the specification of the Web Services Policy 1.5 - Framework specification is http://www.w3.org/TR/2007/CR-ws-policy-20070605. The latest version of Web Services Policy 1.5 - Framework is available at http://www.w3.org/TR/ws-policy.

メディアタイプ「Media type」の登録

HTTPのHeaderの例 http://www.w3.org/TR/ws-policy/,headers

200 OK
Content-Length: 161386
Accept-Ranges: bytes
Expires: Thu, 14 Jun 2007 04:49:47 GMT
Server: Apache/1.3.37 (Unix) PHP/4.4.7
Last-Modified: Mon, 04 Jun 2007 00:57:49 GMT
Connection: close
Etag: "4663638d"
Cache-Control: max-age=21600
Date: Wed, 13 Jun 2007 22:49:47 GMT
P3p: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
Content-Type: text/html; charset=utf-8

メディアタイプ「Media type」の登録(続き)

その例は「WS Policy」のメディアタイプの登録

文書が正しいかどうかというときは…

インターネット標準の紹介

木曜日

インターネット標準の紹介

目的

XML関連の基本的な標準

ここでは触れない標準

XML関連の基本的な標準(続き)

ここでは触れない標準

スキーマ言語

ここでは触れない標準

XML 1.0

ここでは触れない標準

XML 1.0

ここでは触れない標準

XML Namespaces

ここでは触れない標準

名前空間の一例(繰り返し)

ここでは触れない標準

Web Service Policyの草案から

<wsp:Policy
 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
 xmlns:wsp="http://www.w3.org/ns/ws-policy" >
 <wsp:ExactlyOne>
...
  <sp:SignedParts>
...
  </sp:SignedParts/>
...
 </wsp:ExactlyOne>
</wsp:Policy>

XML Information Set

ここでは触れない標準

Web Services Policy Frameworkでも「XML Information Set」が使用される

If there is no wsp:Policy Element Information Item in the
[children] property, the assertion has no nested policy expression.

XPath 1.0

ここでは触れない標準

XPath は XML ドキュメントの表面的なシンタックスというよりは、
XMLドキュメントの抽象的論理的な構造をもとに機能する。
p/child::span

又は

p/span

XSLT 1.0

ここでは触れない標準

<p>...</p>
<段落>...</段落>

「XML 1.0」のDTDの主な問題点

ここでは触れない標準

  1. データー型が足りない
    例は、日時に関するデーター型「2007-06-14」が欲しい
  2. 要素の内容を制約することに関してはDTDの弱点がある
    <!ELEMENT a (b?,b)>
    は不可能
  3. 一般的な制約の作成が不可能
    例は要素の値の合計の制限 A + B = 100
<list>
 <A>100</A>
 <B>0</B>
</list>

データー型の問題の解決する「XML Schema」

ここでは触れない標準

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" ... >           
 <xsd:element name="root">                      
  <xsd:complexType>  
   <xsd:sequence>    
    <xsd:element name="A" type="xsd:integer"/>
    <xsd:element name="B" type="xsd:integer"/>      
   </xsd:sequence>
   <xsd:attribute name="revisionDate" type="xsd:date"/>
  </xsd:complexType>
 </xsd:element>
</xsd:schema>

要素の内容の制約の力を広がる「Relax NG」

ここでは触れない標準

<start>
 <element name="a">
  <optional>
   <ref name="b"/>
  </otional>
  <ref name="b"/>
 </element>
</start>

<define name="b">
 <element name="b">
  <text/>
 </element>
</define>

又は

element a { b? , b }
b = element b { text }

一般的な制約の表現できる「Schematron」

ここでは触れない標準

<sch:schema xmlns:sch="http://www.ascc.net/xml/schematron"> ...
 <sch:pattern ... >
  <sch:rule context="/root" ... >
   <sch:assert test="A + B = 100">
    The sum of the values of A and B must be 100.
   </sch:assert>
  </sch:rule>
 </sch:pattern>
</sch:schema>

どれを使えば良いか

ここでは触れない標準

適用分野による

成績評価(殆ど繰り返し)

一つのファイルで3-5ページを書いてください。枚数は重要ではありません。

インターネット標準の紹介

金曜日(更新版)

国際化の標準の一例
「Internationalization Tag Set (ITS) 1.0」

まとめ(1)

XMLの国際化とローカリゼーションに必要なマーク付け:

まとめ(2)

ITSをXML文書の中で適用「local」

<help xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> [...]
  <p>To re-compile all the modules of the Zebulon toolkit you need to go in the
    <path
     its:translate="no">\Zebulon\Current Source\binary</path> directory.
    Then from there, run batch file 
<cmd its:translate="no">Build.bat</cmd>.</p> [...]
</help>

ITSをXML文書以外で適用「global」(1)

<its:rules version="1.0">
 <its:translateRule selector="//path | //cmd" translate="no"/>
</its:rules>
<help> [...]
  <p>To re-compile all the modules of the Zebulon toolkit you need to go in the
    <path>\Zebulon\Current Source\binary</path> directory.
    Then from there, run batch file 
<cmd>Build.bat</cmd>.</p> [...]
</help>

ITSをXML文書以外で適用「global」(2)

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:langRule selector="//*[@langinfo] langInfoPointer="@langInfo"/>
</its:rules>

"Terminology"の一例

<doc its:version="1.0" xmlns:its="http://www.w3.org/2005/11/its">
 <section xml:id="S001">
  <par>A <kw its:term="yes" 
its:termInfoRef="http://en.wikipedia.org/wiki/Motherboard">motherboard</kw>,
also known as a <kw its:term="yes">logic <span its:term="yes">board</span></kw> on
Apple Computers, is the primary circuit board making up a modern computer.</par>
 </section> 
</doc>

"Elements within Text"の一例

<doc>
 <head>
  <its:rules version="1.0" xmlns:its="http://www.w3.org/2005/11/its">
   <its:withinTextRule withinText="yes" selector="//b|//u|//i"/>
   <its:withinTextRule withinText="nested" selector="//fn"/>
  </its:rules>
 </head>
 <body>
  <p>This is a paragraph with <b>bold</b>, <i>italic</i>, and <u>underlined</u>.</p>
  <p>This is a paragraph with a footnote
<fn>This is the text of the footnote</fn> at the middle.</p>
 </body>
</doc>

ルビの一例

<text xmlns:its="http://www.w3.org/2005/11/its">
 <head> ... 
   <its:rules version="1.0">
   <its:rubyRule selector="/text/body/img[1]/@alt">
    <its:rubyText>World Wide Web Consortium</its:rubyText>
   </its:rubyRule>
  </its:rules>
 </head>
 <body>
  <img src="w3c_home.png" alt="W3C"/> ...
  </body>
</text>

ITSの適用分野

関連情報

インターネット標準の紹介

金曜日(更新版)

RestのWebサービスのスライド

RestのWebサービスについてのスライドは主にテロ オリビエの指導で作成したものです。

開発者の視点

一例: 食器について

RESTの紹介

REST:食器の一例

すべとの食器は「リソース」です。課題「食器のカテゴリーを問う」

GET /?item=l387&action=getCategory HTTP/1.1
Host: silverware.example.org

SOAP

「WebサービスというのはURIで識別でき、インタフェースとバインディングがXMLを基に定義されるソフトの体系です。他のソフト体系がWebサービスを発見し、 インターネットプロトコルで転送されるXMLでの定義を使用し 相互作業を行うこともできます。」

Web Services Architecture - W3C Working Draft

SOAP:食器の一例 (実はSOAPは必要ではありません…)

すべての食器が食器のサービスによって囲まれる。課題「カテゴリを問う」:

POST /Reservations HTTP/1.1
Host: silverware.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
  <env:Body>
    <sw:getCategory
     env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
             xmlns:sw="http://silverware.example.org/swservice">
      <sw:item>l387</sw:item>
    </sw:getCategory>
  </env:Body>
</env:Envelope>

食事を楽しむか楽しまないかについて

フォークを使うフォークを使わない
楽しむ
楽しまない

SOAPかRESTかについて

SOAPSOAPではない
RESTful 可能 可能
RESTfulではない可能 可能

SOAPをRESTful的に使用する

できれば:

SOAPを REST的に使わない方がいい場合がある

一例:SOAP RESTでは対応できない食器のサービス

セキュリティーと信頼性「Reliability」を使い、食器のサービスを問う

<soap:Envelope ...>
  <soap:Header> ...
    <wsrm:UsesSequenceSTR soap:mustUnderstand="true"/> ...
  </soap:Header>

  <soap:Body>
    <wsrm:CreateSequence>
      <wsrm:AcksTo>
        <wsa:Address>http://silverware.example.org/swservice</wsa:Address>
      </wsrm:AcksTo>

      <wsse:SecurityTokenReference> ...
      </wsse:SecurityTokenReference>
    </wsrm:CreateSequence>
  </soap:Body>
</soap:Envelope>

一例:SOAP RESTでは対応できない食器のサービス

セキュリティーと信頼性の基になる標準:

WS-*のすべとを使うか使わないか?

SOAPを使わないで…

…もWebサービスを実現できる!
大切なことはサービスの記述 (コンピュータ処理用のサービス記述(WSDL、又は違うフォーマット)も人のためのAPIの記述も OK)

SOAPを使わない方がいい場合は

繰り返し:使わない方がいいSOAPの一例:

POST /Reservations HTTP/1.1
Host: silverware.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
  <env:Body>
    <sw:getCategory 
        env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
             xmlns:sw="http://silverware.example.org/swservice">
      <sw:item>l387</sw:item>

    </sw:getCategory>
  </env:Body>
</env:Envelope>

SOAPを使わない方がいい場合は(2)

SOAPの変わりに:

GET /?item=l387&action=getCategory HTTP/1.1
Host: silverware.example.org
Accept: application/soap+xml (又はtext/htmlなど)

SOAPを使わない方がいい場合は(3)

目的に相応しい道具を!

実装と適合性「conformance」

金曜日(更新版)

「conformance」の役割

QA Framework: Specification Guidelines から

Conformance is the fulfillment of specified requirements by a product, process, or service.
These requirements are detailed in a specification as part of a conformance clause
and in the body of the specification.

「conformance clause」の例「Web Service Policy

An element information item whose namespace name is
"http://www.w3.org/ns/ws-policy" and whose local part is
Policy or PolicyReference conforms to this specification
if it is valid according to the XML Schema [XML Schema Structures]
for that element as defined by this specification
(http://www.w3.org/2007/02/ws-policy.xsd) and additionally adheres to
all the constraints contained in this specification.
Such a conformant element information item constitutes a policy expression.

conformanceの主な特徴

「conformance clause」の例「BCP 47

適合条件のクラス「classes of conformance」

  1. check for well-formed language tags
  2. validating language tags

1も2もある理由は、1は基本的な実装で、2は実装が1より難しい

「conformance clause」の例「ITS 1.0

二つの適合条件のタイプがある理由は、「ITS 1.0」を使う適用分野が様々

抗議「objection」

金曜日(更新版)

抗議「objection」の趣旨

objectionの取り扱い(注意:W3Cだけに当てはまる)

どうしても合意ができない場合

特許方針

金曜日(更新版)

背景

W3Cの特許方針「patent policy」

W3Cの特許方針に関する文書

IETFの特許方針

The Tao of IETF から

OASISの特許方針

主な資料は http://www.oasis-open.org/who/intellectualproperty.php

ISO/IECの特許方針

特許方針の「厳しさ」が必要かどうか

  1. W3Cの厳しい特許方針を優先する組織もいる
  2. W3Cの特許方針の「厳しさ」でW3Cの活動に参加しない組織もいる

なぜかというと

難しい人「difficult people」

金曜日(更新版)

難しい人「difficult people」

このテーマの背景は、
http://producingoss.com/html-chunk/difficult-people.html
を読んでください

「Difficult People」の定義

「Difficult People」の問題を解決するとき…

解決のステップ

  1. まず、何もしなで、「difficult」の問題をそのままにしてなくなってしまうことを祈る
  2. 次に、ある人が「difficult」である、という証明を集める
  3. 個人的にワーキングループの参加者と問題について相談する
  4. 「difficult」の問題を公開し、解決する

「Difficult People」の問題が解決した一例

ステップ4、解決の鍵になったメールから

In the last 25 days, the top 6 posters to the svn [dev|users] list have
been:
    294  kfogel@collab.net
    236  "C. Michael Pilato" <cmpilato@collab.net>
    220  "J. Random" <jrandom@problematic-poster.com>
    176  Branko Čibej <brane@xbc.nu>
    130  Philip Martin <philip@codematters.co.uk>
    126  Ben Collins-Sussman <sussman@collab.net>
I would say that five of these people are contributing to Subversion
hitting 1.0 in the near future.

まとめ

まとめ

まとめ(続き)

まとめ(続き)

まとめ(続き)

お疲れ様でした

標準を読むとき、本講義の資料を使ってください。

本講義の資料のミス、資料を書いて欲しいなどのコメントがある人は、ご連絡ください。