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

佐々木フェリクス, W3C

資料と本講義について

スライド http://www.w3.org/2008/Talks/0602-naist-fs/

本講義の目的

「標準化」の説明
インターネット技術の主な標準の紹介

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

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

本講義の構造

月曜日

標準化の旨趣について
標準化の組織
- ISO、IEC（特にJTC1）
- W3C
- IETF
- など

本講義の構造

月曜日（続き）

標準化の一般的な過程
- 標準の概要の記述「charter」
- ワーキングループ（TC）が作成する文書
- 対象外のテーマ
- Liaison（共同作業）
- 過程を定める標準組織ごとの規則
標準化のツール

本講義の構造

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

新しい技術の標準化の記述「charter」を提案
日本語でも英語でもOK
宿題の目的は
- charter の一般的な構造を適用
- 対象外「out of scope」、liaison「協調作業」などの定義

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

本講義の構造

木曜日

宿題の分析
標準の「言葉」と「スタイル」
インターネット標準の紹介
- XML関連の標準
- 国際化の標準
- Webサービス
- など

本講義の構造

金曜日

tbd :)

成績評価

レポートと出席状況により評価する
レポートの内容
- 新しい標準の charter （水曜日までの宿題が基になる charter）
- 標準の分析（その対象、標準の文書のスタイル、その質のレベル、普及率など)

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

自己紹介

ドイツ生まれ
ベルリン自由大学、名古屋の南山大学、東京大学でドイツ言語学、日本語を専攻
ドイツのビーレフェルト大学で博士課程
（テーマは、多言語のデーターに XML、 RDF などのインターネット標準を適用する方法）
2005年、「World Wide Web Consortium(W3C)」に就職
慶応義塾大学で W3C の国際化活動とWebサービス活動を担当

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

BCP 47、Web Services Policy、Unicode

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

BCP 47
言語を識別するタグ「Tags for Identifying Languages」とタグのマッチ「Matching of Language Tags」の標準
IETF (Internet Engineering Taskforce)が担当
標準のユーザーも標準化に参加する一例

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

Web Services Policy 1.5 - Framework
Webサービスの相互作業の際の条件、サービスの性質を定義するフォーマット
W3Cが担当
主に、企業が標準化に参加する一例

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

ISO/IEC 10646（Unicode）
文字コードの国際的な標準
JTC1/SC2/WG2が担当
国々も標準化に影響する一例

標準化の旨趣について

月曜日

標準化の旨趣について
標準化の組織
- ISO、IEC（特にJTC1）
- W3C
- IETF
- など

標準化の目的

標準化の目的
標準の種類
標準化活動に参加する企業、ユーザーのコミュニティー

標準化はつまらない！

どうしましょう

ちょっと変わったテーマにしましょう

デジタル化されたバナナを標準にしましょう

Banane

標準の対象：色、味、バナナを包む方法など
バナナの例にご注意ください

標準化の目的

国内、国際の品物、サービスの交換などを支える
バナナを包む方法を標準化する
合理化色の種類を標準化
互換性バナナの箱の形を標準化する
情報交換バナナの説明書を標準化する
など

標準化と革新の関係

革新: 世界各地でバナナを開発
採用: 世界中でバナナを販売
標準化: バナナ自体、箱などを標準化する

実際の例：アメリカ鉄道の標準化

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

標準化の目的

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

アメリカの鉄道は適用された、多数の技術の相互採用が目的。
技術革新>採用>標準化
HTMLは標準化の結果で、標準の適用率が上がる。
技術革新>標準化>採用

実際の例：アメリカ鉄道の標準化

-	鉄道	HTML
1)	革新	革新
2)	採用	標準化
3)	標準化	採用

標準化の歴史

カレンダーの標準化（エジプト）
単位の標準化（エジプト、バビロン）
販売で標準を採用
国内、国際的な標準組織

１９世紀で工業化

標準がもっとも必要になる

鉄道
消火栓
など

技術の普及が標準化の原因になる

１９世紀から現代へ

国際的な標準化（電子工学、情報科学など）

ITU（1865）
IEC （1906）
ISO （1947）

ITの標準化

IETF（1986）
W3C （1994）
OASIS（1993） (SGML Open)
Unicode（1988）

標準の種類

標準化の目的
標準の種類
標準化活動に参加する企業、ユーザーのコミュニティー

標準の種類

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

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

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

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

デジュリス
- バナナのISO標準
デファクトスタンダード
- ISO標準ではないが、だれでも食べるバナナ

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

「BCP 47」はデジュリスタンダーからデファクトスタンダードへ
「Web Services Policy」はデファクトスタンダードからデジュリスタンダーへ
「ISO/IEC 10646（Unicode）」は両方同時にもなった

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

プロプライエタリ
- 誰でもだべるバナナ
オープン
- 食べる人、販売する人、作る人が標準化するバナナ

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

プロプライエタリソフトウェアは使用が法律により制限される
プロプライエタリソフトウェアの例は「FLASH」
オープンソフトウェアの例は「SVG」のプラグイン
デファクトスタンダードがプロプライエソフトウェアの基になることが多い
デファクトスタンダードがデジュリスタンダードとその実装の普及に害を与えることもある

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

「BCP 47」も「Web Services Policy」も「ISO/IEC 10646（Unicode）」もオープンな標準
ただし、標準が使用されるソフトは様々
- 「BCP 47」オープンな実装もプロプライエタリの実装もある
- 「Web Services Policy」は殆どプロプライエタリの実装しかない
- 「ISO/IEC 10646（Unicode）」オープンな実装もプロプライエタリの実装もあるがプロプライエタリの実装の方が多い

標準化活動に参加するグループ

標準化の目的
標準の種類
標準化活動に参加する企業、ユーザーのコミュニティー

「BCP 47」

言語タグを使用する企業の例はGoogle、Yahoo!などのインターネット企業
HTMLページを作成する人も使用

<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」を定義するワーキングループの会員になるのには

IETFのメールリストの登録だけで済む

「Web Services Policy 1.5」

「Web Services Policy 1.5」の実装は大企業のWebサービスのツールしかない
HTMLページの作成者は関係も興味もない
「Web Service Policy Working Group」の参加者も大企業が多い

「ISO/IEC 10646（Unicode）」

実装が難しい
だが、使う人が多い
Unicodeの会員活動が幅広い

標準化の組織

月曜日

標準化の旨趣について
標準化の組織
- ISO、IEC（特にJTC1）
- W3C
- IETF
- など
標準化のツール

標準化の範囲

業界の違い
- バナナとりんごの標準
国際と国内の違い
- 日本とアメリカのバナナ

標準化の範囲

業界の違い
- IETF vs. W3C vs. OASIS
国際と国内の違い
- JIS
- ISO/IEC

「10間」存在する組織

特定の分野の組織は10年がたってなくなることがある
その分野の標準活動が終わり、組織の課題がなくなる

国内と国際的な組織

国内と国際的な組織
NSBとSDO
組織の紹介（まとめ）

国内と国際的な組織

国際（ISOなど）と国内（JISCなど）の組織
特定の技術を中心とする組織（W3C、IETFなど）
特定の業界を中心とする組織(例はローカリゼーションを中心とするLisa「Localization Industry Standards Association」)

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

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

１)国際標準２）それを使用する国際標準３）それを使用する国内標準４）それを使用する文書

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

国内の標準XML 日本語プロファイル（JIS TR X 0015）は標準
JIS TR X 0015が英語訳される、W3Cの文書XML Japanese Profileは単なる文書

違いは合意「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から）

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

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

「BCP 47」も「Web Services Policy」も「ISO/IEC 10646（Unicode）」も国際的な標準
ただし、「ISO/IEC 10646（Unicode）」は国内の標準機関「National Standards Body (NSB)」も標準化活動に参加する

NSBとSDO

国内と国際的な組織
NSBとSDO
組織の紹介（まとめ）

NSBとSDOの関係

NSB「National Standards Body」
- 国営
- 民営
- 両方
SDO「Standards Developing Organization」
SDOがNSBの会員になる
SDOがNSBの標準活動の開始などを指導する
NSBがISOとIECの会員になる

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

ISO/IECの標準からW3C、IETFなどの標準などを参照することが簡単ではない…
ISO/IECのJTC1は他組織の標準の引用に関する規則がある
「Approved RS Originator Organization (ARO)」の資格が必要
次に、AROの組織の標準を引用する「RS Referencing Explanatory Report (RER)」が必要

組織の紹介（まとめ）

国内と国際的な組織
NSBとSDO
組織の紹介（まとめ）

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

標準化活動のテーマ
組織の構造
他組織の共同作業

ISO/IEC、JISC

標準化活動のテーマは「すべて」
組織の構造、国々の組織が会員。標準の文書を売ることがISO/IECの基になる
他組織の共同作業、制限される

W3C

標準化活動のテーマ、インターネットの標準HTML、XMLなど
組織の構造、会員組織
他組織の共同作業

OASIS

Organization for the Advancement of Structured Information Standards

標準化活動のテーマ、W3Cなどの標準を利用するアプリケーションの標準
（但し、例外もある）
組織の構造、会員組織
他組織の共同作業、たくさんある

IETF

標準化活動のテーマ、インターネットプロトコル（HTTP、BCP 47など）
組織の構造、会員組織ではない
他組織の共同作業、W3CなどがIETFの標準を利用する。BCP 47がその一例

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

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

Web Services-Interoperability Organization

標準化活動のテーマ、Webサービスの相互採用
組織の構造、会員組織（Webサービスの企業）
他組織の共同作業、あまりない

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

Web Hypertext Application Technology Working Group

標準化活動のテーマ、HTMLの標準化
組織の構造、主にメールリスト
他組織の共同作業、あまりない

WS-IとWHAT-WGの共通点

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

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

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

標準化の一般的な過程

月曜日（続き）

標準化の一般的な過程
- 標準の概要の記述「charter」
- ワーキングループ（TC）が作成する文書
- 対象外のテーマ
- Liaison（共同作業）
- 過程を定める標準組織ごとの規則
標準化のツール

標準化の一般的な過程

標準の概要の記述「charter」
ワーキングループ（TC）が作成する文書
対象外のテーマ
Liaison（共同作業）
過程を定める標準組織ごとの規則

charterのー例

W3CのWeb Services Policy Working Groupのcharter
IETFの「BCP 47」を標準化する「LTRU]のcharter

目的の記述

Web Service Policy
- 非常に細かい記述
BCP 47
- 存在する標準との関連性が重要

ワーキングループ（TC）が作成する文書

Web Service Policy
- W3Cの標準「Recommendation」実装の実験スイートなど
BCP 47
- IETFの標準「Best Common Practice」（他の種類もある）

対象外のテーマ

Web Service Policy
- 「目的」ぐらいたくさんある
BCP 47
- あまりない

Liaison（共同作業）

Web Service Policy
- W3CのワーキングループとOASISのTC
BCP 47
- 特に、ISOの標準「ISO-639-3」

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

W3C
- W3C Process Document
IETF
- TAO of IETF（IETFの標準化活動の過程のまとも）

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

草案のステップ、Ｗ３Ｃの例
- Ｆｉｒｓｔ　Ｐｕｂｌｉｃ　Ｗｏｒｋｉｎｇ　Ｄｒａｆｔ
- Last Call Working Draft
- Candidate Recommendation
- Proposed Recommendation
- Recommendation

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

標準組織の機関、Ｗ３Ｃの例
- Working Groups
- Advisory Committee
- W3Cのスタッフ
- など

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

問題が起こる場合の対策を決める規則
問題の例
- 合意が得ないといけない期間「Last Call」
- 実装がないといけない期間「Candidate Recommendation」

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

本講義の構造

月曜日（続き）

標準化の一般的な過程
- 標準の概要の記述「charter」
- ワーキングループ（TC）が作成する文書
- 対象外のテーマ
- Liaison（共同作業）
- 過程を定める標準組織ごとの規則
標準化のツール

標準化のツール

コミュニケーションのツール（メール、IRC、電話会議など）
「Action item」
コメント
「balloting」
文書の作成
文書のチェック

標準化のツール

コミュニケーションの手段

メール
電話会議
Face-to-face会議

大変な問題「電話会議の時間」

参加者による
夜中の電話会議はどうしても避けられない

W3Cのツールの紹介

IRCの利用 (Internet Relay Chat)
キュー（queue）が大事
IRC BOTs
- Zakim（queueの管理、電話会議の管理）
- rrsagent action itemsと議事録（minutes）の管理

Queueの例

[2007/07/18 0:47] <scribe> A : the same examples are in the primer
              [2007/07/18 0:48] <scribe> B: the value of keeping this section ...
              [2007/07/18 0:48] <C> q+ to respond to B on why ...
              [2007/07/18 0:48] * Zakim sees C on the speaker queue
              [2007/07/18 0:49] <scribe> B: what's the value of documenting this?
              [2007/07/18 0:51] <scribe> D: the pain WSAaddressing group was so big
              that it would be helpful to show how they came to the right solution
              [2007/07/18 0:52] <pbc> q?
              
              [2007/07/18 0:52] * Zakim sees C on the speaker queue
              [2007/07/18 0:52] <pbc> ack C
              [2007/07/18 0:52] * Zakim sees nobody on the speaker queue

問題点とAction items

Issue 7: バナナの形の定義が不明確

Action: Felixがと定義を書く直さなければならない

Issue tracking via Bugzilla
Issue / action item tracking via Tracker
ツールはたくさんある…

Ballot

組織によってBallotのやり方が違う
W3Cは会員組織ごとにBallotを行う
Disposition of comments の例

合意をIRCで書き残す

[2007/07/18 0:15] <A> Proposal for 4661/4662:
              [2007/07/18 0:16] <A> 1. Adopt changes in 4661 taking into consideration 
              the 4854 change for @any and the BP from B's ACTION-304.
              [2007/07/18 0:16] <A> 2. Adopt change in 4662 taking into consideration 
              the real time edits done on Jul 17 during the meeting (checked in CVS).
              [2007/07/18 0:17] <A> 3. Adopt the change to the remaining text in 5.6.1
              based on proposal from Monica in message Jun/0088.html
              
              [2007/07/18 0:18] <D> RESOLUTION: issue 4661 and 4662 
                  closed with above proposal
                  [2007/07/18 0:18] <D> rrsagent, where am i?
 [2007/07/18 0:18] <RRSAgent> See
 http://www.w3.org/2007/07/17-ws-policy-irc#T15-18-24

文書の作成

XMLフォーマット「XMLSPEC」
W3C文書に使いやすい「tag」

<spec ...
              <w3c-designation>banane5 ...
              <w3c-doctype>W3C Candidate Recommendation ...
              
              <status> ...

HTMLに変換
Diff文書も必要

文書のチェック

チェックOKではない文書は公開できない…

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

新しい技術の標準化の記述「charter」を提案
日本語でも英語でもOK
宿題の目的は
- charter の一般的な構造を適用
- 対象外「out of scope」、liaison「協調作業」などの定義

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

予定変更

宿題の分析は金曜日になる
今日は：
- 標準の「言葉」と「スタイル」
- XMLの基本
- XMLの語彙（時間が足りましたら…）
- 国際化の標準（時間が足りましたら…）

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

文書の識別、バージョン情報
URIの安定性「cool URI's don't change!」
名前空間の重要性
「cool」ではないURIの例
国際化の要求
文章の構造

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

必要な章
W3Cの草案の「status section」の読み方
マーク付けの使い方
正誤表「Errata」
RFC2119のケーワード
Normativeとnon-normativeの違い

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

正式的な記法
参考文献と参照
メディアタイプ「Media type」の登録
文書が正しいかどうかというときは…

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

例「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/

ステップの情報「CR」（Candidate Recommendation）
識別名「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に関する態度が違う

IETF Internet-Drafts

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>

名前空間の定義「xmlns:sp="..."」
名前空間プリフィックスの使用「<wsp:ExactlyOne>」、又は「<sp:SignedParts>」

URIs for W3C Namespaces

URIs for W3C Namespacesの規則

名前空間のURIの種類
- http://www.w3.org/ns/ssss
- http://www.w3.org/YYYY/MM/ssss
名前空間の記述「Namespace Document」

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

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

「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の文字コードを参照する方法

codepoint U+002E
Unicode name full stop
Unicode alias dot

国際化の要求

日時の書き方

正しい書き方の例は「2007-03-30」、又は「30 March 2007」
正しくない書き方の例は「5/6/03」（その解釈は「5月6日」も「6月5日」もあり得る！）
日付の詳細の説明は「XML Schema Part 2: Datatypes」を確認

国際化の要求

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

米国にこだわる例「ZIP code」より一般的な例を使う「postal code」
キーワードをマーク付ける

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

人称代名詞「personal pronoun」の使用を避ける
http://www.mycompany.com を日本語にどう翻訳したらいいのか

文章の構造

例は「Web Services Policy 1.5 - Framework」

草案の題名と種類
バージョン情報
編集者「editors」
著作権の情報
まとめ「abstract」

文章の構造（続き）

status section
本文
- 規定「normative」の章
- 他「non-normative」の章
附属書
- 規定の参考文献
- 他の参考文献
- 変更履歴「changelog」

必要な章

IETFの草案の「security considerations」（例は「BCP 47」）
W3Cの草案の「status section」
適合性「conformance」の定義（例は「Web Services Policy」）

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

例は「Web Services Policy 1.5 - Framework」

草案の種類、例えば「Candidate Recommendation」
「Candidate Recommendation」の場合は、実装が確実ではない特徴「features at risk」
「Candidate Recommendation」の場合は、実装のまとめへのリンク「implementation report」
ワーキングループの名前

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

例は「Web Services Policy 1.5 - Framework」

草案の最終的なステップ、例えば

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

コメントする方法の説明
特許方針の参照

マーク付けの使い方

言語の識別
<html lang="en-US" xml:lang="en-US">
CSSの使い方に注意する（例えば普段のCSSスタイルシートの参照）

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

<font>タグを使用しない
など

正誤表「Errata」

「Recommendation」というWeb標準にもミスがある
標準の更新版をすぐには公開できないが、正誤表「Errata」が作れる
例は
- 「Internationalization Tag Set (ITS) Version 1.0」
- そのErrataへのリンク

RFC2119のケーワード

RFC2119から（日本語訳もある）

「MUST」は「仕様の絶対の必要条件」
「MUST NOT」は「絶対の禁止令」
「SHOULD」は「特定のアイテムを無視する理由もあるかもしれない」
「SHOULD NOT」は「特定のアイテムの禁止令を無視する理由もあるかもしれない」
「MAY」は「本当にオプショナル」

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の違い(続き）

non-normativeの説明が必要かどうか
「Web Service Policy」の場合は、
- 規定の文書も
- その他の文書も
ある
non-normativeの説明があるかどうかは、ワーキングループの人事にもよる

正式的な記法

BNFを使う標準「BCP 47」
XMLの要素「element」と属性「attribute」を使用し、スキーマの概要「schema outline」を使う「Web Service Policy」
CSSもBNFを使うが、本文の中ではない

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

参考文献と参照

標準は草案を「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」の登録(続き）

標準が定義するフォーマットをHTTPなどのプロトコルで送受信する場合、フォーマットのメディアタイプの登録が必要

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

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

manual of styleで確認する
「Pubrules checker」の使用

XMLの基本

謝辞

XMLの基本についてのスライドはMike Smithが英語で作成し、私が翻訳したものです。

Mike Smithのスライドは下記のURIにあります。

http://www.w3.org/2008/Talks/05-01-smith-xml/

XMLの定義

XMLは「木構造」

木構造の例

<html>
 <head>
  <title>A tree</title>
 </head>
 <body>
  <p>This is a tree too.</p>
 </body>
</html>

XMLの基本的な概念

整形式のXML文書(well-formed XML document)。整形式制約(well-formedess constraints)。
妥当なXML文書(valid XML document)。妥当性制約(validity constraints)。

整形式

Ｘ <p>hoge
Ｘ <p>moge
〇 <p>hoge</p>
〇 <p>moge</p>

整形式

Ｘ <i><b>hoge</i></b>
Ｘ <i>
     <b>hoge</i>
   </b>

〇 <i><b>hoge</b></i>
〇 <i>
     <b>hoge</b>
   </i>

整形式

Ｘ <img src="hoge.png">
〇 <img src="hoge.png"/>

整形式

Ｘ <input disabled/>
〇 <input disabled="disabled"/>

Ｘ <input value=yes/>
〇 <input value="yes"/>
〇 <input value='yes'/>

整形式

Ｘ <p>a & b</p>
〇 <p>a & b</p>

Ｘ <p>a < b</p>
〇 <p>a < b</p>

スキーマの宣言（例：DTD）

<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
 <head>
  <title>A tree</title>
 </head>
 <body>
  <p>This document is a tree.</p>
 </body>
</html>

妥当性制約を記述するスキーマ言語

DTD (old way)
W3C XML Schema (new way)
RELAX NG (another new way)

XMLの他の特徴

符号化宣言(encoding declaration)
文字参照(character references)
実体参照(entity references)
名前空間(namespaces)

符号化宣言(encoding declaration)

<?xml version="1.0" encoding="Shift_JIS"?> 
<html>
 <head>
  <title>A tree</title>
 </head>
 <body>
  <p>このドキュメントは「tree」です.</p>
 </body>
</html>

文字参照(character references)

<p>This is a middle dot: ·</p>

表示は:

<p>This is a middle dot: ·</p>

実体参照(entity references)

<p>This is a middle dot: ·</p>

表示は:

<p>This is a middle dot: ·</p>

名前空間(namespaces)

XML語彙のテーマになります

問題

自分のXML文書を作ってください
テーマは
1. 学生の名簿
2. 詩

要素（element）、属性、コンテンツを使ってください。

XML語彙

XML語彙の例
XML語彙の例から一般的な定義へ
XML語彙の過去、現在と将来

XML語彙の例

XHTML 1.0
DocBook
ITS 1.0
Web Services Policy

XHTML 1.0

「HTML」の言語の一種
Web文書の言語

XHTML 1.0文書の例

<!DOCTYPE html
 PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
 "http://www.w3.org/TR/XHTML1/DTD/XHTML1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/XHTML">
 <head>
  <title>XML語彙</title>
   文書のメタデーター
... 
 </head>
 <body>
   文書のコンテンツ
 </body>
</html>

XHTML 1.0の適用分野

ブラウザー
但し、XHTML 1.0ではなく、HTML4.01の文書が多い
過去のHTML：ただのページ
現在と将来のHTML：ブラウザーでのアプリケーション

DocBook

対象は説明書などの技術的な文書
「Single Source Publishing」の一例

DocBook文書の例

<article xmlns="http://docbook.org/ns/docbook" version="5.0">
 <info>
  <title>Sample article</title>
 </info>
 <section>
  <title>Sample section</title>
  <para>You can delete file using <function>unlink()</function>
     function.</para>
 </section>
 </article>

文書の構造を反映
表示ではなく、意味又は機能を表すタグ

DocBookの発展

SGMLの語彙からXMLへ
現在はDocBook 5.0
語彙の定義は現在はRELAX NGによる

ITS 1.0

XML文書追加する語彙
目的は文書の国際化、ローカリゼーション

ITS 1.0文書の例:翻訳可能不可能の区別

<article xmlns="http://docbook.org/ns/docbook" version="5.0"
 xmlns:its="http://www.w3.org/2005/11/its">
 <info>
  <title>Sample article</title>
 </info>
 <section>
  <title>Sample section</title>
  <para>You can delete file using <function its:translate="no">unlink()</function>
     function.</para>
 </section>
 </article>

翻訳不可能

ITS 1.0処理の結果（例）

<article xmlns="http://docbook.org/ns/docbook" version="5.0"
 xmlns:its="http://www.w3.org/2005/11/its">
 <info>
  <title>Xxxxx</title>
 </info>
 <section>
  <title>Xxxxx</title>
  <para>Xxxxx<function its:translate="no">unlink()</function>
     Xxxxx</para>
 </section>
 </article>

翻訳不可能部分だけが残る文書の生成

Web Services Policy

SOAPによるWebサービスの分野に使用されるXML語彙
目的はWebサービスの開始に必要な条件を記述する
開始に必要な条件の例はセキュリティーの条件を記述する

Web Services 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>
  <wsp:All>
Webサービスの開始の条件（１）
  </wsp:All>
  <wsp:All>
Webサービスの開始の条件（２）
  </wsp:All>
 </wsp:ExactlyOne>
 </wsp:Policy>

Webサービスを開始するのには「ExactlyOne」（条件一つだけ）を満たさなければならない

Web Services 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>
  <wsp:All>
   <sp:SignedParts>
    <sp:Body/>
   </sp:SignedParts>
  </wsp:All>
  <wsp:All>
   <sp:EncryptedParts>
    <sp:Body/>
   </sp:EncryptedParts>
  </wsp:All>
 </wsp:ExactlyOne>
 </wsp:Policy>

XML語彙の例から一般的な定義へ

語彙の分類

適用分野
実装の環境
語彙の区別
語彙の定義（１）スキーマ言語
語彙の定義（２）データーモデルと語彙の意味（処理の記述）

適用分野

人間が読む文書
機会処理用のデーター
他の語彙と一緒に使う語彙
そのまま使えるXML語彙

適用分野

人間が読む文書：XHTML, DocBook, ITS 1.0
機会処理用のデーター：Web Services Policy, ITS 1.0
他の語彙と一緒に使う語彙：Web Services Policy, ITS 1.0
そのまま使えるXML語彙：XHTML, DocBook
他の語彙と一緒に使う語彙もできる：XHTML, DocBook

実装の環境（１）：文書の作成

XHTML：XHTML専用のエディター
DocBook：普通のXMLエディター、又はDocBook専用のエディター
ITS 1.0：普通のXMLエディター
Web Services Policy：Webサービス専用のエディター、又は自動生成

実装の環境（２）：文書の処理

XHTML：Webブラウザー
DocBook：普通のXMLプロセッシング
ITS 1.0：普通のXMLプロセッシング
Web Services Policy：SOAPによるWebサービスの実装

語彙の区別（１）名前空間と修飾された名前

名前空間「namespaces」と修飾された名前「qualified names」

<article xmlns="http://docbook.org/ns/docbook" version="5.0"
 xmlns:its="http://www.w3.org/2005/11/its">
 <info>
  <title>Sample article</title>
 </info>
 <section>
  <title>Sample section</title>
  <para>You can delete file using <function its:translate="no">unlink()</function>
     function.</para>
 </section>
 </article>

XML名前空間の構文

namespaceの宣言

xmlns ( :接頭辞 ) ="名前空間 URI"

xmlns:db="http://docbook.org/ns/docbook"

qualified name

( 接頭辞: )  ローカル名

db:article

語彙の区別（２）バージョンの区別

名前空間で語彙のバージョンを区別する例もあるが
バージョンを識別するメカニズムは大体は語彙による

HTML？

DocBook：

<article xmlns="http://docbook.org/ns/docbook" version="5.0"> ...

ITS 1.0 ：

... its:version="1.0" ...

Web Services Policy：名前空間の使用

語彙の定義（１）スキーマ言語

妥当性の検討
「妥当性」という概念はスキーマ言語によって違う

主な XML スキーマ言語

DTD: XML 1.0/1.1 に含まれるスキーマ言語
W3C XML Schema: W3C により策定されたスキーマ言語
RELAX NG (ISO/IEC 19757-2 / JIS X 4177-2): ISO で Document Schema Definition Languages (DSDL) Part 2 として標準化
Schematron (ISO/IEC 19757-3): XPath を使って規則を表現するスキーマ言語; ISO で DSDL Part 3 として標準化
Namespace-based Validation Dispatching Language (NVDL) (ISO/IEC 19757-4): RELAX Namespace などを元に策定された、名前空間に基づき検証の委譲を行うスキーマ言語; ISO で DSDL Part 4 として標準化

DocBook文書の例（繰り返し）

<article xmlns="http://docbook.org/ns/docbook" version="5.0">
 <info>
  <title>Sample article</title>
 </info>
 <section>
  <title>Sample section</title>
  <para>You can delete file using  
  <function>unlink()</function> function.</para>
 </section>
 </article>

<article>の定義

DTDの例

要素の宣言：要素の名前と内容モデル

<!ELEMENT article (info, section+)>

属性の宣言：属性の名前、型、ステータス

<!ATTLIST article
 version CDATA #REQUIRED
  xmlns CDATA "http://docbook.org/ns/docbook" 
  xmlns:db CDATA "http://docbook.org/ns/docbook"

注意：DTDは名前区間の使用が問題がある

属性の重要な型

属性の型:

CDATA
ID
IDREF
IDREFS
ENTITY
ENTITIES
NMTOKEN
NMTOKENS
NOTATION
列挙属性

RELAX NG と XML Schema では、要素にも当て嵌められる

XML Schemaの例

<xs:schema
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://docbook.org/ns/docbook"
 xmlns:db="http://docbook.org/ns/docbook">
 <xs:element name="article">
  <xs:sequence>
   <xs:element name="info" type="db:infoType"/>
   <xs:element name="section" type="db:sectionType"/>
  </xs:sequence>
  <xs:attribute name="version" type="xs:string"/>
 </xs:element>
...
</xs:schema>

主な特徴：ユーザーが定義できる型の定義

RELAX NGの例（XML構文）

<grammar ... >
  <define name="article">
    <element name="db:article">
      <ref name="version"/>
      <ref name="info"/>
      <oneOrMore>
        <ref name="section"/>
      </oneOrMore>
    </element>
  </define>
  <define name="version">
    <attribute name="version"/>
  </define>
...
</grammar>

主な特徴：パターンで要素と属性の取り扱いがほぼ同じで、複雑な内容モデルが自由に定義できる

Schematronの例

<sch:schema
  xmlns:sch="http://www.ascc.net/xml/schematron" > 
 <sch:pattern
   name="DocBook constraints check">
  <sch:rule context="article">
   <sch:report
 test="@version[.='3.1'] and namespace-uri()!='']">
 DocBook version 3.1 does not use a namespace</sch:report>
  </sch:rule>
 </sch:pattern>
 </sch:schema>

主な特徴：構文用のスキーマ言語で検討できない「constraints」の検討

スキーマで複合文の検討

DTDでは名前空間の使用範囲が乏しく、難しい
XML SchemaとRELAX NGでは可能ではあるが、複雑なスキーマだと複合文用のスキーマの作成が難しい
解決方法：NVDL

NVDLでXHTMLとITS 1.0の複合文書を妥当

<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"
       startMode="xhtml">
  <mode name="xhtml">
    <namespace ns="http://www.w3.org/1999/xhtml">
      <validate schema="../xhtml-schemas/xhtml11.xsd">
        <context path="head" useMode="its-rules"/>
      </validate>
    </namespace>
    <namespace ns="http://www.w3.org/2005/11/its" match="attributes">
      <validate schema="its-attributes-for-xhtml.rng"/>
    </namespace>
  </mode>
  <mode name="its-rules">
    <namespace ns="http://www.w3.org/2005/11/its">
      <validate schema="its-rules.rng"/>   
    </namespace>
  </mode>
</rules>

スキーマ言語はどれにしましょうか

DTDはまだ一番普及している
RELAX NGは人間が読む文書のスキーマに最適
XML Schemaはデーターベース、プログラミング言語交換に最適
Schematronは構文用のスキーマ言語に加えて使う
NVDLは多スキーマの複合に便利
（注意：特にXML Schemaにもスキーマの複合に便利なメカニズムもある）

スキーマ言語の発展

語彙の定義（２）データーモデルと語彙の意味（処理の記述）

XMLの基本的なデーターモデル

DOM (Document Object Model)
ブラウザーなどにとって便利なAPI
Information Set
一般的なデーター処理
XML Schemaデーターモデル
データーベースなどに便利
XQuery 1.0 and XPath 2.0 Data Model
XML Schemaデーターモデル＋…

語彙の意味（処理の記述）

語彙によって同じようなタグの「意味」が違う
例はXHTMLの<p>とDocBookの<para>
アプリケーションが意味の元になる

XML語彙の定義の層

XML語彙の過去、現在と将来

過去：複雑なXML語彙がたくさん定義された
現時：自分の定義より、大切なXML語彙の使用がお勧め
例：XHTML、DocBook、Atom
将来：XML語彙の複合文がもっと普及される

宿題の分析

Topics

mobile phones (keyboard layout etc.)
paper sizes
emoji
packages (paper etc.)
food and their packages (apples, bananas, ikinari dango, ...)
garbage

Topics

pencils
information about food supply
eco life
time information standardization
electric money
scissors

Topics

network games
beautiful woman(!?!)
...

新たな宿題

自分で標準を選んで、標準の「言葉」と「スタイル」を分析して下さい。
本講義の「言葉」と「スタイル」についての説明を参考にして下さい。
来週、水曜日（2008-06-11）までご提出（fsasaki@w3.org）下さい。
ページの枚数は１－３枚でお願いします。

国際化

概要

国際化の趣旨
Webの国際化の対象
Webの国際化の現状と将来
リンク集

国際化「Internationalization」の趣旨

「国際化」はどこでも、だれでも使えるように製品などを作成する過程
国際化と関連する「ローカリゼーション」はその製品をある地域や国、言語などに適応する過程

国際化とローカリゼーションの一例

自動車の国際化はハンドルを右側にも左側にも付けられるように車工場で準備する
自動車のローカリゼーションはハンドルを
- 右に付ける（日本のためのローカリゼーション）
- 左に付ける（ドイツのためのローカリゼーション）

国際化「Internationalization」の趣旨（続き）

ITの国際化は「ソフト」という製品の準備
ITのローカリゼーションはソフトの適応
Webの国際化、又はローカリゼーションはWebに必要なすべてのものが対象になる
つまり、この講義のテーマは殆どが国際化の対象になる

概要

国際化の趣旨
Webの国際化の対象
Webの国際化の現状と将来
リンク集

Webの国際化の対象

文字と文字コード
文字の処理
文字、又はテキストの表示
テキストの追加情報「ルビ」
テキストの組版

Webの国際化の対象（続き）

言語の識別と言語タグのマッチ
言語とロケールの違い
Webサービスの国際化
XMLの国際化

文字とは

文字は書き言葉の最も小さい部分。それに関連する概念は

文字符号化「character encoding」
例えば「雪」という文字の Unicode の符号化「code point」はU+96EA
文字を表示するためのイメージ「glyph」
- U+96EAを日本のglyphで表示する雪 ja
- U+96EAを韓国のglyphで表示する雪 ko

glyphの表示の集合「font」
文字の発音
など

文字の国際化の基「Unicode」

世界の「すべて」の文字集合を定義
文字符号化も定義
本講義で紹介されたWeb標準にも使用
- HTTP
- URI、又は「IRI」
- XMLと関連の標準XPath、XSLTなど
- SSML
- など

文字符号化方式とは

Character Encoding Scheme
コンピュータでの文字処理の基になる体系
文字符号化方式における一番重要な情報は
- 文字集合「character repertoire」（例は「雪」）
- 文字に該当する値（例はU+96EA）
- 値の基本データー型（例はバイト、2バイト、4バイト）

重要な文字符号化方式

Unicodeの文字符号化方式
- utf-8（基本データー型はバイト）
- utf-16（基本データー型は2バイト）
- utf-32（基本データー型は4バイト）
他の文字符号化方式
- ISO 2022
- iso-8859-1、iso-8859-2、など
- EUC-JP
- Shift_JIS
- など

文字集合

質問「Unicodeの文字集合にない文字はどうすればよいか」
回答は
- その文字がUnicode文字集合に追加されるまでに「待つしかない」
- 又は、Script Encoding Initiativeなどと連絡

文字の処理

文字を比較する際の問題

U+00E7 `ç` = U+0063 `c` U+0327 `¸`?

Unicode正規化「Unicode Normalization」が必要
- 「U+0063 `c` U+0327 `¸`」の文字コードを
- U+00E7 `ç`に変換できる定義

文字の処理

文字の順序の問題

Strasse = Straße?

文字列の照合「collation」が問題の解決
XQueryからの一例

compare
('Strasse', 'Straße','http://example.com/collation-identifier/German')

国際化の対象「URI」

入力し、表示したいWebアドレス

http://ja.wikipedia.org/wiki/文字

URIで表示される

http://ja.wikipedia.org/wiki/%E6%96%87%E5%AD%97

「文字」をWebアドレスとして使用できる「IRI」(Internationalized Resource Identifier)

テキストの表示について「ルビ」

<ruby>
 <rb>慶應義塾大学</rb>
 <rt>けいおうぎじゅくだいがく</rt>
</ruby>

表示

テキストの表示「テキストの方向性」

A)english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
B)english1 2WERBEH english3 4WERBEH english5 6WERBEH
           <------          <------          <------
               H                H                H
  ------------------------------------------------->
                          E

A)は入力、又はコンピュータにおけるデーターの方向「logical order」
B)は読者のための表示の方向「visual order」
スクリプト「script」の混合の表示に必要な国際化

テキストの組版

現時ではW3Cが「日本語組版処理の要件」を集めている
例は「縦書き」に関する要件
要件を実現するのはスタイルの技術CSS、SVG、XSL

縦書きの例

言語の識別の目的

言語ごとのスタイル
検索
比較
一般的なメターデーター
など

言語によるglyphの違いの例（繰り返し）

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

雪 zh-CN

雪 zh-TW

雪 zh-HK

雪 ja

雪 ko

言語識別の標準「BCP 47」

BCP 47の言語タグ「language tag」は「sub tag」の構造が定義される

langtag = (language
 ["-" script]
 ["-" region]
 *("-" variant)
 *("-" extension)
 ["-" privateuse])

IANA Language Subtag Registry

File-Date: 2006-04-19
%%
Type: language
Subtag: aa
Description: Afar
Added: 2005-10-16
%%
Type: variant
Subtag: 1901
Description: Traditional German orthography
Added: 2005-10-16
Prefix: de
%%

言語タグの例

タグ	「sub tag」の構造	趣旨
en	language	英語
de-AT	language-region	オーストリアで使用されるドイツ語
de-CH-1901	language-region-variant	スイスで使用されるドイツ語で、1901年の正書法
sr-Cyrl	language-script	キリル文字でセルビア語

自分で言語タグを作りましょう

Language Tag Analyzer (LTA)

言語タグのマッチ

de-*-DEで検索できる言語タグ

de-DE
de-DE-x-goethe
de-Latn-DE-1996

ロケールについて

ユーザーの言語や国、地域などの指定
ロケールにより、データーの表記や処理が異なる
ロケール情報の集合「locale data」、例えば文字列の照合「collation」

言語はロケールの主な要素だが…

言語とロケールの違い

国際化とローカリゼーションの一例（繰り返し）

自動車の国際化はハンドルを右側にも左側にも付けられるように車工場で準備する
自動車のローカリゼーションはハンドルを
- 右に付ける（日本のためのローカリゼーション）
- 左に付ける（ドイツのためのローカリゼーション）
地域が主な要素になるロケール情報の例
- 為替
- 時間帯

国際化の対象：Web Service

主に、ロケールを取り扱うWebサービスがテーマになる
ロケール情報が必要なWebサービスの例は「飛行機のチケットの予約」
- 出発地、乗り換え、又は到着地の時間帯を表示
- ユーザーが住んでいる地域の為替で値段を計算
- ユーザーの言語でHPを表示
詳細のところは後で紹介する

XMLの国際化

Internationalization Tag 1.0というW3Cの新しい勧告
国際化とローカリゼーションのためのマーク付けを提供

まとめ(1)

"Translate"翻訳の可能不可能を識別
"Localization Notes"
"Terminology"用語の識別と関連情報の参照

まとめ(2)

"Directionality"アラビア語などに必要なテキストの方向性
"Ruby"ルビ
"Language Information"BCP 47の言語タグの識別
"Elements Within Text"XMLの要素の位置を識別。例：混合内容である要素を識別

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

@translate属性で翻訳の可能不可能を識別
"Translate"のデフォルト値と相続関係

<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)

XPathで要素や属性を識別し、"Translate"の情報を追加

<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)

XML文書における情報を参照
例："language information"BCP 47の言語タグの残照

<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の適用分野

（自動）翻訳ツール
ローカリゼーションツール
用語の出力
正書法のチェック
など

Webの国際化の対象（復習）

文字と文字コード
文字の処理
文字、又はテキストの表示
テキストの追加情報「ルビ」
テキストの組版

Webの国際化の対象（復習）

言語の識別と言語タグのマッチ
言語とロケールの違い
Webサービスの国際化
XMLの国際化

概要

国際化の趣旨
Webの国際化の対象
Webの国際化の現状と将来
リンク集

Webの国際化の現状と将来

国際化ドメイン名「domain name」の問題
（「a」はキリル文字、又はラテン文字か）

http://www.paypal.com

組版の国際化(CSS、SVG、XSLなど)
問い合わせ言語の国際化、例えば「XQuery Full Text Search」

/book[@number="1"]//editor ftcontains "salon de the"
with default stop words language "fr"

リンク集

Webサービス

注意！HTTPの詳細のところは省きます

文書のWebとサービスのWeb

文書のWebとサービスのWebについて
SOAPのWebサービス
RESTのWebサービス
SOAPとRESTの共同作業
Webサービスの国際化

文書のWeb

本講義の今までのテーマは文書がメーン
- HTTPで送受信する文書
- XMLで文書の作成
- スキーマ言語で文書の構造の定義
- XPath、XSLTなどで文書の処理
- CSSで文書のスタイル
- など

サービスのWeb

適用分野は

情報体系への問い合わせ、又は情報の変更
サービスの間のつながり

Webサービスのアプローチ

RESTのWebサービスは
- 情報体系への問い合わせ、又は情報の変更が課題
- 特定の技術ではなく、インターネット技術（HTTP、URIなど）の適用方法
SOAPのWebサービスは
- サービスとサービスをつなぐ、
  サービス指向アーキテクチャ「Service Oriented Architecture」の一例
- SOAP、WSDL、UDDIなどの特定の技術

注意！

Webサービスの一般的な定義はまだない
「RESTはWebサービスではない」という声も
SOAPとRESTの違いは今のWebのHot Topic！

Webサービスのメリット

特定のOSと関係ない
特定のプログラム言語と関係ない
Webサービス提供者「provider（server）」とWebサービス要求者「requestor(client)」の多様な組み合わせができる

サービスの一例

部品についてのWebサービス
サービスのオペレーション
- 部品の情報の問い合わせ
- 部品の注文

SOAPのWebサービス

文書のWebとサービスのWebについて
SOAPのWebサービス
RESTのWebサービス
SOAPとRESTの共同作業
Webサービスの国際化

SOAPのWebサービスが利用する技術

データはXML、データ型はXML Schema
SOAP はメッセージのフォーマット
HTTP などのプロトコルとの「Binding」
Webサービスの記述「WSDL」
Webサービス発見「UDDI」（ここでは触れない）

SOAPの基本

Simple Object Access Protocol
メッセージとエラー定義を含むXML文書「Envelope」
header と body

<soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header> ... </soap:Header>
<soap:Body> ...
 <soap:Fault> ... </soap:Fault>
</soap:Body>
</soap:Envelope>

部品のサービスの request（document style）

<soap:Body>の内容はユーザーが定義する、XMLスキーマによるXML文書

<soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
<soap:Header> ... </soap:Header>
<soap:Body>
 <getPartInfo xmlns="some-ns.example.com">00345</getPartInfo>
</soap:Body>
</soap:Envelope>

部品のサービスの request（rpc style）

Remote Procedure Call
主に単なる「request-response」のパターンに使用
<soap:Body>の内容は「SOAP ENCODING」の規則に従うXML文書

<soap:Envelope
 xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
 soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header> ... </soap:Header>
<soap:Body>
 <getPartInfo xmlns="some-ns.example.com>
  <partID>00345</partID>
 </getPartInfo>
</soap:Body>
</soap:Envelope>

responseの一例

<soap:Body>
 <p:Part xmlns:p="http://www.parts-depot.com"   
  xmlns:xlink="http://www.w3.org/1999/xlink">
  <Part-ID>00345</Part-ID>
  <Name>Widget-A</Name>
  <Description>...</Description>
  <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
  <UnitCost currency="USD">0.10</UnitCost>
  <Quantity>10</Quantity>
 </p:Part>
</soap:Body>

WSDL

Web Services Description Language

<definitions>
 <types> ... </types>
 <message> ... </message>
 <portType> ... </portType>
 <binding> ... </binding>
</definitions>

データ型<types>
データ型を利用するメッセージ<message>
メッセージなどを含み、サービスの記述<portType>
プロトコルとのbindingの定義<binding>

WSDLの一例

<definitions>
 <types> 
  <xs:element name="getPartInfo"> ... </types>
 <message name="GetPartInfoSoap">
  <part name="parameters" element="tns:getPartInfo"/> ... </message>
 <portType name="GetPartInfoSoap> 
 <operation name="GetPartInfo">
  <input message="tns:GetPartInfoSoap"> ... </operation> ... </portType>
 <binding> ... </binding>
</definitions>

WS-*

SOAPを拡張する標準
【メッセージング仕様】WS-Addressing
【セキュリティ】WS-Security、WS-SecureConversation、WS-SecurityPolicy、WS-Trust
【高信頼性】WS-ReliableMessaging
【トランザクション】WS-Coordination、WS-AtomicTransaction
【メタデータ】WS-Policy、WS-PolicyAttachment、WS-MetadataExchange

WS-Addressingの「endpoint reference(EPR)」

サービスを識別する
URIと追加情報

<wsa:EndpointReference xmlns:wsa="..." xmlns:example="...">
   <wsa:Address>http://www.parts-depot.com/parts/</wsa:Address>
   <wsa:ReferenceProperties>
       <example:ServiceLevel>Basic</example:ServiceLevel>
   </wsa:ReferenceProperties>
</wsa:EndpointReference>

EPRはURIとは違い、Web Architectureに従わない！

SOAPのWebサービス

Webサービスのツールがメーン
ツールの会社が影響が大きい
RESTは違う

RESTのWebサービス

文書のWebとサービスのWebについて
SOAPのWebサービス
RESTのWebサービス
SOAPとRESTの共同作業
Webサービスの国際化

RESTの趣旨

Representational State Transfer
Webの基本単位は「リソース」
clientのステートがリソースの送受信で変わる

RESTの基本的な概念

HTTP、URI、リソースとリソースのMIME typeがメーン
SOAPよりシンプル
新しい技術より、Web技術の適用方法

RESTの一例、問い合わせ

部品のリストの問い合わせ

http://www.parts-depot.com/parts

部品の詳細の情報を問う

http://www.parts-depot.com/parts/00345

問い合わせの出力

 <p:Part xmlns:p="http://www.parts-depot.com"   
  xmlns:xlink="http://www.w3.org/1999/xlink">
  <Part-ID>00345</Part-ID>
  <Name>Widget-A</Name>
  <Description>...</Description>
  <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
  <UnitCost currency="USD">0.10</UnitCost>
  <Quantity>10</Quantity>
 </p:Part>

RESTのURIの種類

logical URI

http://www.parts-depot.com/parts/00345

physical URI

http://www.parts-depot.com/parts?action=getParts&partID=00345

logical URI と physical URIの互換性
RESTのWebサービスが提供するのは「logical URI」だけ

RESTの特徴（まとめ）

HTTPのPUT、POST、GET、DELETEの適用
clientがリソースのrepresentationを引き出す「pull」アプローチ
ステートがない
Cacheができる
リソースはイコールURI
URIでリソースをつなぎ、clientのステートが変更

RESTの短所

セキュリティがない
高信頼性がない
サービスのメタデータが

SOAPとRESTの共同作業

文書のWebとサービスのWebについて
SOAPのWebサービス
RESTのWebサービス
SOAPとRESTの共同作業
Webサービスの国際化

SOAPとRESTの共同作業が可能

情報体系の問い合わせ、又は変更はREST
サービスの間のつながりはSOAP
その例は、サービスのセキュリティ性質などを表現する「Web Service Policy」

WSDLにおける「WS Policy」のメタデータ

bindingにセキュリティが必要

<binding name="SecureBinding" ...>
  <PolicyReference URI="#secure" />...</wsdl:binding>

「security policy expression」の定義

<Policy wsu:Id=”secure”>
  <All>
    <ExactlyOne>
     <sp:TransportBinding>...</sp:TransportBinding>
     <sp:AsymmetricBinding>...</sp:AsymmetricBinding >
    </ExactlyOne>
  </All>
</Policy>

Webサービスの国際化

文書のWebとサービスのWebについて
SOAPのWebサービス
RESTのWebサービス
SOAPとRESTの共同作業
Webサービスの国際化

注意！

これから紹介する技術は

標準ではない
Webサービスの国際化の提案

Webサービスの国際化の目的

ロケール情報をサービスに追加する
ロケール情報の例（繰り返し）は
- 言語
- 地域
- 時間帯
- など

SOAPのWebサービスの国際化

SOAPのheaderに国際化の情報を追加

<i18n:international>
 <tz>GMT-0300</tz>
 <i18n:locale>en-US</i18n:locale>
 <i18n:preferences>
  <ldml:measurementSystem type="metric" />
 </i18n:preferences>
</i18n:international>

ロケールの「WS Policy　expression」をWSDLに追加

RESTのサービスの国際化

URIにロケールの情報を追加する
HTTPのheaderにロケールの情報を追加する

概要

文書のWebとサービスのWebについて
SOAPのWebサービス
RESTのWebサービス
SOAPとRESTの共同作業
Webサービスの国際化

リンク集

W3Cの特許方針「patent policy」

W3Cの標準はロイヤリティフリー「royalty free」に実装ができる
知的財産権「Intellectual property」でお金を支払う必要がない
主な要素はワーキンググループ参加者(組織)が従わなければならない期間
- ある草案の中で特許を使わないことを明記する除外期間「exclusion period」
- 特許の開示「disclosure」の期間
特許の問題が発生するときに、PAG (Patent Advisory Group)が構成される

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

特許方針 (Patent Policy)
W3Cの特許方針のウェブシステム http://www.w3.org/2004/01/pp-impl/
W3Cの特許方針のまとめ
W3Cの特許方針のFAQ

IETFの特許方針

The Tao of IETF　から

「BCP 78」と「BCP 79」を参照
「IETF IPR Disclosure Page」で特許の開示ができる
IETFの特許方針はW3Cの特許方針とは違い、絶対に特許を開示する必要がない

OASISの特許方針

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

W3Cの方針に似ている
但し、絶対特許を開示する必要はない
OASISの特許方針に反対する人もいる

ISO/IECの特許方針

ISO/IECの特許方針のガイドラインがISO/IECの特許方針を説明する
特許が開示されていないISO/IECの標準を公開することが可能

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

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

なぜかというと

Type1の組織は組織の成功が特許だけに依存することがなく、特許の問題（裁判！）を怖がる
Type2の組織は特定の分野で特許を持ち、組織の成功がその特許に繋がる

難しい人「difficult people」

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

「Difficult People」の定義

プロジェクトの邪魔になる人
自分が邪魔になる、ということに気が付かない人
プロジェクトの邪魔になる例は
- 合意「consensus」に続けて反抗する
- よく新しい提案を出す
- など

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

問題は自分が「difficult」に気が付く人がいない
「あなたは difficult」、又は「あの人は difficult」という判断自体が難しい
「あなたは difficult」という主張は人間関係の負担になってしまう

解決のステップ

まず、何もしなで、「difficult」の問題をそのままにしてなくなってしまうことを祈る
次に、ある人が「difficult」である、という証明を集める
個人的にワーキングループの参加者と問題について相談する
「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.

まとめ

本講義の構造（繰り返し）

標準化の旨趣について
標準化の組織
標準化の一般的な過程
標準化のツール
宿題

本講義の構造（繰り返し）

標準の「言葉」と「スタイル」
XMLの基本
XML語彙と新たな宿題
宿題の分析

本講義の構造（繰り返し）

国際化
Webサービス
W3Cの特許方針「patent policy」
難しい人「difficult people」

お疲れ様でした

今週、ありがとうございました！
本講義のスライドを参考にして、標準の文書を読んでく下さい。
もし分かりにくいところがありましたら、ご連絡下さい（fsasaki@w3.org）

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

資料と本講義について

本講義の目的

本講義の構造

本講義の構造

本講義の構造

本講義の構造

本講義の構造

成績評価

自己紹介

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

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

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

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

標準化の旨趣について

標準化の目的

標準化はつまらない！

ちょっと変わったテーマにしましょう

標準化の目的

標準化と革新の関係

実際の例：アメリカ鉄道の標準化

標準化の目的

実際の例：アメリカ鉄道の標準化

標準化の歴史

１９世紀で工業化

１９世紀から現代へ

ITの標準化

標準の種類

標準の種類

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

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

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

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

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

標準化活動に参加するグループ

「BCP 47」

「BCP 47」

「Web Services Policy 1.5」

「ISO/IEC 10646（Unicode）」

標準化の組織

標準化の範囲

標準化の範囲

「10間」存在する組織

国内と国際的な組織

国内と国際的な組織

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

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

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

NSBとSDO

NSBとSDOの関係

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

組織の紹介（まとめ）

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

ISO/IEC、JISC

W3C

OASIS

IETF

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

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

WS-IとWHAT-WGの共通点

標準化の一般的な過程

標準化の一般的な過程

charterのー例

目的の記述

ワーキングループ（TC）が作成する文書

対象外のテーマ

Liaison（共同作業）

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

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

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

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

本講義の構造

標準化のツール

標準化のツール

大変な問題「電話会議の時間」

W3Cのツールの紹介

Queueの例

問題点とAction items

Ballot

合意をIRCで書き残す

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