競輪補助事業
平成１９年度 Web 資源有効活用を推進する情報基盤
の標準化調査研究補助事業
マルチモーダルウェブマイニング
技術の標準化調査研究
成 果 報 告 書
平成２０年３月
財団法人
日本規格協会
情報技術標準化研究センター
序
ウェブは今や社会的なインフラとして広く認知され，インターネットに接続されたパソ
コンだけでなく，ユビキタス環境に広がったケータイ(携帯電話)によってアクセスされて，
多くの人に多様な情報を提供し，多くの人から多様な情報形態で多様な内容の情報が書き
込まれている。
このような大量情報をだれもがいつでもどこでもアクセス可能になったことは，人類の
歴史上はじめてであり，そうであるがゆえ故にその大量情報をどのように利用するかが今
後の人類の文化の方向を大きく左右する局面に我々は遭遇している。
このような多様な情報形態の大量情報の中から，ある特定の目的に応じて必要な情報を
取り出し，それを適切な表現形式で提供する技術としてマルチモーダルウェブマイニング
技術がある。この言葉は，本調査研究プロジェクトによってはじめて使われるようになっ
たキーワードであるが，関連する技術は数多く存在し，多くの技術者達によって推進され
てきた。
本調査研究プロジェクトはこれらの先行技術をマルチモーダルウェブマイニングの視点
から捉えなおし，新たな技術要素を追加して，有意義な応用に展開できる新技術を提供す
るものである。その成果は，コンセプトの明示から規格原案の提供まで多岐にわたる。こ
れらのプロジェクトの成果が，今後の情報化社会に大きく寄与して新たな情報文化を育て，
さらに次世代の情報技術につながっていくことを期待したい。
マルチモーダルウェブマイニング技術の標準化調査研究委員会
委員長 池田克夫
目 次
1.
調査研究の概要 ··························································· 1
1.1 はじめに ································································ 1
1.2 目的 ···································································· 2
1.3 委員会構成とテーマ······················································· 3
1.4 委員会名簿 ······························································ 4
1.4.1 マルチモーダルウェブマイニング技術の標準化調査研究委員会 ··············· 4
1.4.2 WG1：Web サービス ······················································ 4
1.4.3 WG2：Web データアクセス ················································ 5
1.5 委員会開催状況··························································· 6
1.5.1 委員会開催期間························································· 6
1.5.2 委員会開催状況························································· 6
1.6 成果一覧 ································································ 7
1.6.1 マルチモーダルウェブマイニング技術の標準化調査研究委員会 ··············· 7
1.6.2 WG1：Web サービス ······················································ 7
1.6.3 WG2：Web データアクセス ················································ 7
2.
マルチモーダルウェブマイニング技術の標準化調査研究委員会活動報告 ·········· 8
2.1 概要 ···································································· 8
2.1.1 研究目的 ······························································ 8
2.1.2 研究内容 ······························································ 8
2.2 活動報告 ································································ 8
3.
WG1：Web サービス活動報告 ················································· 9
3.1 背景と目的 ······························································ 9
3.2 活動内容 ······························································· 10
3.2.1 次世代 Web サービスに関する調査研究···································· 11
3.2.2 コンテンツ生成・流通・管理の概念モデルに基づく
交換フォーマットの標準化············································· 22
3.2.3 電子書籍，電子辞書，オーディオブック，教材コンテンツの標準化 ·········· 30
3.3 成果のまとめ ··························································· 45
3.3.1 次世代 Web サービスに関する調査研究成果································ 45
3.3.2 コンテンツ生成・流通・管理の概念モデルに基づく
交換フォーマットの標準化成果········································· 46
3.3.3 電子書籍，電子辞書，オーディオブック，教材コンテンツの標準化成果 ······ 50
(ⅰ)
3.4 今後の課題 ····························································· 51
4.
WG2：Web データアクセス活動報告 ·········································· 52
4.1 背景と目的 ····························································· 52
4.2 活動内容 ······························································· 53
4.2.1 トピックマップ(TM)···················································· 53
4.2.2 文書スキーマ定義言語(DSDL)············································ 54
4.2.3 XML データベース問合せ言語及び関連規定 ································ 55
4.2.4 スタイル指定言語······················································ 59
4.3 成果のまとめ ··························································· 64
4.3.1 トピックマップ(TM)···················································· 64
4.3.2 文書スキーマ定義言語(DSDL)············································ 65
4.3.3 XML データベース問合せ言語及び関連規定 ································ 65
4.3.4 スタイル指定言語······················································ 65
4.3.5 2006 年度開発原案のフォロー ··········································· 65
4.4 今後の課題 ····························································· 66
4.4.1 トピックマップ(TM)···················································· 66
4.4.2 文書スキーマ定義言語(DSDL)············································ 66
4.4.3 XML データベース問合せ言語及び関連規定 ································ 66
4.4.4 スタイル指定言語······················································ 66
5.
今後の展望と課題························································· 67
附属資料 ···································································· 68
[附属資料 WG2-1]： TM-4 JIS 素案（抜粋）
，トピックマップ
第 4 部 正準化
[附属資料 WG2-2]： JIS X 4177-3 素案（抜粋）
，文書スキーマ定義言語(DSDL)
第7部
文字レパートリ記述言語（CREPDL）
[附属資料 WG2-3]： フォーマット化特性（Formatting Property）における
XSL と CSS との違い
(ⅱ)
1.
調査研究の概要
1.1 はじめに
ウェブは、インターネットそのものの発達を促しただけなく、それ自体がこれまでにな
い大規模な情報空間を構成し、人類の文化を変えようとしている。つまり誰もが、地域・
文化・言語・表現メディア等の壁を越えて、いつでもアクセスでき、レビューし、更新で
きる大規模データ空間が構築され、さらにその規模は増大している。
このような大規模データ空間を前にしたとき、人はその情報内容の規模と多様性に圧倒
されると共に、そのはかり知れない利用可能性に期待し、利用方法を模索することになる。
その利用方法の一つがウェブマイニングである。いろいろな人がそれぞれの意図のもとに
独立に提供した情報も、それが大量に集まることによって、たとえ個々の情報としては断
片的な不十分な内容であったにせよ、ある目的のもとに集め直すことにより、新たな知見
を生成し得る情報セットを獲得する可能性が出てくる。これをサポートする技術がウェブ
マイニングであり、ウェブでは個々の情報はさまざまな情報形態をとり得るため、それら
を集める技術は基本的にマルチモーダルであることが望まれる。
例えば、最近のマスコミで報道された悪徳商法業者の行動は、その被害を受けた多くの
人たちによってウェブに書き込まれていた。しかし、その書込みは決して系統立ったもの
ではなく、しかも悪徳商法業者からの“営業妨害”のクレームを避けるために必ずしも明
示的ではなく、しかも多様な情報形態でウェブに掲載されていた。このような大量のマル
チモーダル情報を被害回避の視点で予め整理し捉えることができていれば、マスコミで報
道された被害の状況ははるかに小さくとどめることができたに違いない。このようにマル
チモーダルウェブマイニング技術の応用は、ウェブの技術的内容を知らない多くのウェブ
エンドユーザからも強く望まれている。
データマイニングの技術は、以前から多くの情報技術者達によって研究され、関連プロ
ダクツの開発が行われてきた。さまざまな情報形態への対応も、マルチメディアというキ
ーワードのもとに、多くの研究成果が報告され、INSTAC においても多年にわたるプロジェ
クトの成果が報告されている。
マルチモーダルウェブマイニング技術の標準化調査研究委員会は、これらの調査研究の
成果を踏まえ、ウェブ環境で利用価値の高まる多様なアプリケーションを構築するために
必要な基礎的な調査研究を行い、ウェブが国際的に広がっているが故に、必要に応じて国
際標準化へのアプローチを行うことをも狙って計画された。
- 1 -
1.2 目的
前項(1.1)に示したユーザ要求に応えようとすると、今なお幾つもの技術的な問題点に遭
遇する。ウェブを情報共有の手段として活用しながらも、ウエブ上の各資源が個別最適で
構築されていることから、これらの多様な情報形態をもつ各種資源を自在に組み合わせ、
関連付けて利用するような仕掛けについては、技術的検討の途上にある。
そこで、ウェブに分散している多様な情報形態をもつ各種資源を必要に応じて関連付け
ながら、目的とする一連の情報を的確に把握するシステムの構築を可能とするための情報
基盤環境を整備するため、基本的な要業技術であるユーザインタフェース、ウェブデータ
アクセス、マルチモーダル情報表現、マルチモーダルウェブサービスなどを多岐にわたる
視点で調査研究し、その中で標準化を必要とする技術内容については適切な規格原案の作
成を推進する。
ウェブとそのサービスを構成する主要技術要素の代表として、XML（Extensible Markup
Language／拡張可能なマーク付け言語）及びスキーマ言語がある。スキーマ言語について
は、DSDL(文書スキーマ定義言語)として国際標準化機構の JTC1/SC34 において積極的な検
討が行われており、それで記述され、国際規格案として提出された文書交換フォーマット
についても国際的な関心が高まっている。これらについて基礎的な検討を行うと共にその
成果を JTC1/SC34 に反映し、しかも国内の規格として原案作成を行う。
ウェブ環境に分散する膨大な資源を関連付け、それらに対するインデクス付けする技術
として Topic Maps（以降、トピックマップ（TM)という）がある。開発当初のトピックマッ
プは HyTime を用いて記述されたが、その後 XML で記述されるようになって、広く普及した
が、さらにそれを便利に使うための技術要素が国際的に検討されている。この動向を見定
めて、新たな技術要素を提案し国際での議論を喚起するとともに、国内の規格として原案
作成を行う。
- 2 -
1.3 委員会構成とテーマ
平成19年度
マルチモーダルウェブマイニング技術の標準化調査研究委員会
体制
● Webに分散している資源を必要に応じて結合しながら、目的とする柔軟なシステム
構築を可能とする情報基盤環境を整備するための標準化技術要素 を調査研究
マルチモーダルウェブマイニング技術の標準化調査研究委員会
池田委員長（事務局：堀江）
WG1： Webサービス
大野主査
WG2： Webデータアクセス
小町主査
＜研究内容＞
＜研究内容＞
①次世代Webサービスに関する調査研究
①TMのJIS化及びIS動向調査
②コンテンツ生成・流通・管理の概念モデルに
②DSDLのJIS化及びIS動向調査
基づく交換フォーマットの標準化
③ XML-DBの問合せ言語及び関連規定の
③電子書籍、電子辞書、オーディオブック、教
材コンテンツの標準化
調査研究
④XSLのJIS化及びCSSとの機能比較
- 3 -
1.4 委員会名簿
1.4.1 マルチモーダルウェブマイニング技術の標準化調査研究委員会（本委員会）
（敬称略・順不同）
種別
氏名
所属
委員長
池田 克夫
大阪工業大学 情報科学部
副委員長
小町 祐史
大阪工業大学 情報科学部
委員
五十嵐 達治
富士通（株） 法務・知的財産権本部スタンダード戦略室
委員
和泉 章
経済産業省 産業技術環境局情報電子標準化推進室
委員
植村 八潮
東京電機大学 出版局
委員
大久保 彰徳
(株)リコー グループ技術企画室
委員
大野 邦夫
(独)雇用・能力開発機構
職業能力開発大学校 通信システム工
学科
委員
河込 和宏
(株)東芝 ソフトウェア技術センター
委員
黒川 利明
(株)ＣＳＫホールディングス 総合企画部
委員
黒田 信二郎
(株)紀伊國屋書店 出版部
委員
杉山 和弘
ＮＴＴソフトウェア（株） 営業推進本部
委員
須栗 裕樹
(株)コミュニケーションテクノロジーズ
委員
出葉 義治
ソニー（株） テレビ事業本部
委員
中村 幹
(株)印刷学会出版部
委員
平山 亮
金沢工業大学 情報フロンティア学部
委員
宮澤 彰
国立情報学研究所 情報社会相関研究系
委員
村田
国際大学 研究所
委員
矢ヶ崎 敏明
キヤノン（株） プラットフォーム技術開発センター
委員
八尋 俊英
経済産業省 商務情報政策局情報処理振興課
経産省
小林 秀司
経済産業省 産業技術環境局情報電子標準化推進室
事務局
堀江 由伸
(財)日本規格協会 情報技術標準化研究センター
事務局
宮古 牧子
(財)日本規格協会 情報技術標準化研究センター
真
1.4.2 WG1：Web サービス
種別
主査
（敬称略・順不同）
氏名
大野 邦夫
所属
(独)雇用・能力開発機構 職業能力開発大学校 通信システム
工学科
幹事
植村 八潮
東京電機大学 出版局
委員
新
(株)インターネットイニシャティブ 技術研究所
麗
- 4 -
委員
黒崎 芳行
アラクサラネットワークス(株)
マーケティング本部ソリュ
ーションマーケティング部
委員
佐藤 弘一
ＮＥＣシステムテクノロジー(株) 第二ミドルウェア事業部
委員
高木 悟
(株)KDDI 研究所 Web データコンピューティンググループ
委員
高橋 仁一
大日本印刷(株) C＆Ｉ事業部 IT 開発本部
委員
田中 宏一
(株)内田洋行
マーケティング本部次世代ソリューション開
発センター
委員
田原 恭二
凸版印刷(株) 情報･出版事業本部・製造事業部
委員
長村 玄
コンサルタント
委員
山田 篤
(財)京都高度技術研究所 研究部
経産省
小林 秀司
経済産業省 産業技術環境局情報電子標準化推進室
事務局
堀江 由伸
(財)日本規格協会 情報技術標準化研究センター
事務局
宮古 牧子
(財)日本規格協会 情報技術標準化研究センター
1.4.3 WG2：Web データアクセス
種別
（敬称略・順不同）
氏名
所属
主査
小町 祐史
大阪工業大学 情報科学部
幹事
村田 真
国際大学 研究所
委員
石野 恵一郎
アンテナハウス(株) XSL Formatter グループ
委員
内山 光一
東芝ソリューション(株)
プラットフォームソリューション
要素技術開発部
委員
黒川 利明
(株)ＣＳＫホールディングス 総合企画部
委員
瀬戸川 教彦
(株)日立システムアンドサービス 研究開発ｾﾝﾀ
委員
内藤 求
(株)ナレッジ・シナジー
委員
林
ディスクロージャー・イノベーション(株) シナジー･インキ
均
ュベート事業部
委員
藤島 雅宏
(有)イー・エｲド
経産省
小林 秀司
経済産業省 産業技術環境局情報電子標準化推進室
事務局
堀江 由伸
(財)日本規格協会 情報技術標準化研究センター
事務局
宮古 牧子
(財)日本規格協会 情報技術標準化研究センター
- 5 -
1.5 委員会開催状況
1.5.1 委員会開催期間
本委員会及び WG の委員会活動の開催期間は、平成 19 年 6 月 14 日から平成 20 年 3 月 10
日までである。
1.5.2 委員会開催状況
本委員会及び WG の委員会の開催状況を次に示す。
(1) マルチモーダルウェブマイニング技術の標準化調査研究委員会
計3回
開催
開催日時
開催場所
第1回
平成 19 年 6 月 14 日(木) 14:00-16:00
JSA 本部ビル 203 会議室
第2回
平成 19 年 11 月 6 日(火) 10:30-12:30
赤坂エイトワンビル 802 会議室
第3回
平成 20 年 2 月 26 日(火) 14:00-16:00
日本海運会館 301 会議室
(2) マルチモーダルウェブマイニング技術の標準化調査研究委員会 WG1
開催
開催日時
計8回
開催場所
第1回
平成 19 年 7 月 12 日(木) 14:00-16:00
JSA 本部ビル 203 会議室
第2回
平成 19 年 8 月 30 日(木) 14:00-16:30
赤坂エイトワンビル 802 会議室
第3回
平成 19 年 9 月 13 日(木) 10:00-12:30
赤坂エイトワンビル 802 会議室
第4回
平成 19 年 10 月 24 日(水) 14:00-17:00
JSA 本部ビル 203 会議室
第5回
平成 19 年 11 月 21 日(水) 14:00-17:00
赤坂エイトワンビル 802 会議室
第6回
平成 19 年 12 月 19 日(水) 14:00-17:00
JSA 本部ビル 202 会議室
第7回
平成 20 年 1 月 16 日(水) 14:00-17:00
日本海運会館 302 会議室
第8回
平成 20 年 2 月 13 日(水) 14:00-17:00
JSA 本部ビル 203 会議室
(3) マルチモーダルウェブマイニング技術の標準化調査研究委員会 WG2
開催
開催日時
計9回
開催場所
第1回
平成 19 年 7 月 19 日(木) 14:00-16:00
JSA 本部ビル 202 会議室
第2回
平成 19 年 8 月 24 日(金) 14:00-16:00
JSA 本部ビル 202 会議室
第3回
平成 19 年 9 月 25 日(火) 11:00-13:00
JSA 本部ビル 203 会議室
第4回
平成 19 年 10 月 31 日(水) 14:00-17:00
赤坂エイトワンビル 802 会議室
第5回
平成 19 年 11 月 26 日(月) 14:00-17:00
JSA 本部ビル 202 会議室
第6回
平成 20 年 1 月 7 日(月) 14:00-17:00
JSA 本部ビル 203 会議室
第7回
平成 20 年 1 月 31 日(木) 14:00-17:00
日本海運会館 302 会議室
第8回
平成 20 年 2 月 18 日(月) 10:00-12:00
日本海運会館 302 会議室
第9回
平成 20 年 3 月 10 日(月) 14:00-17:00
日本海運会館 302 会議室
- 6 -
1.6 成果一覧
1.6.1 マルチモーダルウェブマイニング技術の標準化調査研究委員会
本委員会の検討結果は、各 WG の項にその詳細を示すが、本委員会ではその成果を承認す
るとともに、今後の INSTAC 標準化活動により、Web 資源有効活用の推進に資するものとし
て提言するものである。
1.6.2 WG1：Web サービス
(1) 次世代 Web のサービスに関する調査研究
意味情報を表現するためのオントロジ記述言語に関し、Web にアクセスするモバイル端
末の市場及び技術の動向を踏まえ、PND(パーソナル・ナビゲーション・デバイス)、情報
家電の相互接続プロトコルである DLNA、認証技術の OpenID、障害者をも含めたユーザイ
ンタフェース、携帯コンテンツサービスと連携した個人プロファイル活用技術等を調査
し、報告書にまとめた。
(2) コンテンツの生成・流通・管理の概念モデルに基づく交換フォーマットの標準化
e-Book 等の概念モデルに適用されるプルーフリーディングの仕組みについて検討し、
プルーフリーディングのためのメタデータ案をまとめ、標準化の準備を行った。
(3) 電子書籍、電子辞書、オーディオブック、教材コンテンツの標準化
交換フォーマットの具体例として、電子書籍、電子辞書、オーディオブック等の市場
調査を行うと共に、JEITA を経由して IEC/TC100 のｅ-Book 関連の分科会 TA10 に提案し
国際標準化へ寄与した。
1.6.3 WG2：Web データアクセス
(1) トピックマップ(TM)
トピックマップ-4（正準化）の JIS 素案を作成した。また、その他パートの国際標準
化
動向の調査を行い、報告書にまとめた。
(2) 文書スキーマ定義言語(DSDL)
DSDL-7（文字レパートリ記述言語）の JIS 素案を作成した。また、その他パートの国
際標準化動向の調査を行い、報告書にまとめた。
(3) XML データベース問合せ言語及び関連規定
海外コンソシアムでの標準化動向の調査を実施した。具体的には、W3C から勧告され
たデータモデル、XPath2.0、XSLT2.0 を翻訳し、概要を取り纏めるとともに、今後の国内
標準化への提言を行った。
(4) スタイル指定言語
XSL の TS 普及動向の確認を行った。また XSL と CSS の整合のための機能比較を行い、
表にまとめた。
- 7 -
2.
マルチモーダルウェブマイニング技術の標準化調査研究委員会活動報告
2.1 概要
2.1.1 研究目的
Web を情報共有の手段として活用しながらも、Web 上の各資源が個別最適で構築されて
いることから、これらの資源を自在に組み合わせて利用するような仕掛けはあまり普及
していない。
そこで、Web に分散している資源を必要に応じて結合しながら、目的とする柔軟なシス
テム構築を可能とする情報基盤環境を整備するため、基本的な技術要素である、ユーザ
インタフェース・Web データアクセス・マルチモーダルサービスなど、多岐に渉り調査研
究し、標準化を推進し、わが国の情報社会、中小機械工業の振興に寄与する。
2.1.2 研究内容
さまざまな情報端末を使って、Web 上に分散した膨大な資源にアクセスし、有用な解を
求めるための環境を整備するため、マルチメディア市場と情報端末市場の動向及び関連
する技術分野の動向を踏まえ、マルチメディア情報を有効に取り扱うための文書情報交
換に必要な標準化要素技術について、国際標準化動向と整合性を図りながら調査研究を
実施する。
本委員会では、この要求に応えるため、次の WG を構成して調査研究を推進する。
(1) WG1：Web サービス
次の事項について、目的とする情報基盤環境を実現する標準化要素技術を整理し、
報告書を作成する。
a) 次世代 Web のサービスに関する調査研究
b) コンテンツ生成･流通･管理の概念モデルに基づく交換フォーマットの標準化
c) 電子書籍、電子辞書、オーディオブック、教材コンテンツの標準化
(2) WG2：Web データアクセス
次世代 Web 環境候補のトピックマップ(TM)や XML に準拠した文書を異なるシステ
ム間で利用可能とするための文書スキーマ言語(DSDL)等の調査と JIS 化検討を行う。
a)トピックマップ(TM）
：原規格は ISO/IEC 13250
b)マルチモーダルサービス記述
c) XML データベースの問合せ言語及び関連規定の調査研究
d) XSL
2.2 活動報告
本委員会の検討結果は、各 WG の項にその詳細を示すが、本委員会ではその成果を承認す
るとともに、今後の INSTAC 標準化活動により、Web 資源有効活用の推進に資するものとし
て提言するものである。
- 8 -
3.
WG1：Web サービス活動報告
3.1 背景と目的
Web2.0 というキーワードが頻繁に出現することが物語る通り、Web が急速に進化しつつ
ある。IT に関するビジネス、サービスの大半が Web をベースとしつつある。そのような状
況の下で、さまざまな情報端末が検討され、Web 上に分散した膨大な資源にアクセスし得
るネットワークインフラが整備されつつある。Web 上の資源は、セマンティックウェブの
ように論理的・意味的な構造を持つ情報、映像やアニメといった動的なコンテンツ、ブロ
グや SNS のような利用者との対話を可能とする環境、
セカンドライフのような 3D コンテン
ツ、多様な端末と無線環境に適合可能なケータイコンテンツ、障害者向けのユニバーサル
な環境など、多種多様なコンテンツや環境が Web 上に実装されつつある。そのように多様
に進化しつつあり複雑なデータ様式を含む Web を、ここではマルチモーダルウェブと呼ぶ
こととする。
WG1 では、以上のようなマルチモーダルウェブを活用する具体的なサービスやビジネス
環境を整備するための調査研究を推進する。多様に進化しつつあるマルチモーダルウェブ
を活用するサービスやビジネスも、既存の組織をベースとする以上は、紙や電子ファイル
といった既存メディアと連携する必要がある。見方を変えると、既存のコンテンツ制作・
管理における情報公開や配信、管理の一環として Web が存在し、それがマルチモーダル化
したと言える。そのためにはコンテンツの生成・流通・管理といったライフサイクル的な
概念を組織横断的に共有し、交換フォーマットを標準化してマルチモーダルウェブを含む
種々のシステムへの実装に反映することが要請される。そのような交換フォーマットの具
体例として、電子書籍、電子辞書、オーディオブック、教材コンテンツなどが提案されて
おり、その標準化が検討されている。
以上のような背景の下に、今後のさらなる発展が期待されるマルチモーダルウェブの技
術や市場について、下記の３項目に関する調査研究を推進する。
a) 次世代 Web のサービスに関する調査研究
・意味情報を表現するためのオントロジ記述言語を、次の側面からアプローチする。
NW オントロジ／PIM オントロジ
b) コンテンツ生成・流通・管理の概念モデルに基づく交換フォーマットの標準化
・Submission format モデルの標準化
・Proofreading の考え方整理及びマークアップ言語の標準化
・電子メディアに適した新しい文書スタイル/フォント技術の調査
c) 電子書籍、電子辞書、オーディオブック、教材コンテンツの標準化
・標準化動向の把握及び具体策の検討
- 9 -
3.2 活動内容
WG1 は、進展し続ける IT 技術の成果が端的に期待される次世代 Web のサービス分野と
コンテンツビジネス分野を対象とした調査研究活動を行った。
次世代 Web のサービス分野は、広帯域 IP ネットワーク化が進展する通信技術に支えら
れて変容しつつある Web の現状と今後の動向に焦点を当てた。市場ニーズの主力は、これ
まで企業人を中心としてきたビジネス環境から、生活者を中心とする家庭環境及びユビキ
タス環境へと移行しつつある。
家庭環境では、2011 年の地上デジタル TV 放送への切り替えを目指した大型液晶画面の
デジタル TV の普及が進んでいる。デジタル TV は、地上波放送だけでなく、広帯域 IP ネッ
トワークによる IPTV としての用途も想定されている。IPTV は新しい Web の世界を開拓す
る。従来のキーボードとマウスを使って操作する Web ではなく、リモコンで操作される映
像を中核的なコンテンツとするマルチモーダルウェブの世界である。
ユビキタス環境は、当グループのメンバーが昨年まで関わってきたテーマであり、昨年
度と一昨年度の報告書に最近の動向を記した[1][2]。ユビキタス環境における主力デバイ
スは依然として携帯電話である。携帯電話には、電話としての機能だけでなく、カメラ、
メールの送受信、Web サイトの参照、IC カードによる認証・決済、GPS による現在地確認
といった多様な機能がある。さらに携帯電話にはアドレス帳、スケジュール管理といった
電子手帳としての機能も盛り込まれている。このような機能は PIM（Personal Information
Management）と呼ばれ、以前は専用デバイスとしての PDA（Personal Digital Assistance）
があったが最近はあまり使われていない。ところが PDA 機能を本格的に携帯電話に取り込
んだスマートフォンが見直されつつある。その端緒となったのは、ウィルコム W-ZERO3 で
あるが、アップルの iPhone がこの動向をさらに加速している。このような個人が常に携帯
する情報端末は、将来的には個人の生活履歴を記録・管理する情報環境となることが予想
される。
コンテンツビジネス分野においては、コンテンツのライフサイクルとその間のフォーマ
ット変換がビジネスにおいて重要である。コンテンツの作成者は作成しやすいフォーマッ
トを要求し、利用者は見やすいフォーマットを要求する。利用者はコンテンツを電子的な
フォーマットで参照するだけでなく紙でも参照する。そのような背景からコンテンツの生
成・流通・管理の概念に基づく交換フォーマットの標準化を試みた。さらに具体的なコン
テンツとして、電子書籍、電子辞書、オーディオブック、教材コンテンツの標準化につい
て調査・検討した。
【参考文献】
[1] 平成 17 年度 INSTAC ユビキタス委員会成果報告書
[2] 平成 18 年度 INSTAC ユビキタス委員会成果報告書
- 10 -
3.2.1 次世代 Web のサービスに関する調査研究
W3C のディレクタである Tim Berners Lee が Web を発明して以来 19 年、Web 用の拡張マ
ークアップ言語である XML が正式勧告となってすでに 10 年を迎える。
そのような意味では
Web はもはや最新技術ではない。膨大な利用者コンテンツを抱える古典的なシステムであ
る。
1990 年代の当初の Web の特徴は、HTML、すなわちハイパーリンクを可能としたマーク
アップ言語を用い、文字コード情報により明示的な構造で内容が記述されていることにあ
った。その基本文法は ISO による汎用マークアップ言語である SGML を用いたが、その単純
さと無料のインターネットという枠組みにより急速に世界を席巻した。当時 OMG（Object
Management Group）の CORBA（Common Object Request Broker Architecture）による分散
オブジェクトによるネットワーク思想がかなり高い技術的な完成度で導入されつつあった
が、
技術的には未完成な Web が、
構造の単純さと低価格で分散オブジェクトを駆逐した[1]。
10 年前に、HTML による Web の技術的な未熟さを補うために、新たに XML が導入され
たと考えることが可能である。HTML のメタ言語は SGML であるが、SGML の汎用性に起因す
る複雑さを排除するために、Web での使用に特化したのが XML である。パーサの負担を減
らすために終了タグを省略不可とし、
木構造への標準的なアクセスのために DOM による API
が定義され、重複要素名を許すために名前空間が導入された。
ところで、XML による情報構造を定義する枠組みが混乱し、今日に至るも解決していな
い。当初は SGML で用いられていた DTD（Document Type Definition）が暫定的という意識
で用いられ、多くの XML 関連仕様が DTD で定められた。その後、XML 自体で XML の構造を
記述する XML Schema が W3C により定められた。XML Schema は、型を用いて構造を定義す
るアプローチであるが、テキストで記述することを特徴とする XML にプログラム言語的な
型による制約を課する意義は疑問である。さらに、個別の XML Schema で定義された型を継
承するような機構は考慮されていないので、せっかく型を定義してもオブジェクト指向的
な再利用のメリットは存在しない。
XML Schema への批判的な観点で OASIS/ISO から RELAXNG
が提案されている。これは XML Schema の煩雑さを除去し、DTD の考え方に近い XML による
構造定義である。現状では、DTD、XML Schema、RELAXNG の鼎立状況が続いており、この状
況が三者のコンテンツを包含するシステムとなり、これらのコンテンツが存続する限り継
続しそうである。
Web サービスは、XML をベースとするクライアントサーバシステムの枠組みの再来で
ある。CORBA が分散オブジェクトの世界で構築した種々の概念は、XML による Web サービス
でも継承されている。すなわち、分散オブジェクトにおけるメッセージ送付が SOAP に、イ
ンタフェースリポジトリが UDDI に、インタフェース定義言語の IDL が WSDL に対応してい
る。CORBA においてインタフェースリポジトリの未完成が、CORBA を局所的な使い方に制約
してしまったように、Web サービスでも UUDI の未完成が Web サービスの広範な適用を妨げ
てしまったことは、同様の失敗の歴史を繰り返していると言える。次世代の Web 技術、Web
- 11 -
サービスは、以上のような失敗の教訓を生かすことから始められねばならない。XML がコ
モディティとして普及した現状の認識と分析が、重要なポイントである。XML は、Java を
はじめとするプログラム言語と、HTML、CSS を中心とする表現系言語の中間的な存在とし
て位置づけられる。プログラム言語が、CPU による論理演算に基づくアルゴリズムとデー
タ型に代表される厳格なデータ構造を扱うのに対し、HTML や CSS は、人間の視覚・聴覚を
中心とする感覚に効果的に作用する領域を扱う。その中間の領域の架け橋となるのが XML
である。
XML によるドキュメント、コンテンツやデータは、必ずしも整理された形態で存在して
いるわけではない。W3C は XML Schema でその枠組みを定義し、OASIS は RELAXNG で定義す
る。以前のドキュメント系のデータは相変わらず DTD で定義する。そのような状況が現状
である。そのような状況は、普及したシステムの常で容易に変わることはない。ただし文
字コードについては、ユニコードに統一されたので、シフト JIS や EUC の膨大な既存デー
タが氾濫している日本にとっては種々の問題が生じている。Web コンテンツとして XML に
準拠した XHTML が提案されて久しいが、HTML の XHTML 化への移行は一向に進展しない。コ
ンピュータと人間の架け橋として期待される XML は、現状では無秩序に散在している。こ
の状況を系統付けるのが、今後の Web 技術・Web サービスへの要件であろう。
コンピュータを含む機械と人間の中間を埋める分野は、昔からマンマシンインタフェー
スやユーザインタフェースとして扱われてきた領域で、古典的にはノーバートウィーナが
サイバネティックスというキーワードで提唱してきた領域でもある[2]。この領域の人間の
知識を扱う部分は、その後、人工知能、知識工学といった歴史を経て、XML の世界ではセ
マンティックウェブやオントロジという領域に発展した。
他方、人間の感覚を扱う部分は、
Xerox PARC の研究開発を経て GUI やデスクトップパブリッシングに発展し、今日の Web の
CSS や XSL に発展していると言える。
この 3.2.1 項は、以上のカテゴリにおける前者の PIM オントロジ、ネットワークオント
ロジ領域について検討していると言えるであろう。他方、3.2.2 項は後者のコンテンツ領
域について検討していると言える。後続の 3.2.1.1 項では、無秩序に増殖する XML コンテ
ンツや HTML コンテンツをメタデータという領域で系統付けるアプローチを提案する。
さら
にこの方法の具体的な応用分野として、ユビキタス情報への適用、すなわち地図情報を中
心とする空間情報と PIM 関連情報について述べている。3.2.1.2 項では、前項における空
間情報の具体的な活用アプリケーションとして、PND（パーソナル ナビゲーション デバイ
ス）を活用するサービスについて調査した結果をまとめている。3.2.1.3 項では、空間情
報と共にユビキタス社会で必要とされる PIM 情報について考察し、デファクト標準化が進
展している PIM 関連情報の交換フォーマットやデバイスに関する最新動向を述べている。
3.2.1.4 項は、前項の PIM オントロジを情報家電のネットワークサービスや管理分野に適
用する可能性を検討するものである。その第一歩として、デジタルリビングにおけるネッ
- 12 -
トワーク利用シナリオと、そのサービスに対して XML メタデータを用いる NETCONF プロト
コルによる実装に関して検討している。
【参考文献】
[1] 大野邦夫；"転機を迎えた分散オブジェクト"、 Computer Today、 1997.1、 No.77
[2] N.ウィーナー（池原訳）
；
“サイバネティックス（第 2 版）
”
、 岩波書店（1962）
3.2.1.1 次世代 Web のサービスのためのアーキテクチャ
(1) コンテンツとそのメタデータ
1990 年代初頭の HTML の爆発的な普及を足がかりにして、Web 技術の中で特に脚光を
浴びた XML とその周辺仕様は、XML を策定した W3C だけに留まらず、幅広い分野、特に標
準化プロジェクトにおいてしばしば用いられてきた。その結果、その全てを把握すること
が困難なほどの、非常に多くのデータフォーマットが XML を基に策定された。XML はメタ
記述言語の一種とされ、主に情報の意味を示唆する「要素名」
「属性名」を持っているが、
どのような名称が有るのかをそれ自体は基本的には規定せず、XML に基づく仕様において
自由に規定できる。これはその普及の足がかりとなった HTML に対する XML の特徴とされる
が、一方で WWW が HTML によって半ば実現してしまった用途や目的を問わず、一つのプラッ
トホーム(HTML と HTTP)で全ての情報やシステムを統合的に扱う環境への期待が、XML に対
してもかけられることとなった。
このような背景の下で、XML による記述言語の乱立と、それらの間での相互運用性の低
さが XML の課題として認識されることとなった。
当然ではあるが、
用途や業種が異なれば、
それぞれにおいて異なる意味を持つ情報が扱われるので、それぞれが個別に記述言語を規
定する結果となる。個々の記述言語では、そのコミュニティにおいて通用する「名称」が
定義される。一方で、他のコミュニティでその名称が示唆する意味を知り、そのコミュニ
ティに通用する観点に翻訳するメカニズムを、XML が持っているわけではない。この課題
において XML が提供する機能は、それらの名称がどのコミュニティによって定義されたも
のなのかを URL によって示す「Namespaces In XML」仕様だけであろう。
更に、XML にはデータの構造を記述するという点において、階層構造以外を採ることが
難しいという問題点を持っている。これはデータのモデリングにおいて、多重継承された
（すなわちメッシュ状のデータ構造を持つ）情報の表現が困難ということをあらわしてい
る。
これもまた横断的な情報交換において、
次のような解決困難な課題を発生させている。
一つの情報を複数の用途・観点において相互に利用したいという用途では、それぞれの
観点に基づくデータモデルが、存在するのは当然である。しかし、XML によって記述した
時点では、そのうちのどれか一つのモデルを採用しなければならない。これでは、採用さ
れたデータモデルに基づくアプリケーション以外で、相当不利な状況が生まれてしまう。
XML の標準のパーサが生成する DOM データ構造が採用された記述言語に依存してしまい、
他の用途・観点で利用する場合には、その用途に適した構造に再変換しなければならない
- 13 -
ためである。これには当然多くの計算機資源が必要となる。なお、WWW 上の HTML コンテン
ツのハイパーリンクによる関係はメッシュ状であり、WWW は文書内の構造と文書間の構造
がミスマッチとなっている。
(2) RDF
RDF は、このような XML の問題点の解決のために XML とは異なるメッシュ形のデー
タ構造を、
分散的な語彙定義に基づいて生成することを可能にしたフレームワークである。
RDF もまた W3C が策定したのだが、
RDF/XML と呼ばれる新たな記述言語によるデータ交換を
前提としていた。先述のように、XML はツリー型のデータ構造の表現には向いているが、
メッシュ形のデータ構造には向いていない。そのため、RDF/XML は「RDF TAX (RDF 税)」の
俗称が付くほど、従来の XML のメカニズムと整合性が悪かった。よって、RDF はそのデー
タモデルのメリットを出せず、XML と比べれば広く引用されることも無かった。
（少なくと
も Web2.0 のブームが始まる前までは）
(3) コンテンツ＋メタデータの埋め込み
このような課題を抱えた中、Web2.0 においてしばしば話題となる microformats は、こ
れに対する一つのゆり戻しともいえる着想に依っている。すなわち、汎用的・横断的な記
述言語として HTML を唯一の特別なホスト言語として扱い、HTML によって記述されたデー
タに、多様な意味を持つ情報をメタデータとして埋め込むことで、より高度な情報の意味
の伝達を横断的に行おうというものである。HTML は、
「スタイル付けされたテキストを主
体とする文書の表示と、それらの文書間の関連性を GUI（ハイパーテキスト）により人に
示す」という目的、すなわち人への表現という文脈と意味を持った記述言語（表現形式）
である。
人が多くの情報を紙に書いた文書として交換するように、文書の表示は多様な業界やコ
ミュニティを横断した汎用的な観点であり、その文書がどの文書を参照しているのかとい
う情報もまた同じく汎用的な観点のため、HTML は個々の業界が規定した記述言語とは異な
る特別な存在として再認識されたものといえよう。HTML のような「表示のためのデータ形
式」は、いくらか広義に解釈すると「人が理解するための表現形式」であり、それに基づ
いて生成されるデータは、狭義のコンテンツ（＝情報財）と称される。すなわち、その形
式は「コンテンツフォーマット」と呼ばれるものであろう。このようなコンテンツフォー
マットとしては、他にも JPEG や MPEG などの画像・動画・音波形フォーマットなどが存在
し、これらもまた横断的に活用されている。
しかしながら、HTML はシステム連携・統合に必要なハイパーテキストによる情報間の
関連付けとメタデータの埋め込みの２つの重要な機能を持っており、これが他のコンテン
ツフォーマットに対する注目すべきメリットといえる。このような経緯から、XML によっ
て規定した記述言語を設けず、HTML を代表とするコンテンツデータの記述言語によるデー
タとそれに埋め込まれたメタデータによって、情報システムを構築しようという取り組み
が、現在広く進捗しつつある。これは、極端な見方をすれば、横断的なデータ交換フォー
- 14 -
マットとしての XML を棄却したものと見ることもできる。
以上のような背景から、まさに様々な意味を持つデータを多様な観点に基づいて横断的
に利用することにより、モードに依らず情報システムを使えるようにするということが目
的とされるマルチモーダルアプリケーションにおいては、XML による新たな記述言語とい
う形で、その意味の情報の標準化を進めることは既に適切な方法とは言いがたく、既存の
コンテンツへの埋め込みを想定した、メタデータとしての分散的な語彙、すなわち、ダブ
リンコアのような RDF に基づく分散的なボキャブラリ(語彙)の規定を進めていくことが、
今後有力になっていくものと考えられる。
更に加えて、人が理解するための表現形式の重要性が再認識された現状を鑑みれば、マ
ルチモーダルアプリケーションで必要になると考えられている、移動体としての人により
密着した情報システム(PIM)のための表現形式と、それらの間で交わされる基本的な意味を
表す語彙が、
今後新たに必要となってくることは明らかであろう。
以下にその例を挙げる。
・カレンダー
・予定表
・住所録
・日記
・音声（対話性を含む）
・地図
・経路誘導
・漫画
・文庫本
・リモートコントローラ
3.2.1.2
空間情報サービス
(1) PND
マルチモーダルアプリケーション分野における 2007 年の世界規模の顕著な変化の
一つとして、PND（パーソナル ナビゲーション デバイス）の爆発的な普及を挙げること
ができるだろう。
（2007 年の出荷台数は 2000 万台を超えると予想され、欧米のみならず自
動車の普及に呼応して中国・インド市場も急成長している）
PND は、それが提供するアプリケーションは一見すると一世代前の日本のカーナビゲー
ションシステム（カーナビ）程度と言っても良いものであるが、それが基にしている技術、
対象としている利用者を見ると、安価なカーナビとして無視することはできない。
(2) PND の背景技術
PND は、組み込み系のシステムから進化した日本のカーナビと異なり、PIM のためのキー
デバイスとして一時期脚光を浴びた PDA（2001 年頃が最盛期：1500 万台市場、現在は半分
以下に減少）を基にしている。そのオペレーティングシステムは WindowsCE であり、縦横
- 15 -
の向きは異なるもののタッチパネルを備えた 4 インチ前後の画面や、SD フラッシュメモリ
による 2 次記憶装置、内蔵リチウムイオンバッテリなど、各種インタフェースも PDA と酷
似し、またその製造メーカも、かつて PDA に取り組んでいた人材が重要な位置を占めてい
る。大きく異なるのは、近年著しく性能（感度と測位持間）が向上した GPS レシーバ（多
くは SiRF 社の StarIII チップセットを用いており、
補助センサを搭載しているものの、
GPS
レシーバの性能が低い旧世代のカーナビと比べれば、十分な測位性能を持っている）を内
蔵し、旧世代並とはいえ完成度の高いナビゲーションソフトウェアを内蔵している点、そ
してそれらを支える基本ハードウェアである CPU やメモリなどの大幅な性能向上であろう。
PDA はデスクトップ PC の製造モデルをベースに構築されたプラットホームであり、デフ
ァクト標準を基に、組み込み型のシステムと比べ低コストで生産可能なことと、ソフトウ
ェアの開発も PC のデファクト標準(Windows)との互換性の高さから、大幅に容易な開発環
境を提供していた。しかし、既にその市場規模が最盛期の PDA を上回り、来年以降も大幅
な市場拡大が予想されている PND を見れば、過去の PDA はキラーアプリケーションとそれ
を支えられるだけの基本性能が達成できていなかった、といえよう。
(3) 空間情報プラットホーム
このような背景から、従来は特別なもの(キラーアプリケーション)として取り上げられ
ることが少なかった地図や位置情報、そしてそれらによる多様な実空間上のナビゲートは、
PIM の重要な要素であることが明らかになりつつあると言えよう。しかしながら、地図や
空間情報に関する標準化活動は、先に挙げたような多様な用途を横断したアーキテクチャ
として検討がなされているとは言えず、未だ一部の専門業界（測量業界など）に閉じた検
討が続けられているに過ぎない。
一方で PND に関しても、例えばノキアが約１兆円で大手地図データベンダの NavTeq
を買収したように、データからアプリケーションに至る全てのソフトウェアを資金力で押
さえることによる独占的垂直統合ビジネスモデルが有るに過ぎず、多様な企業が参加し、
多様な情報システムが連携して稼動するような協調領域は、未だ創出されていない。すな
わち、地図・ナビゲーション分野においては、ソフトウェアやサービスの多様化と低コス
ト化に関しては、未だ解決されていないということである。もちろん、ハードウェアとオ
ペレーティングシステムのレイヤにおいては、デファクト標準による協調領域が成立しつ
つあることが、PND の低価格化を実現していることは言うまでも無い。
一方、日本では 2007 年は携帯電話位置通知制度が施行された年である。これは、全て
の携帯電話に高精度測位システムが搭載されることを意味すると共に、そのインタフェー
スの標準化が進行し、ひいてはその民間活用が促される状況が確立されつつあることを意
味する。すなわち、携帯電話においても地図や位置情報が利活用可能な状況が完成し、そ
れを活用するサービスの市場も立ち上がっている。言うまでも無く、PND の市場規模と比
べても、携帯電話の現在の市場規模は遥かに大きく、しかも情報サービスのための課金モ
デルが確立している。通信機能や情報処理能力においてもひけをとらない。課題は、カー
- 16 -
ナビ同様に、高コストで開発が困難な組み込みシステムであるということ、またソフトウ
ェアやサービスに関する横断的なプラットホームもまだ確立していないことである。
3.2.1.3 PIM 関連情報とその応用
(1) システム間での PIM 情報交換
現在、情報の提示方法は、PUSH 型が一般的だが、今後はユーザの情報に応じて、最適
な情報が提示される PULL 型及びパーソナライゼーションが重要になっていくと考えられ
る。実際に今でも Web の世界では、Google AdWords や、Amazon のレコメンデーション機能
といったサービスが提供され、他の Web サービスとの差別化が図られている。しかし、Web
の世界では、Google や Amazon といったユーザ情報・履歴を取得できるプレイヤが、その
情報を利用してサービスを展開するに留まっていると言える。今後、情報システムがあら
ゆるシーンでユーザに適切な情報提示を行うためには、異なるシステム間でのユーザ情報
の交換が必要になるだろう。
既に、Web のアプリケーションでは、異なるシステム間でのユーザ情報の交換・システ
ム連携が始まっている。Web 2.0、マッシュアップといったキーワードで、Web API を利用
した連携が盛んだが、中でも、ユーザ情報（PIM）を扱ったものに注目したい。MyRadar は、
CSL の暦本氏によるもので、Twitter に位置情報を埋め込むことができる。Google Calendar
に代表されるスケジュールサービスは、スケジュール情報を他のユーザと共有したり、ま
た、他の Web アプリケーションで保存する予定を iCal 形式で取得できる。また、スケジュ
ールを扱うサービスでは、位置情報を埋め込むことができるようになっている。認証を伴
う Web アプリケーションでは、認証機能を API として切り出し、提供するサイトが増えて
きており、OpenID のような統一方法が提案されている。
OpenID では、認証を行う方法が定義されているとともに、OpenID 属性交換仕様書
（Attribute Exchange）では、ユーザ情報の公開の管理手段が定義されている。このよう
に Web の世界では、パーソナライゼーション、また、システム間でのユーザ情報の交換が
始まっている。今後は、Web の世界だけでなく、情報家電、街中広告、携帯電話、携帯デ
バイスのように、人々が情報を受け取るあらゆるシーンで、PULL 型の情報提供がされるよ
うになっていくだろう。このとき、ユーザが携帯するモバイル端末は、ユーザの行動履歴・
ユーザ情報を格納するのに最も適したデバイスであろう。
(2) PIM についての課題
PIM（Personal Information Management）では、スケジュール、アドレス帳、ToDo、メ
モ帳といった情報を管理する。PIM はこれまで、PDA やスマートフォンと呼ばれる携帯端末
で提供されてきた。また、PDA やスマートフォンでは、合せて、メーラー、電子辞書、電
卓といった機能が提供されることが多い。PIM が扱う情報は、人々の生活、特にビジネス
パーソンにとっては、欠かすことのできないものである。しかし、それらの機能を提供す
る PDA は普及しているとは言い難く、
手帳を利用する人がほとんどだろう。
なぜだろうか。
- 17 -
携帯端末は、携帯性の確保が最も重要であり、よって、重量・サイズに制限がある。特
に画面サイズは小さく、3～5 インチである。また、入力手段も、PC のようなキーボードや
マウスが使えず、タッチパネル、スタイラス、小さなキーボードなどが主要な入力手段と
なる。ボタンのようなウィジェットは、タッチパネルでの操作は可能だが、文字入力を伴
う作業はキーボードがないと難しい。これらの制限から、現在の携帯端末は、機能的には
ビューワとしての用途には向くが、オーサリングを行うのは困難であろう。
しかし、PIM ではスピーディな文字入力が求められる。スケジュールの入力、Todo、メ
モといった情報は、その場で即座に参照・入力できなければならない。参照は GUI の改善・
CPU 向上によって解決するだろうが、文字入力は入力手段の問題の解決が必要である。
PIM というアプリケーションにおいては、携帯性とスピーディな文字入力が必須要件で
ある。携帯性は、コンピュータの省電力化、小型化によって、PDA・スマートフォンとして
実現してきた。一方、文字入力については上記の課題があり、現状の PDA・スマートフォ
ンでは PIM の要件を満たすのは難しい。これらの要件を満たすデバイスとして、PDA より
も紙の手帳を選択する場合も多いだろう。
(3) 携帯端末の進化と PIM
PIM は、情報システムのパーソナライゼーションを実現するのに重要なアプリケーショ
ンである。PIM にはユーザの情報が集約されており、特にユーザのコンテキストを最も直
截的に得ることができる。
携帯端末の進化は著しく、特に、基本性能（CPU・メモリ）の向上により、これまで PC
で実装されてきたような GUI アプリケーションの動作が容易になっていくだろう。また、
通信機能（WiFi、事業者系通信サービスの利用）の搭載は当然になってきている。これに
より、Web サービスなどによる他システムとの連携が容易になる。Web の世界で実現されて
いるパーソナライゼーションは、携帯端末での利用でも特に有用だろう。
また、携帯端末は、ユーザが常に所持するため、認証が成立しやすい。他システムとの
連携を考える場合、他システムが Web のシステムであれば、携帯端末からのアクセスによ
りユーザの特定は行いやすい。また、WiFi などの近距離無線機能、RFID の搭載によって、
Web だけでなく現実世界に配置されているシステムとの接続、ユーザ認証も容易である。
このように、携帯端末の基本性能向上と通信機能の拡充、PIM アプリケーションとの組
み合わせで、Web だけでなく、どこにいても情報提供のパーソナライゼーションが可能に
なるだろう。
他方、PIM アプリケーションにとっては、前述のようにユーザが扱うときの筺体・イン
タフェースが課題となっている。iPhone はビューワとして革新的なユーザインタフェース
であったが、文字入力で利用する仮想キーボードは、PIM アプリケーションが求めるレベ
ルに達しているかは疑問が残る。一般的な PDA でのスタイラスによる手書き文字入力も、
認識率と変換時間の向上が望まれる。
また、PIM 情報の連携を行う場合でも、PIM は Personal であるが故に、情報の書き方が
- 18 -
個人によってばらばらで、システム間の連携が困難な場合も多い。位置情報が緯度経度で
表され、異なるシステムでも利用可能になっているように、PIM においても、ユーザの属
性情報、スケジュール、ToDo などの情報を共通した語彙で表すことが重要である。
3.2.1.4 ネットワークの自動設定
ネットワークの IP 化、ブロードバンド化の進展で、家庭環境における情報通信機器の利
用形態が変化しつつある。特に大画面のデジタル TV やそのコンテンツ・レコーダの普及に
より、デジタルリビングやホームシアタといった用語が一般化しつつあり、豊かで幸福な
家庭生活のコンセプトを形成しつつある。このようなハードウエアを使いこなすためには、
使いやすい操作性と容易なネットワーク接続性が要求される。ところが現状では、設定に
は専門的な知識と技術が必要とされ、誰でもができるものではない。
このような問題を解決するために、現在、ネットワーク設定の自動化に関する標準化が
行われている。まずは大規模なネットワーク機器を対象にしているが、技術の進歩ととも
にいずれ家庭にも入ってくると考えられる。現状ではまだ PIM との関連は薄いが、家電と
の連携を考えた時には、PIM 情報を利用しなければユーザに的確な設定情報を提供するこ
とができない。そのための第一歩として、ネットワークの動作の抽象化を行うためにデー
タモデルの検討が行われている。本節では、まずネットワーク設定の自動化とデータモデ
ルに関する標準化をまとめ、次にネットワークの自動設定が実現することで可能となるシ
ナリオを提示する。
(1) ネットワーク設定の自動化に関する標準化
ネットワーク設定の自動化に関する標準化として代表的なものは、IETF(Internet
Engineering Task Force)で議論されている NETCONF である。NETCONF はプロトコルのみで
あるが、別途ネットワーク運用及びデータモデルの検討も行われている。
(2) ネットワークの自動設定プロトコル NETCONF
NETCONF は IETF (Internet Engineering Task Force、 http://www.ietf.org/) で標準
化が進めら
れている遠隔からネットワーク機器の設定を行うプロトコルである。XML をベースとした
プロトコルで、オブジェクトとしてインターネット機器へ送るコマンドとパラメータが定
義されている。ネットワーク機器に送る情報は XML で記述され、インタフェースとしては
RPC を利用する。
NETCONF の標準化はまだ基本部分が終了したにすぎないが、プロトコルが XML である
ことで新たな可能性が期待できる。構造化されたテキスト文書であるため再利用性が高い
こと、XML の豊富なツール群が利用できること、データベースや Web 技術との親和性が高
いことなどである。つまり、設定情報それだけでなく、他のツールやソフトウェアと組み
合わせて使うことが容易になる。IETF で議論されている NETCONF に関する RFC は、以下の
通りである。
・RFC4741: NETCONF Configuration Protocol
- 19 -
・RFC4742: Using the NETCONF Configuration Protocol over Secure Shell (SSH)
・RFC4743: Using the Network Configuration Protocol (NETCONF) Over the Simple
Object Access Protocol (SOAP)
・RFC4744: Using the NETCONF Protocol over Blocks Extensible Exchange Protocol
(BEEP)
(3) ネットワーク運用とデータモデルの標準化
ネットワークの運用とデータモデルに関しては、INTAP/OSMIC 企画委員会
(http://www.net.intap.or.jp/INTAP/osmic/index.html)で標準化が行われており、以下の
要件と標準が定められている。
・運用管理ツールの要件
・MAXI-NM-1.0 (インターネット環境におけるネットワーク運用管理システム相互運用
のためのフレームワーク)
(4) ネットワーク設定の自動化シナリオ
現在のところ NETCONF は、キャリアネットやエンタープライズ向けの一部で実装され
ているに過ぎないが、今後標準化と開発とが進めば、家庭用のルータにも実装されるよう
になるだろう。本稿ではそのようなルータが家庭にも普及しているものとして利用シナリ
オを検討する。なお、本シナリオの詳細については、画像電子学会 VMA 研究会にて報告し
た。
本シナリオでは、販売者と利用者の他に、利用者向けに設定などのサービスを行うネッ
トワークサービス運営者を導入する。この運営者が、利用者の家庭内のネットワーク情報
及び PIM 情報等を管理することで、利用者にとって最適な情報提供及びネットワーク設定
を行う。価値観が多様化する現在、今後の家電には個々の利用者の使い方、嗜好などに対
応して提供する情報や動作が変化することが求められる。その場合に、利用者情報を一括
管理するネットワークサービス運営者の役割が大きくなると考えられる。
ネットワークサービス運営者は、販売店と契約し利用者に紹介してもらうことによって、
利用者と直接契約し、顧客のプロファイル、購入機器、接続される機器、を系統的に履歴
管理するデータベースを持ち、顧客の種々の問い合わせに備えるような形態を想定してい
る。
(5) ネットワーク設定の自動化
家庭環境におけるネットワーク設定の自動化について考えてみよう。ここでは、PC を使
わない一般ユーザにとっても設定が容易であるようなシナリオを検討する。具体的には、
消費者向けのネットワークサービス運営者に支援してもらうことを考える。
(6) ユーザ側のシナリオ
一戸建て住宅を新築した A さんが、販売店で S 社製のデジタル TV を購入した。販売店
は、M 社というネットワーク運営サービス企業が、1 年間は無償で、1 年後からは有償で今
後の運営サービスに関しては責任を持つということで紹介した。
- 20 -
しばらく経って、A さんは T 社製のコンテンツ・レコーダを購入した。デジタル TV と
はメーカが異なるので接続に関する操作説明は、各々のメーカのマニュアルには記されて
いない。だが、そのような情報は M 社が提供する Web マニュアルには記されており、索引
から検索された項目について、メニュー選択して、映像を眺めつつ説明を聞きながら、作
業すれば接続は完了してしまった。この作業の過程で、T 社製のコンテンツ・レコーダが M
社のデータベースに追加された。
T 社製のコンテンツ・レコーダを購入して間もなく、A さんの実家が U 社製のデジタル
TV を購入した。A さんの実家の機器は、M 社のデータベースに A さんの関連接続機器とし
て登録された。実家の両親は、最近、幼稚園児の孫の運動会があったことを思い出し、そ
の映像を見たいと言い出した。自宅のコンテンツ・レコーダにその映像を蓄積し、自宅で
は大画面で見ていたのだが、それを遠隔の実家から見ることにした。自宅に電話して、T
社製のコンテンツ・レコーダの電源を入れてもらい、あとはマニュアル通りに操作したと
ころ、自宅で見たのと同様な映像が映し出された。
(7) ネットワークサービス側のシナリオ
本節では、視点を変えて前節と同じシナリオがネットワークサービス運営会社である M
社側でどう見えるかを検討する。まず、A さんが S 社製のデジタル TV を購入して M 社のサ
ービスに契約する。このときに M 社の顧客データベースには、A さんの自宅のネットワー
ク構成が登録される。次に、A さんが T 社製のコンテンツ・レコーダを購入した。レコー
ダを接続するとルータが自動的に検知して、すでに登録されているデジタル TV との接続方
法に関する Web マニュアルを検索して表示する。情報が揃ったところでルータに対し
NETCONF で設定情報の変更を行う。
同時期に A さんの実家がデジタル TV を購入したときは、
実家のデジタル TV が A さんと関連があるという情報が加わる。
さて、A さんの実家のデジタル TV で A さんの自宅にあるレコーダの動画を見ることに
なった。デジタル TV のメニューは、M 社側で自動構成された Web マニュアルが表示され、
関連機器の操作という画面が現れる。そして、NETCONF を利用して転送元ルータと転送先
ルータの間に必要な帯域を確保した VPN を張り、セキュアな伝送路を用意する。
(8) PIM 情報の利用
実際に利用する際には、よく行う操作を記録しておけば、毎回同じ画面を呼び出して操
作を行う必要はない。このような情報は A さんの PIM 情報として記録しておき、状況に応
じて呼び出すことができれば、さらに操作性が上がる。ネットワークオペレータ側では、
このような情報も記録することでサービスを向上させることができるだろう。
【参考文献】
－ 新 麗、 永田 真之、 大野 邦夫、 “ネットワーク設定の自動化シナリオとプロトタ
イプの設計”、画像電子学会第 20 回 VMA 研究会、 2008.1.
- 21 -
3.2.2 コンテンツ生成・流通・管理の概念モデルに基づく交換フォーマットの標準化
マルチモーダルウェブを活用するサービスとして、コンテンツの生成・流通・管理シス
テムにも影響を与えつつある。そこではコンテンツの交換フォーマットを標準化してマル
チモーダルウェブへ対応することが要請されている。
デジタルコンテンツの生成・流通・管理の概念モデルについては、2006 年 7 月 24 日に、
そ の 概 念 モ デ ル が 国 際 規 格 （ IEC/TS 62229 “Multimedia systems and equipment Multimedia e-publishing and e-books - Conceptual model for multimedia e-publishing
(TC 100)”）として公布されている。これは本委員会活動に連なる委員会による歴年の活
動の成果の一つである。この概念モデルをさらに発展させて、 Proofreading ML を位置
づけた概念モデル図が図 1 である。IEC TC100/TA10 においても、昨年までの委員会活動の
提案に基づき Proofreading
ML の検討を続けている。
反映
図1
図 1 において、著者から出版社にわたるデータを Submission format とし、出版社と印
刷会社間での交換フォーマットが Generic format、印刷会社から読者あるいは読書装置に
送られるデータが Reader’s format である。このうち Generic format が IEC 62448 とし
て国際規格となっている。
本項では、電子メディアに適した文書スタイルを再検討し、Submission format との関
係を再整理する。その上で、マルチモーダルウェブサービスが進展する上で求められる高
精細ディスプレイにおけるフォント技術に注目して実証的調査研究を行った。
さらに、概念モデルで課題となってきた Proofreading ML について調査した。
3.2.2.1 電子メディアに適した新しい文書スタイル関連
(1) 生活空間と文章による情報伝達
- 22 -
生活空間の中で身近に存在する文章の類いとしては、新聞の記事、雑誌のコラム、文庫
本や単行本をはじめとする書籍類、何がしかの報告書、子どもたちの本棚に山積する教科
書類などがある。
一方、最近ではオフィスや仕事の移動中に限らず、自宅でもインターネットにアクセス
し、調べものや電子メールを読む機会が多い。ブログを読んだりコメントを書いたりして
いる人たちも多く、デジタルの世界でも文章に触れる機会がずいぶん増えている。
そういった意味では、
「新刊書籍の販売部数の落ち込み＝活字離れ」といった一部の単純
な捉え方ではなく、むしろテキストを主体としたコミュニケーションは街に溶け込んで増
え続けていると見るべきである。
文章が生活空間の中で思想や情報を相手に伝えるための道具である以上、アナログやデ
ジタルといった環境や手段の相違に本質的には関係がない。
(2) 文書表現・表示加工技術の目的
さて、その文章によって情報を相手に正確に伝えようとする試みの中に文書表現や表示
加工技術が含まれる。情報伝達のプロセスで言えば、発信された情報の意味が相手に正し
く理解されてはじめてその伝達プロセスは完了するが、この情報の理解において、誤読さ
せないように視線上のノイズを減らし、見栄えを良くし、文書に記述された文章そのもの
への感情移入を促進させ、正確にかつ素早く理解できるように整形された情報を提供する
ことこそが文書表現・表示加工技術の目的に他ならない。
(3) 表現手法の方向性
文書表現加工技術における具体的な表現手法は、情報利用者の主要言語、慣習、年齢、
趣味趣向といった要素や文章の記述だけでなく、アナログやデジタルなどの環境、判型や
画面サイズのような表示なども含まれる。さまざまな変化する要素が配慮され、目的の達
成に向けた最適化が相乗的に図られるべきである。よって、新しい表現・表示メディアが
誕生すれば、その新しいメディアと利用者にとって最適な表現・表示手法が確立されるこ
とになる。
(4) 印刷出版物における組版技術
印刷出版物における文書表現・表示加工技術は、組版技術を核としながら現在のさまざ
まな文書表現・表示メディアの中で最も確立していると思われる。縦組、横組の区別や、
１ページ内の字詰め数、行数、段数等をはじめ、柱・ノンブルの位置や文字サイズ、和欧
文混在時の和文と隣り合った欧文の絶妙な空き量調整、約物の調整、行頭行末の禁則、ル
ビの配置方法、圏点や傍線による強調方法、図版・表の取り扱い等の細部に至るまで、伝
統的な日本語文章の組版ルールが確立し、多くの出版物はその組版ルールを搭載したペー
ジレイアウトソフトによって製造されるため、極めて高品質な文書の表現・表示加工が確
保されている。
なお、組版技術そのものは、読者をより自然に文章に注力させるための技術であり、良
い組版技術こそ読者からは意識されないという、相反する特徴を持っている。
- 23 -
(5) 組版ルールと国際規格
組版技術の源泉となる組版ルールは、本来その対応する言語や表記法、慣習等によって
形成されるため、各国や地域ごとに各々ユニークな面を持っており一意ではない。例えば
日本語組版における版面の設計は、字詰め数、行数、段数等、いわゆる版面の中心から（本
文のテキストを配置する矩形から）設計が行われるのに対して、欧米系の版面設計はこれ
とは異なり、天地左右の空き量（マージン）の外側から先に設計する。これは文字の送り
が全角を基準とする日本語と、プロポーショナルを基準とする欧米系の言語の違いによる
もので、いずれも該当する言語圏の版面製作者にとっては重要なものである。
しかし、Web をはじめとするグローバルな領域においては、国際標準的な言語やルール
が第一ターゲットとして優先され易いため、スタイルシートや Web ブラウザの表示機能等
において、先の例のような日本語固有の機能がサポートがなされていない場合があり、ル
ビの括り出しや、縦組から横組への変換など、しばしば情報発信者側が情報の表現方法を
妥協せざるを得ない状況が起きている。
現在、W3C に JIS X 4051:2004「日本語文書の組版方法」の一部を近い将来のスタイルシ
ート規約に組み込むべく活動している日本語組版検討グループがあるが、Web コンテンツ
における日本語文書の表現力アップに繋がるこの活動に注目したいと思う。
(6) デジタルコンテンツにおける利便性の追求
Web ブラウザで閲覧するコンテンツをはじめ、デジタルコンテンツの世界では、印刷物
で言う物理的に表現領域が限定されたページと言う単位の概念が無い。読者は対象コンテ
ンツのすべてを、画面をスクロールさせながら読んでいる。また、自分の趣向に合わせて
表示する文字の大きさや書体などを変更出来るようになっており、印刷物とは異なり、表
現ファクタの一部を利用者に解放することによって、利用者一人一人に合致した利便性を
確保しようとしている。
(7) 携帯電話のもたらした表示革命
生活必需品としての情報端末の地位が定着した携帯電話も、文書表示装置として見るこ
とができよう。現在の携帯電話には、レーザープリンタの解像度に近い 300dpi クラスの高
精細液晶ディスプレイを搭載したものも増えている。しかし 3.5 インチ大の小さい画面の
表示領域や、省電力設計等によって、必ずしも十分な表示装置とは言えない。少なくとも
古典的な日本語組版による文書表現という概念は通用しない。
一方、10 代 20 代の若い世代を中心に携帯電話用の電子書籍（ケータイノベル）の読者
が増加しているのも事実である。ディスプレイの解像度をあげることだけが、利用者の要
求に応えることにはならないのである。
(8) 現状分析のまとめ
以上のように、文書表現・表示加工技術の観点から、代表的な幾つかの利用シーンで現
状の分析を試みた。どの表示メディアでも読者にとって誤読しにくく、見栄えが良く、文
書内容そのものに集中できるように情報を提供するが基本である。さらに読者が求める品
- 24 -
質や表示メディアの特性、あるいはデバイスのハードウェア的な制約事項等によって最適
な表現方法に違いがあることも必然的である。今後も新しい表示メディアが出現するたび
に、最適な表現手法の確立が課題となるだろう。
(9) 電子メディアに適した文書スタイルの実現に向けて
E-Book/e-Publishing 概念モデル（3.2.2 項の図 1）に照らし合わせながら電子メディア
に適した文書スタイルの実現について考えてみよう。この図 1 の右側にある
Reader/Reading device ブロックが、読者が直接手にする各文書表示メディアであり、こ
れらのデバイスは、読者のユーザビリティやホスピタリティの追及によって今後ますます
性能を上げると共に、多種多様化が行われる可能性が高く、かつ前述したように各々の表
現手法が一意ではない。
このような環境下において、種々の端末に適合した文書表現・表示加工を行い、読者へ
提供する役割を担うのが概念モデルの中央にある e-Publishing Market ブロックである。
e-Publishing Market ブロックが担う役割を一元化されたデータソースで合理的に行お
うとした場合、技術的に言えば、まずコンテンツそのものは十分なメンテナンス性を確保
した上で、緻密に細分化され、文構造細部の要素まで特定できる形式で保管されているこ
とが、コンテンツのメディア展開対応力を向上させるという観点からも望ましい。なお、
この文構造細部の特定要件（どこまで細分化するか）は、想定する Reader/Reading device
での表現要件に大きく依存する。
また、サービス実行時には各々の文書表示デバイスに対応した文構造要素とスタイル情
報をマッピングしたマッピングテーブルが必要となる。
実際のサービスは読者のリクエストに応じ、膨大なデータベースの中から動的に該当コ
ンテンツの抽出が行われ、同じく動的に生成されたマッピングテーブルによって自動的に
端末に適合した文書表現加工が行われた後、読者の表示デバイスへ提供される。
3.2.2.2 電子メディアに適した新しいフォント技術関連
インターネットの登場から十余年の間で、情報流通の基盤が従来のペーパーメディアか
らデジタル・ネットワーク環境へと大きく変容を遂げて来た。現在では、情報の生成から
編集・加工、配信の仕方、さらには利用者の情報への接し方も多様化が進んでいる。昨今、
メディアの多様化により活字離れが叫ばれている。その一方で、TV 画面での字幕や、PC、
携帯電話でのメールやウェブコンテンツ、学習の場や旅行先などでの電子辞書の利用など、
ディスプレイ環境下で文字を読む機会は著しい増加を遂げている。
ここでは、100 年以上もの間、印刷という産業領域の中で培ってきた「秀英明朝体」書
体の品質を継承しつつ、デジタル・ネットワーク環境へ適用させていくための取組みを紹
介する。なお、本稿は月刊「ディスプレイ」2006 年 11 月号の記事を元にしている。
(1) コンテンツ流通に関わるディスプレイ環境下の動向
文字は、情報発信者の思いを言葉・文章として忠実に提示するコミュニケーションツー
- 25 -
ルである。従って、コンテンツ(情報の内容)の動向に合わせて変化を求められる。
ここで、いくつかのコンテンツのジャンルについて動向を述べることで、ディスプレイ
環境下で文字に求められるものの背景を示すこととする。
a) 出版コンテンツ
「出版月報 2008 年 1 月号」の「2007 年出版物発行・販売概況」によると、2007 年出版
物販売額は 3.1％減の 2 兆 853 億円で書籍は前年の反動と低価格商品にシフトし落ち込み、
雑誌は 98 年から 10 年連続のマイナスとなった。
一方で電子書籍の市場動向は、2005 年度をターニングポイントとして、これまで主流で
あった PC/PDA 向けから、新たに携帯電話向け市場が急激な成長を遂げている。シード・プ
ランニング社の「CD-ROM 版コミック配信ビジネスと対応端末市場動向」によると、2006
年度の電子書籍市場の規模は「280 億円」で、前年(100 億円)比 280％の伸びとなった。
内訳は、電子コミック分野が「190 億円」と電子書籍市場の 68%を占めており、その内、
ケータイ向けが 165 億円で前年（25 億円）比 660％で全体の 87％を占める。PC/PDA 向けで
「25 億円」で、前年（15 億円）比 167％の伸びとなる。この電子コミック分野は 2012 年
には、710 億円（電子書籍全体では 930 億円）に成長すると想定される。
また、電子出版の成功事例として、専用端末による「電子辞書」がある。電子辞書は 1990
年代初頭に出版社が提供した辞書コンテンツを搭載した専用機として登場した。その後、
1990 年代末に、安価な厳選収録型が爆発的に売れ始め、さらに 2000 年代に入って出版社
から提供される印刷辞書の多くを収録したフルコンテンツ版が主流となった。販売台数は
安価なタイプが売れた 2000 年がいったんピークとなるが、フルコンテンツ版に移行するこ
とで平均単価が上がり売り上げは伸びている。2005 年の市場規模は 330 万台、600 億円市
場と推定されている。
従来は、主に家電ルートで販売されていたが、近年、学校向け販促が行われ書店も積極
的に扱っている。これに対し印刷辞書市場は、かつて年間の販売冊数で 1000～1200 万冊と
いわれていたのが、今では 800 万冊程度であり、売上げは 10 年間で 300 億円から 250 億円
まで縮小したといわれている（
『新文化』2003.8.21 号）
。辞書販売の主流は学習辞書であ
り、少子化による学習者人口の減少を考慮したとしても、明らかに電子辞書の影響は受け
ている。電子辞書は 1 台に英和、和英、英英、国語、漢和などの各辞典を基本に、数十点
分の辞書が収められている。印刷辞書に換算すれば、販売冊数でも印刷辞書の販売部数を
超えた市場を形成している。電子辞書の実売価格は収録されている辞書の価格合計とほぼ
同額か安くなっており、携帯性に加え価格面でも優位性がある。
この様に、出版系も中長期で見ると「オンペーパー → オンスクリーン」へと利用環
境が広がっていくことは明らかである。
b) 放送コンテンツ
2004 年 12 月のデジタル放送開始以降、急激に完全デジタルの流れが進展している。そ
んな中、サービス向上の一環として、NHK をはじめとして各局とも字幕付与率の向上が著
- 26 -
しい。放送の公共性から言っても、主に難聴者の方々を対象とした「クローズドキャプシ
ョン」だけでなく、より簡潔で正確に情報を伝える手法として、動画・音声だけでなく字
幕による要約などを表示することが広い範囲の視聴者にとっても効果的な情報伝達と思わ
れ、
「観る、聴く → 観る、聴く、読む」へと「オープンキャプション」が多用化される
方向にある。
c) 公開情報
ユビキタス時代を志向したネットワーク環境としては、「ナローバンド(文字主体)
→
ブロードバンド(動画・音声主体)」へと変遷が著しい。また、情報流通環境の進展に伴っ
て、公共性のある情報公開は、一般生活情報から歴史資料のアーカイブに至るまで高まる
一方である。今後は、画像・音声と文字との関係は利用者へ「正確な情報伝達を補完」し
たり、
「必要な情報へたどり着くための検索性」を高めるという観点から、文字が担うべき
機能は増えていくものと思われる。
(2) ディスプレイフォントの現状
明朝体は金属活字から DTP へと技術基盤こそ変われども、主に印刷を目的として変遷を
遂げてきた。印刷では主に 1、200～2、400dpi の解像度で出力がなされるのに対し、ディ
スプレイの画面解像度は 100～200ppi 程度(最近の携帯電話では 300ppi を超えるものが増
えてきている)である。それ故に、印刷では忠実に表現されてきたシャープな横画や自由闊
達な仮名の曲線、画数の多い漢字などの再現性が悪く、視認性が低下してしまう。
このままでは、印刷物では日本語の標準的な書体である明朝体が、ディスプレイ表示に
は不向きな書体とされてしまう。書体メーカの中には印刷書体をディスプレイ環境へ適応
させるために横画を著しく太めた‘テレビ明朝’などを作成しているところもあるが、本
来、明朝体のデザインが保有する‘品格’を損なうものが多い。
従来、明朝体の特徴の一つである横画の細さが低解像度になると視認性を損ねるとの説
があった。これに対して、存在感のある縦画や‘ウロコ’による横画の補完により視認性
の向上が可能であり、それによって豊かな情報表現を実現するために明朝体が活用できる
と
いう仮定の元、実験に取り組んだ。
(3) 実証実験によるディスプレイのための適性フォント
この結果「細いウエイト（L）は横画と縦画の太さ比が小さいほうが判別性が高い」こと
と、
「太いウエイト（B）では逆がよい」という評価が出た。
(4) 今後の対応
以上のように、実証実験を踏まえて評価版となるフォントを開発した。実証実験による
知見と成果については、3.3.2.1 項で述べることとする。
従来の出版分野をはじめとする冊子体では、表現要素としての美しさを支えるデザイン
性もさることながら、原典に忠実な正確な字体や外字を保有することを求められてきた。
画一的なファミリフォントは別として、これまでの文字開発は、1 文字 1 文字の字形にこ
- 27 -
だわるあまりコストと納期を度外視したものや、技術の進展に適用した流用性の低いもの
になりがちだった。これまでにも小型液晶表示で視認性の高いフォントとしてシャープの
LC フォントへの取組みがあり、携帯電話、PDA 及び電子辞書に効率的に搭載されている。
今後も、ディスプレイの解像度の向上や、搭載文字数の増加など技術的進展が一層図られ
ることは想像に難くない。
【参考文献】
－ 国際大学 GLOCOM IECP 研究会 資料「デジタルコミュニケーション環境における文
字」2005.1.26
＆ 「知場」intelplace＃101 2005.5
－ 日経 BP 社「日経デザイン 5 月号」 2005.5
－ 財団法人日本規格協会 情報技術標準化研究センター「平成 17 年度報告書」
－ シード・プランニング社「CD-ROM 版コミック配信ビジネスと対応端末市場動向」
－ 出版科学研究所「出版月報１月号」2008.1
－ 新文化
3.2.2.3
2003.8.21
校正概念の整理と Proofreading ML の検討
コンテンツ生成・流通・管理の概念モデルに基づく実用的な文書生成環境について深耕・
検証するために、校正（Proofreading）の考え方整理及びマークアップ言語の標準化に関
する検討を行った。
(1) Proofreading の考え方
テキスト系コンテンツの生成工程において校正は重要である。たった１語の過不足がコ
ンテンツの価値をまったく喪失することもあることは、17 世紀英国の「姦淫聖書」（The
Wicked Bible）の例を出すまでもない。
しかし実際には誤植は後を絶たない。誤植のない本はないと言われるほどである。それ
は校正作業を軽視しているというより、従来の校正作業がほとんど「一人の」個人的な能
力に依存する面が強いことに関係している。すなわち複眼的なチェック機構が働きにくい。
Web 環境の進歩によって、コンテンツを時空を越えて遍在させることが可能になった。
換言すれば、安全かつ確実に「いつでも・どこでも・だれでも」一つのコンテンツにアク
セスすることができ、複眼的なチェックを可能にする環境が現実的になったのである。
しかし Web 上で汎用的な校正を行う仕組みは、いまのところ存在していない。
具体的には、 Submission Format 、Generic Format、 Reader’s Format の間を自由に
文書データ、校正指示データが行き来でき、効率的な校正作業ができる Proofreading ML
の実現が望まれる。
そこで現在検討しているコンテンツ生成・流通・管理の概念モデルに適用させる
Proofreading の仕組みについて検討した。
(2) 従来における「校正」の定義
『広辞苑』、『日本語大字典』によれば、「校正」を次のように定義している。
- 28 -
a) 書物の字句の異同を考えて正すこと。
b) 校正刷りを原稿と引き合わせて、文字の誤りや不備を調べ正すこと。（校正刷り：校正
するために、仮に刷った印刷物。ゲラ刷り）
一方『新明解国語辞典』では、もう一歩踏み込んで、「原稿や原資料などとつき合わせ
て、文字や図版の誤りを正すこと。」としている。
JIS Z 8125『デジタル印刷用語』では、
校正：校正刷りを点検して、誤りや不備などに対して訂正・指示を加える作業。
【参考】校正刷りに記入された指示に従って、組版データを修正する作業（赤字修正）
も、校正と呼ばれている。
となっている。 同JISにおいては類似用語である「校閲」についても定義しており、
a) 著者の依頼・承認を受けた第三者が、原稿内容の誤り又は不備などを調べて正すこと。
b) 一通り校正の済んだ校正刷に目を通し、誤りの有無を吟味すること。
c) 新聞制作において、専門の部署によって行なわれる原稿内容の修正・訂正。
としており、これも広義の校正といえよう。
しかし現在では著者の意向に合致させるだけでなく、著者原稿そのものの不備の訂正、
表現の統一、図版の確認などを含めた、より広範なものとして位置づけられるようになっ
た。ゲラ刷りもレイアウト済みのコンテンツを使用することが多くなったが、これは校正
すべき対象が版面のすべてに及ぶからである。
(3) ｢校正」の定義拡張の要請
本研究対象である Web 利用を含むマルチモーダル環境での文書校正では、上記の定義範
囲ではうまく機能しない。たとえば冊子本と Web 配信用では文書の体裁だけでなく、構成
も変わる場合があり、後者ではハイパーリンクの設定、ユニバーサルデザインへの配慮な
ど、冊子本にはない属性が付与されることも多い。
さらに近年では、著述と、その発表の仕方自体が変わりつつある。たとえばブログでは
著者の原稿そのものが他人の手を経ずに公開対象とされるので、従来の校正の考え方は合
わなくなってきている。また Wiki のような Web 上での共同執筆・共同校閲のような仕組み
も従来型の校正では対応できない。こうした環境変化をも包含した校正のあり方を踏まえ
て、新しい校正機能を定義していかねばならない。
本稿では、要求仕様として、
・著者はすべてのステージで校正できること
・制作サイドでは、原則的には自分が扱うフォーマット上で校正できること
・編集者は、制作フォーマット及び最終の配布フォーマットの両方で校正できなければ
ならないこと
・分担執筆、共同執筆に対応すること
・分担校正・共同校正時の、校正権限の設定と管理機能が備わっていること
・校正履歴が保存できること
- 29 -
・Web 上で校正データが行き来できること
などを実現することを目指すものとし、その前提で考え方をまとめることとした。なお、
こうした定義での「校正」を対象とすることを明示するため、本調査研究では校正を意味
する Proofreading という用語を用い、従来型の校正と区別することとした。
3.2.3 電子書籍、電子辞書、オーディオブック、教材コンテンツの標準化
マルチモーダルウェブを活用するサービスが、電子書籍などにも影響を与えつつある。
特に米国で発売された「電子書籍」の専用リーダーはウェブと連携したサービスにより下
火となっていた市場に活気を与えている。また日本が世界をリードする「電子辞書」や、
米国主導の「オーディオブック」
、企業教育が先行していた「教材コンテンツ」が学校教育
などが、それぞれの垣根を越えて市場拡大のきっかけを得つつある。
ここでは、これら四分野について取り上げ標準化の動向を調査する。
3.2.3.1 電子書籍の標準化に関する動向調査
電子書籍及び電子辞書の市場動向については、3.2.2.2(a) 出版コンテンツで述べたと
おりである。ここでは主に電子書籍リーダーの市場動向を取り上げることにする。
米国においては 2003 年以降、全社撤退していた携帯型の電子書籍リーダーであるが、
2006 年 10 月の SONY Reader の投入で再び注目されつつあった。そこに Amazon.com が 2007
年 11 月 19 日に Kindle を発売し、
一時品切れが続く状態となった。
米国の電子書籍市場は、
有力な電子書籍リーダーの再登場で再びブームとなっている。米国市場で市場が活性化さ
れた要因を取り上げることで、電子書籍市場を検討することとする。
(1) 電子書籍専用リーダーの開発史
米国では 90 年代末からのドットコムバブルにのって、
日本より一足先に電子書籍リーダ
ーのブームを迎えていた。シリコンバレーのベンチャー企業が開発したロケット e ブック
やソフト・ブック、さらに両社を買収したジェムスターの活動が話題となった。しかし、
バブル景気を背景としたところもあってブームの潮が引く 2003 年に販売終了となった。
一方、日本では 8 センチ CD-ROM ドライブと液晶ディスプレイを組み合わせた電子ブック
（ソニー）が 1990 年に登場し、電子辞書に先駆けた市場を形成している。さらに 1993 年
に液晶ディスプレイによる電子書籍専用リーダー「デジタルブック」
（NEC）が発売されて
いる。しかし、PDA ブームの中で埋没してほとんど話題とならなかった。一般に注目され
るのは 1999 年からの電子書籍コンソーシアムによる電子書籍リーダーを用いた実証実験
である。これも多くの課題を残して実証実験は終了し、実用に至らなかった。
その後、ディスプレイ技術の進歩により、松下電器が見開き 2 枚のコリスティック液晶
を用いた Σ ブックを、ソニーが E-ink 社の電子ペーパーを用いたリブリエを 2003 年に発
表した。くしくも米国で液晶電子書籍リーダーの終焉を迎えた年である。しかし、Σ ブッ
クもリブリエも出版界では話題になったものの、実質的な販売台数においてアーリーアダ
- 30 -
プター市場（IT 商品の新しもの好き）を獲得することもなく販売中止となった。
なお、松下電器は Σ ブックの後継機、ワーズギアを 2006 年末に日本で発売した。5.6
インチのカラー液晶ディスプレイ 1 画面として、音声や動画にも対応している。コンテン
ツとしてカラー化したデジタルコミックや音楽データも扱えるようになった。電子書籍の
専用リーダーというより iPod の成功も意識したマルチメディア端末である。
この市場分野
は、モバイル PC やケータイ端末、シャープ W-ZERO3、さらに iPod まで含めると激戦区で
ある。
(2) SONY Reader（PRS500/505）
ソニーはリブリエの販売戦略を見直し、2006 年 10 月に米国でソニーリーダーとして発
売した。基本的な改良はユーザインタフェースと E-ink 社の電子ペーパーの機能向上であ
る。リブリエで採用された電子ペーパーは 4 階調であるが、ソニーリーダーでは 8 階調に
なっている。
ソニーリーダーは、リブリエからキーボードをなくしてシンプルなデザインとなってい
る。その結果、評判の悪かった検索機能や辞書がなくなっている。日本人は多機能製品を
好む傾向があるが、米国では新商品を投入するにはユーザに印象づけるためシンプルにし
て、商品コンセプトを明確する必要があるという。この「読むこと」に徹したことに加え、
オープン対応として PDF が読める点が評価されたという。ソニーの公式な発表によると 1
年間で 10 万台販売と健闘した。1 年後の 2007 年 10 月に 2 号機（PRS505）にバトンタッチ
している。
電子ペーパ搭載の電子書籍リーダーを利用した人の多くが、読みやすさに満足し、書換
速度が遅いことに不満を感じる。リブリエの検索機能が評判悪かったのは、CPU の処理速
度に問題があったのではなく表示が遅かったからである。そのためメニューの表示やカー
ソルの動きが悪く、利用していてイライラすることになる。ソニーリーダーでは検索機能
がないことに対する批判もあったが、現在のところ、機能を絞ることで成功したと思われ
る。
2 号機は書換速度の向上というより、インタフェースの変更に工夫がある。その一つが
右側に縦に並べたボタンである。メニュー画面を表示した際、従来であればカーソルがゆ
っくり下がるのを待つことになったが、この改良でメニュー横のボタンをダイレクトに押
して選択することができる。
1 回の充電で 7500 頁読書可能、内蔵メモリに 80 冊収納。価格は、いずれも約 300 ドル
（299.99 ドル）である。
ソニーリーダーのファイル形式は XML 形式の BBeB であるが、
PDF も採用した。
ただし PDF
は拡大縮小ができないので全画面表示のみである。米国に多いレターサイズの文書を 6 イ
ンチ画面で読むと、文字がかなり小さくなって読みにくい。これは技術的解決を検討して
いるという。
日本語文章は電子書籍化（BBeB）に人手がいるが、英語はかなり自動化ができる。コス
- 31 -
トは日本の製作費の十分の一である。日本の出版社はリブリエに対し書籍並みの組版品質
を要求したが、米国では、そのような要求はないという。
むしろカラー化については、ユーザよりも出版社から要求があるという。米国では電子
書籍の有望な市場として大学などの教科書がある。オールカラーで分厚い自然科学系教科
書を何冊も抱えることを考えると、電子書籍リーダーは魅力的と考えられる。
(3) Amazon Kindle
Amazon が電子書籍リーダーを準備していることが、2006 年にネットニュースでリーク
された。当初、2007 年 1 月発売予定とされたが、たびたび延長され、2007 年 11 月 19 日に
Kindle と製品名が発表され、同時に発売開始された。入力機能、検索機能、通信機能など
がサポートされている。通信機能は米国の携帯電話の電波サービス（EV-DO）を使い常時接
続している。
本体 399 ドル、電子書籍は 99 セントで、約 10 万タイトルが Amazon のサイトで販売され
ている。新聞は月額 5.99～14.99 ドル、雑誌は月額 1.25～3.45 ドルで購入できる。
電子書籍や雑誌は、すべて kindle の通信機能を使って Amazon のサイトから購入する。
また、ウィキペディアやブログを読むこともできる。通信費用は Amazon が負担するが、コ
ンテンツ購入費がかかる。
ディスプレイは E-ink 社製の 6.1 インチ電子ペーパで 8 階調（800×600）である。ソニ
ーリーダーと同等品である。Kindle では、画面の右横に液晶による縦に細い長いデジタル
バーがついている。これをスクロールホイールで上下に動かして使う。
ファイル形式は独自形式（.AZW）であるが、Amazon が 2005 年 4 月に傘下におさめた
Mobipocket が表示可能である。Mobipocket は 2000 年に開発された電子書籍ファイルであ
り、当初、Open eBook をベースとして PDA やスマートフォンに対応していた。PDF コンテ
ンツを表示することはできない。
(4) iRex 社
iLiad
iRex 社は 2005 年にフィリップスからスピンアウトした会社で、電子書籍リーダーであ
る iLiad（イリアッド）を 2 発売している。iLiad ではディスプレイに E-ink 社の 8.1 イン
チ電子ペーパを用い、独自技術で 16 階調（1024×768）を実現している。本体の重量は 390g
で、E-ink 電子ペーパ特有の遅い表示をタッチスクリーンによるアクセスにより回避して
いる。およそ 810 ドルである。PDF コンテンツを表示できる。
フランスの日刊経済紙レゼコーは創刊 100 周年にあたる 2008 年に厚さ 1mm の電子ペーパ
新聞を発行すると報道されたが（読売新聞 2006 年 10 月 24 日）
、前年の 2007 年に、iLiad
を用いて発売された。発売時の報道によると、読者は専用の携帯端末にインターネットの
無線 LAN によりコンテンツを取り込み、画面に表示して読む。レゼコーは毎朝 4 時配信し
経済・金融関連のニュースは 8 時から 21 時まで毎時間更新する。年末までに 2000 人の契
約を見込んでいた（日経産業新聞 2007 年 9 月 25 日）
。専用端末は２種類用意し、その一つ
が iLiad であり、もう一つが後述するガナクサ社製である。レゼコーの購読費用は、iLiad
- 32 -
とのセット販売が基本で 642.98 ユーロである。
（http://www.lesechos.fr/epaper/）
(5) ガナクサ社
レゼコーe リーダー
レゼコーブランドによる電子書籍リーダーで新聞購読とセットで 542.64 ユーロであ。デ
ィスプレイはソニーリーダーや Kindle に用いられているのと同じ 6.1 インチ、8 階調
（800×600）の E-ink 社製である。インターネット接続したパソコンから USB で端末へダ
ウンロードする。通信機能を持たない。
(6) 富士通フロンテック
FLEPia（フレッピア）
富士通研究所が開発したカラー電子ペーパを用いた電子書籍である。768 ドット×1、024
ドット（XGA）仕様の高精度、8 色または 4、096 色のカラー表示に対応できる、見やすい
表示画面です。大画面表示が可能な A4 タイプ（12 型パネル）と、持ち運びに便利な A5 タ
イプ（8 型パネル）の 2 種類を 2007 年よりサンプル出荷した。
(7) 米国における電子書籍のニーズ
米国における全出版物（書籍・雑誌・新聞）の年間総売上げは、およそ 250 億ドルであ
り、そのうち、コンシューマートレードブックス（注：日本のベストセラーなど単行本に
該当）が 80 億ドルである。この市場規模は、この 10 年変わらず、人口増を考えると米国
人の読書離れが指摘されている。
Amazon Kindle が登場するまでの米国電子書籍市場は 250 万ドル（出版市場の 0.3％）に
すぎず、アマゾンのモビポケット、パーム、PC、PDA の他、電子書籍専用機はソニーのみ
であった。
電子書籍の価格は、アマゾンが参入する以前は紙の本の 20～30%割引で、アマゾンはす
べて 99 セントである。
ソニーリーダー対応の電子書籍は発売開始時で 1 万タイトルだった。
当初の予定より遅れているが 1 年後 2 万タイトルまで増やしている。これに対し、Kindle
はスタート当初から約 9 万タイトルを準備している。ちなみに米国の郊外の大型書店で、
だいたい 20 万冊くらいの在庫である。
ソニーリーダーが売れた背景の一つとして、米国ソニーの担当者は、電子書籍のポータ
ビリティ（携帯性）をあげている。米国で流通する書籍の多くは大きくて厚いハードカバ
ーである。例えば『ダ・ヴィンチ・コード』の翻訳版は、文芸単行本に多い四六判上製で
上下 2 巻、文庫本化の際に上中下 3 巻で出版されている。これが米国では菊版を一回り大
きくしたサイズのハードカバーで 1 巻である。
この大きくて不便な本を米国人は、旅行やバケーションに 2、3 冊持って行く。そして読
み終えれば捨てて帰ってくる人も多い。一方、ソニーリーダーの重量は 9 オンス（255 グ
ラム）
、Kindle でも 10.3 オンス（292 グラム）と、ペーパーバック 1 冊よりも軽い。米国
人にとって書籍の携帯性が、長い間、潜在ニーズとなっていたといわれる理由である。
一方、米国出版業界の現状として、書籍返品コストによる経営圧迫があり、過去の出版
物の在庫増も負担となっている。そこに加えて、アマゾンやバーンズ&ノーブルなど大手書
- 33 -
店による書籍流通の寡占化が脅威となってきている。日本と異なり米国は大手の取次がな
く、版元と書店の直接取引が多い。このため卸正味が個別交渉となり、勢い多量部数を買
い付ける大手書店が優位となっている。
しかも米国では再販制度がないこともあり、書籍の価格決定権が書店に握られつつある。
そこで電子書籍ならば取次や書店を飛び越して、出版社と読者を直接結ぶことが期待され
るのである。
このような背景があって、日本と米国で出版社の対応が大きく異なっている。日本での
電子書籍は品切れの旧版が多かったが、米国出版社は積極的に新刊を提供している。ソニ
ーリーダーでは、ニューヨークタイムズのベストセラーリストの 7 割をカバーしている。
また参加出版社のうち大手 6 社で市場の 8 割を占有しているとのことである。
3.2.3.2
電子辞書の標準化に関する動向調査
(1) 標準化の必要性
電子辞書市場は、専用機分野がほぼ飽和状態となり、最近ではウェブを利用した検索サ
ービスに移行している。また、ウィキペディアなどのようなフリー百科事典などが人気と
なっているが、信頼性の保証については議論のあるところである。それだけに良質な辞書
コンテンツの電子化やウェブ利用を推進していく必要がある。
辞書出版社は、辞書ごとに異なるフォーマットを持ち、一方、電子辞書メーカーは開発
費の点から、
いったん作成した電子辞書コンテンツの再利用になりがちである。
この結果、
コンテンツは書籍に人気のあった辞書で占有された状態のままである。このような紙の辞
書が持っていた多様性が電子辞書になることで失われつつある問題については、一般紙な
どでも取り上げられるようになった（読売新聞 2008 年 1 月 9 日付）
。
そこで、リエゾンを取っている IEC/TC100 の TA10 でもこの問題を取り上げて検討してき
た。以下、標準化提案のための議論を元にまとめておく。
(2) 標準化する部分
ここでの標準化については、出版社と電子辞書メーカとの円滑なデータの受け渡しのた
めのデータフォーマットについて規定する。具体的には、以下の部分について規定を設け
る。
a) 検索情報を与える部分（index）必須
b) 本文情報を与える部分（card）必須
c) 見出し語の並び情報を与える部分（order）必須
d) その他管理情報（書籍名、著者名、凡例 等）オプション
- 34 -
card 1 の検索情報
card n
card 2 の検索情報
card 3 の検索情報
・
card 3
・
card 2
・
card 1
card n の検索情報
index
card 1
card 2
その他管理情報
card 3
・
・
・
card n
order（複数あってよい）
(3) 標準化すべき内容
以下、それぞれにおける標準化すべき項目を列挙する。
a) 検索情報を与える部分（index）
・コード体系
・本文情報とのリンク方法
・複数の検索キー、コード体系がある場合の記述方法
・見出しの中に含まれる例文や成句、サブ見出しの検索の記述方法
・ノーマライゼーション、異体字の取扱方法
b) 本文情報を与える部分（card）
・コード体系
・外字の考え方
・本文の記述方法
文字色背景色、ボールド、イタリック、アンダーライン、ルビ、インデント、禁則情
報見出し部、意味部 等の分類方法
・他の見出しへのリンク方法
・他のオブジェクト（音、静止画、動画、図表 等）の埋め込み方法及びリンク方法
- 35 -
・各見出しの ID の付与方法
・サブ見出しの扱い方
・個々の辞書固有の情報の取扱方法
c) 見出し語の並び情報を与える部分（order）
・並び情報の指定方法（本文情報へのリンク方法）
・複数必要か、また、必要な場合の記述方法
・サブ見出しの扱い方
d) その他管理情報（書籍名、著者名、凡例 等）
・凡例や巻末付録 等の記述方法
・書籍名、著者名 等の記述方法
3.2.3.3
オーディオブックの標準化に関する動向調査
朗読などの録音物を総称してオーディオブックと呼び、音源（カセットや CD）が単体で
販売されているものを指していう。日本ではカセットブック、カセット文庫、CD ブックと
いう名で 1980 年代に朗読や講演などの録音物が流行した。作家自らの自作朗読や、俳優に
よる朗読、著名人の講演、落語などのライブ録音が多数カセットブック化された。またラ
ジオドラマに加え、小説や漫画を原作にドラマ化した作品も登場した。現在ではドラマ CD
と呼ばれて販売が続いている。さらに視覚障害者のためにボランティアが活字書籍を朗読
した録音図書もある。なお、英語や英会話の書籍では音源の CD が付いた本が多いが、これ
らはオーディオブックと分けてとらえられている。
また、テキストと音源を組み合わせた電子知育玩具や英語学習機器が販売されている。
電子書籍リーダーにオーディオブックを組み合わせたルーツととらえることができる。ソ
ニー「トーキングカード」や「Speak&Spell」などがそれにあたる。後者は文字と音がリン
クしていた初期の知育トイで、1970 年代後半に米国で幼児が単語の綴りを覚えるために開
発された商品である。現在でも「マジックトーカーズ（AZ マスター）
」
、「チャティパロッ
ト」
、
「エニートーカーズ」など、いくつかの英語学習専用機がある。
さらにカーナビゲーションシステムが普及し、音声認識技術の取り込みによりマルチモ
ーダルな端末として注目されつつある。そこで、音声認識カーナビゲーションの現状機能
を調査し、普及のための課題を検討した。
(1) 米国におけるオーディオブック市場
オーディオブックの 2006 年の売上げは 9 億 2300 万ドルで前年比 6％増であった。オー
ディオ出版協会の調査によると、ＣＤの売上げが 77％（前年 74％）に対して、ダウンロー
ド形式は 14％（前年 9％）であり、新媒体での売上げが伸びているとのことである。アメ
リカではポッドキャストで自分の著作物を音声で配信し、iPod 小説で人気を得た作家が、
紙媒体 で書籍を発行するとい ったことも新たな出版 の流れとして注目され ている 。
（Publishers Weekly
Sep/3/2007 翻訳出典：書協「出版広報」2007 年 10 月号）
- 36 -
オーディオブック　流通経路
オーディオブック　媒体構成比
ＭＰ３－ＣＤ
1%
カタログ
1%
オンライン
ダウンロー
2%
ド
10%
カセット
7%
その他
10%
ダウンロード
14%
図書館
32%
取次
15%
その他
1%
ＣＤ
77%
小売
30%
(2) 日本におけるオーディオブック市場
前述のように欧米では自動車通勤者が車内で聴くためのオーディオブックが普及してい
るが、日本の市場は欧米に比較して小さい。ただ、2005 年 8 月に日本上陸した iTunes Music
Store にはオーディオブックのコーナーがあり、日本独自のコンテンツとして落語、怪談
がある。また、アマゾンなどでもオーディオブックが扱われるなど、インターネットの普
及でダウンロード販売が伸びている。
日本におけるオーディオブックの販売サイトとして、
「iTunes Music Store」のほか、
「こ
とのは出版」
、
「フィービー」
、
「ラジオデイズ」などがある。
(3) 将来型オーディオブックへの拡張と標準化検討
オーディオブックでは、先頭から順に音を聞いていくだけではなく、利用者が希望する
任意の箇所の音声を再生できることが望ましい。特に言語音の場合は、対応する文字表現
が存在することが想定されるため、再生箇所の指定方法としては、表示されるテキストの
ここからといった方法が考えられる。マルチモーダルという観点からも、音声データとテ
キストデータが同期して再生されたり、一方である箇所を指定すると追随して他方でも同
じ箇所が再生されたりすることは、複数のモダリティの同期という点で意味がある。
ここで、音声とテキストを同期させる方法が問題となるが、テキストデータが存在する
場合に、TTS (Text To Speech) を用いて自動的に音声データを作成する方法は、現状では
再生される音声の品質や制御の点で、使用できる場面が限られる。よって、ここでは予め
録音された音声データとテキストデータを同期させる方法について述べる。
最も単純な方法は、録音単位で、テキストとの対応を取るという方法である。最もわか
りやすい例としては、録音単位毎にファイルを分割し、各ファイルとテキストのリンクを
とる方法がある。この場合、再生箇所の指定は、原則として録音単位の先頭に制限される。
また、録音単位をあまり短くすると、ファイル数が増大するとともに、連続再生する際の
- 37 -
単位間のつなぎの部分の問題が発生する。
このため、録音単位よりも細かな指定ができることが必要となる。原則として、テキス
トデータには文字単位で任意のタグ付けが可能であるため、これは、音声データの任意箇
所をどのように指定するかという問題となる。これに対して、音声データは時系列である
ため、録音された際の時刻情報ないし経過時間情報が一般に用いられる。
たとえば、カラオケでは、再生される楽曲と同期して歌詞のテキストデータを表示する
が、歌詞を構成する各文字毎に楽曲の先頭からの経過時間情報を持たせれば、経過時間を
もとにして、歌詞の現在再生しているであろう箇所を特定できる。たとえ、再生速度を録
音時と変えたとしても、一定であれば計算により求めることができる。
また、主に視覚障害者向けの録音図書のための DAISY (Digital Accessible Information
System) では、HTML と SMIL を用いている。SMIL で音声データの区間と、対応する HTML
のテキスト箇所との対応を記述することにより、再生される音声に同期したテキスト表示、
また逆に表示された箇所の再生を行えるようにしている。たとえば以下のような記述であ
る。
<par endsync="last">
<text src="sample.html#xmmg_0001" id="xmmg_0001" />
<seq>
<audio
src="sample.mp3"
clip-begin="npt=2.828s"
clip-end="npt=6.496s"
id="qwrt_0002" />
</seq>
</par>
このように時間情報を手がかりに同期をとる方式では、何らかの理由で遅延が発生した
り、再生速度が安定しないような場合にずれが発生することが考えられるので、ファイル
単位の同期との併用が望ましい。また、朗読のように、最初から最後までが単一の時間軸
に収まる場合は、
単一の経過時間の記述ですむが、
インタラクティブなコンテンツなどで、
再生する内容が変わるような場合にも、異なる音声区間の指定が必要になる。このような
複数コンテンツを同一トラック（ファイル）の異なる時間区間に格納するか、異なるトラ
ックに格納するかは管理の問題である。ただし、前者の場合は、そのトラックを先頭から
単純に再生することはできなくなる。
次に、このような同期情報の作成方法について述べる。最も原始的な方法としては、音
声データとテキストデータを別々に用意しておき、音声データを再生しながら、それを聞
き取って、人手で時間情報を付与していくという方法がある。再生開始後、マウスをクリ
ックしたタイミングで時間情報を書き出すツールも存在する。
自動的に行う場合は、音声認識技術を用いる。テキストから発声が予想される音素列を
構成することで、一般にセグメンテーションと呼ばれる手法を用いて、音声データと音素
列とのアラインメントをとる。実際には、音素毎のアラインメントでは細かすぎてうまく
- 38 -
いかないことが多いため、音素を単語程度にまとめあげて、単語とのアラインメントをと
る。作業手順は概ね以下のようになる。
a) テキストを形態素解析し、単語列にわける。
b) 各単語の読みを確定する。
c) 読みから音素列を得る。
d) 音声認識エンジン（セグメンテーションツール）を用いて、音声データに対して単語
単位のアラインメントをとる。
e) アラインメント結果から、各単語の発声の開始・終了時間を得る。
なお、
このようにして得られる情報はあくまで、
文字列と音声との対応関係のみである。
実際には、同じ文字列であっても、文脈によって発声の仕方が異なることが考えられる。
また、イントネーションの違いといった情報も表現できない。これらの字面には現れない
パラ言語的な情報も必要に応じてタグ付けすることが求められる。
(4) 音声認識カーナビゲーションの機能と課題
カーナビゲーション（以下、カーナビ）は、目的地まで安全・快適に導くアイテムとし
て車内装備の必需品となっている。運転中は安全のために操作が行えないようになってい
るが、高級機を中心に音声操作が可能な機種が増えてきており、運転中でも操作が可能で
ある。また、カーナビの操作だけではなく、オーディオやエアコンなどの操作も音声で行
えるようになっている。
a) 音声による操作（基本操作）
音声による操作は、発話スイッチを押して、音声コマンドを話して操作を行う。音声を正
しく認識させるために、いくつかの注意点がある。
＜音声操作の注意点＞
－
ナビの認識可能な言葉（音声コマンド）で話す。
－
音声コマンドのみをはっきりと話す、
－
車外の音などを遮断するために、窓を閉める。
－
住所の番号を発話するときには、"番地"や"号"などは発話しない
－
数字の読み方は以下のように読む
ゼロ、イチ、ニ、ニー、サン、ヨン、ゴ、ゴー、ロク、ナナ、ハチ、キュー、ジュウ
b) 声の登録
音声認識の認識率を上げるためにシステムに声データを覚えさせることができる。声の
登録は、指示された単語の発話で認識させる。調査したカーナビでは、５人分の登録が可
能であった。
c) 音声操作による目的地の検索方法
目的地を探してルート案内を行うために、音声で行きたい場所を発話し、目的地の地図
を表示して目的地設定を行う。
＜音声での検索の方法＞
- 39 -
－ 施設の名前で場所を探す場合
「長野県の志賀高原スキー場」などのように発話する
－ 近くの施設を探す場合
「近くのコンビニ」などのように発話する。
－
ルート沿いの施設を探す場合
「この先のガソリンスタンド」などのように発話する。
－
電話番号で場所を探して案内させる
「電話番号から探す」と発話し、電話番号からの検索モードになったら、
「市街局番＋
市内局番」を発話し、認識されたら「残りの番号」を発話する。目的地にする場合は
「ここに行く」
、経由地にする場合は「ここに立ち寄る」
、マークを登録する場合は、
「マークセット」と発話する。
－
郵便番号で場所を探して案内させる
「郵便番号から探す」と発話し、郵便番号からの検索モードになったら、
「はじめの３
桁」を発話し、
「残りの４桁」を発話する。
－
住所で場所を探して案内させる。
「都道府県名＋市区町村名＋地名（丁目）
」を発話し、
「詳細住所の番地」を発話する。
検索された施設を選択し、地図を表示し、
「ここに行く」
、
「ここに立ち寄る」などのよ
うに発話し、目的地または経由地としてセットする。
d) 音声コマンドの例
操作別の主な音声コマンドは以下のとおりである。
操作
基本操作
図面表示
目的地を探す
操作内容
音声コマンド
現在地を表示する
現在地
ルート案内を聞く
音声案内
ルート案内の音量を OFF にする
音声音量オフ
広域の地図を見る
広域、縮小
詳細な地図を見る
詳細、拡大
北を上に表示する
北を上に表示
進行方向を上に表示
進行方向を上に表示
高速ガイド表示にする
高速ガイド
２画面表示にする
２画面表示
電話番号で検索する
電話番号から探す
郵便番号で検索する
郵便番号から探す
近くの施設を探す
近くの○○○○
ルート沿いの施設を探す
この先の○○○○
- 40 -
操作
目的地に行く
操作内容
音声コマンド
目的地周辺の施設を探す
目的地周辺の○○○○
自宅を目的地にする
自宅へ誘導、うちに帰る
地図表示された場所を目的地にする
ここに行く、目的地セット
地図表示された場所を経由地にする
ここに立ち寄る、経由地セット
地図表示された場所を経由地にして自
ここに寄って帰る
宅に帰る
ルート案内
ランドマーク
ルートを再計算する
ルート再計算
全ルートを表示する
全ルートを見る
次の経由地を表示する
経由地表示
ルート案内を中止して再開させる
案内中止
迂回ルートを再計算して案内させる
迂回５キロメートル
到着予想時間を確認する
到着予想時間
残りの距離を確認する
残りの距離
案内音の音量を設定する
音声音量
高速道推奨ルートで案内する
高速道推奨
一般道推奨ルートで案内する
一般道推奨
高速道距離優先ルートで案内する
高速道距離優先
一般道距離優先ルートで案内する
一般道距離優先
ガソリンスタンドを表示する／しない
ガソリンスタンド
コンビニを表示する／しない
コンビニ
ファミリーレストランを表示する／し
ファミリーレストラン
案内開始
ない
ナビの設定
駐車場を表示する／しない
駐車場
市街地図を表示する／しない
市街地図表示
現在地情報を表示する／しない
現在地情報の表示
時計を表示する／しない
時計表示
渋滞考慮オートリルートをする／しな
渋滞考慮オートリルート
い
到着予想時間を表示する／しない
到着予想時間表示
ルート計算条件を変更する
ルート計算条件
ふらつき検知警報をする／しない
ふらつき検知警報
合流・県境案内をする／しない
合流・県境案内
踏み切り案内をする／しない
踏み切り案内
右左折専用レーン案内をする／しない
右左折専用レーン案内
- 41 -
操作
ハンズフリー
便利な機能
オーディオ
エアコン
操作内容
音声コマンド
ハンズフリー電話モードにする
電話をかける
自宅を呼び出す
自宅
目的地を呼び出す
目的地
経由地を呼び出す
経由地
給油情報を表示する
給油
音声メモを利用する
音声メモ
音声メモを録音する
音声メモ録音
音声メモを読み上げる
音声メモ読み上げ
オーディオの電源を入れる
オーディオ、オーディオ オン
オーディオの電源を切る
オーディオ オフ
ラジオを受信する
ラジオ
ＣＤを聞く
シーディー
次の曲を再生する
次のキョク
エアコンを入れる
エアコンオン
エアコンをきる
エアコンオフ
内気循環にする
内気
外気導入にする
外気
設定温度を１度下げる
あつい、温度下げる
設定温度を１度上げる
さむい、温度上げる
e) 音声により検索可能な施設
－ 目的地検索
音声による目的地検索は、都道府県名の後に施設名を話すことにより検索することが
できる。発話指定可能な施設は、
「駅、道の駅、空港、サービスエリア、パーキングエリ
ア、文化施設、レジャー施設、宿泊施設、スポーツ施設」などである。
－ 周辺検索
音声による周辺検索は、周辺検索コマンドの後に施設名を発話することにより、検索
することができる、指定可能な施設は、
「駅、道の駅、警察署、消防署、医院、眼科、歯
科、総合病院、保育園、幼稚園、小学校、中学校、高校、大学、トイレ、銀行、ガソリ
ンスタンド、駐車場、うどん・そば店、カレー店、ファーストフード、ファミリーレス
トラン、ラーメン店、図書館、博物館」などである。
周辺検索コマンドは、
「近くの○○○」
、
「この先の○○○」
、
「目的地周辺の○○○」で
あり、
「近くのカレー店」のように発話することで検索が行える。
f) 課題
- 42 -
カーナビの音声認識には、①目的地の検索が目的地を発話するだけで行える、②運転中
でも画面を見なくても操作が行える、③目的地検索に絞れば覚える音声コマンドも少なく、
操作習得も容易である、などのメリットがあるが、カーナビの音声操作はあまり普及して
いるとはいえない。現在の音声操作には、以下のような問題点がある。
・声の登録など、音声操作を確実に行えるようにするための準備が必要で、敷居が高い
と感じる。
・音声の認識率があまり高くないため、ご認識や認識しない場合がある。
・音声による操作を行う際のレスポンスがあまりよくない。
・周囲の雑音や同乗者の会話などの影響により、正しく認識できない場合がある。
・一部の音声コマンドはすぐに覚えられるが、多くの機能を利用しようとすると、音声
コマンドを覚えきれない。
ハンズフリーが要求されるカーナビにおいて、音声による操作は実用化が期待されてい
る技術である。
現時点では上記のような問題点により利用している人は少ないと思われる。
今後、音声認識の精度とレスポンスを高めることで、もっと気軽に誰でも利用できるよう
に進歩してほしい技術である。
3.2.3.4 教材コンテンツの標準化に関する動向調査
近年インターネットの普及により、インターネットを使ったデジタルコンテンツの配信
が盛んになってきている。
日本では 2005 年頃から iTunes Music Store や GyaO が開始され、
これらのコンテンツ配信サービスが、既存のコンテンツビジネスに大きな影響を与えてい
る。一方、学校におけるネットワーク整備も、e-Japan 戦略の一環として、2005 年を目処
に行われてきた。本項では、学校におけるデジタルコンテンツ、教材コンテンツについて
の概況を紹介する。
(1) 学校のネットワーク環境
日本には小中高、中等教育学校、盲・聾・養護学校あわせて約 3 万 8 千の学校があるが、
現在、これらの学校でのブロードバンド普及率は 89.1%である。しかし、PC 教室はネット
ワーク化されているものの、普通教室のネットワーク化はされていないことが多い。校内
イントラの普及は 5 割程度である。
（1）
つまり、普通教室で行われる授業でのインターネット活用を想定する場合、まだインフ
ラが十分に整ってはいない。また、もっとも大きな課題は、利用者である教師の IT リテラ
シーが低い、ということにある。
(2) 教材コンテンツの実例
教材コンテンツには、大きく分けて、個別学習型教材、提示型教材、ドリル型教材があ
る。個別学習型教材は、生徒が自学自習するための教材であり、自分のペースで学習でき
1
文部科学省「学校における教育の情報化の実態等に関する調査結果」
- 43 -
るようになっている。また、グループ学習で使ったりすることもある。提示型教材は、教
師が授業を行う際に利用する教材であり、資料、映像やデジタル教科書がこれにあたる。
ドリル型教材は、いわゆるドリルとして使用し、PDF 化された練習問題をダウンロードし
て利用する。
タイプ
用途
個別学習型教材
自学自習、グループ学習
提示型教材
授業での資料提示
画像、映像、デジタル教科書など
ドリル型教材
ドリル
実際に利用される教材コンテンツは、提示型教材が多い。これは、教師が授業での使い
方を想定しやすいためと考えられる。一方、デジタルコンテンツだけで授業をするのは困
難という声もある。そのために提示型教材の利用が多くなっている、という側面もあるの
ではないか。
教材コンテンツは、その入手方法として、インターネット上で公開されているコンテン
ツと、有料で購入するコンテンツがある。また、文部科学省の委託事業で開発されたコン
テンツ（http://www.mext.go.jp/a_menu/shotou/zyouhou/020705.htm）もある。
インターネット上で公開されているコンテンツとしては、例えば NHK デジタル教材(2)
がある。これは NHK で TV 放送された教育番組を映像コンテンツとして見ることができる。
教材の内容を Web ページで確認でき、また、NHK で TV 放送された教育番組が細かく分割さ
れた動画になっており、必要な部分だけを再生できるようになっている。また、例えば国
立天文台で公開されている画像・映像(3)のように、学術機関が公開しているデジタルコン
テンツを提示型教材として利用することもある。
有料で購入する教材コンテンツには、Web ブラウザで利用するものと、ビューワとコン
テンツが一体化した PC ソフトとなっているものがある。前者は Flash のような RIA で提供
されることが多い。後者の例は、専用のビューワーソフトに、読み上げ機能、マーカー機
能などが実装された、デジタル教科書などがある。
概況として、教材コンテンツは、量としては揃いつつある。一方で、先に挙げたように
利用者である教師の IT リテラシーによって、実際に利用されるかどうかが左右される。
(3) 教材コンテンツのビジネスモデル
教材コンテンツを販売する場合には、インターネットを利用したコンテンツ配信として
提供する形態と、PC ソフトとして販売される形態、に大別できる。
2
3
http://www.nhk.or.jp/school/program/index.html
http://www.nao.ac.jp/Gallery/index.html
- 44 -
コンテンツ配信の課金対象は、コンテンツ配信システムの設置・初期契約、利用料、個々
のコンテンツ購入、などが挙げられる。しかし、教材コンテンツの購入は、各学校／教育
委員会でのソフトウェア予算枠の範囲で行われるため、学校内で必要なコンテンツを集計
しておき、一括購入するという購入形態になることが多い。また、ソフトウェアの予算措
置も、1 学校あたりの購入金額が、なしが約 10%、10 万円未満が約 30％、10 万円～50 万円
未満が約 30％、という状況である（4）
。このような学校でのコンテンツ購入についての事
情は、一般のコンテンツ配信ビジネスとは趣が異なるといえる。
コンテンツ配信では、教材コンテンツは、学年・科目・単元によってカテゴライズされ
る。各コンテンツは数千～数万円で購入・ダウンロードできる。教材コンテンツ配信では、
ゲーム感覚で学習できる（動きがあるもの、コンテンツを操作するもの）コンテンツ、複
数の科目が含まれているコンテンツ、に人気が集まったという例がある。
(4) 教材コンテンツの標準化について
教材コンテンツのメタ情報を扱う規格として、LOM（Learning Object Metadata／IEEE
1484.12.1）が定義されている。また、その教材コンテンツがどの学年・科目・単元で利用
できるのかをメタ情報として記述しておきたい、というコンテンツ提供者の声もある。し
かし、LOM はあまり普及していないのが実情である。
教材コンテンツは、テキスト・画像・映像といったベーシックなものと、PC ソフト・Flash
などのアプリケーションとがある。また、学校現場においては、教材コンテンツは、どの
ような OS でも再生・動作することが求められる。そのため、インタラクティブ・高機能な
教材コンテンツもブラウザで動作するものが多い。
教材コンテンツの標準化においては、これらの要求を整理検討し、実情に合った要件定
義を行うことが必要と考えられる。
【参考文献】
－ JAPET（日本教育工学振興会）
「2007 年度版 先生と行政のための ICT 教育環境整備ハ
ンドブック」
－ 文部科学省「学校における教育の情報化の実態等に関する調査結果」
http://www.mext.go.jp/b_menu/houdou/17/08/05080101.htm
3.3 成果のまとめ
3.3.1 次世代 Web のサービスに関する調査研究成果
3.3.1.1 次世代 Web のサービスのためのアーキテクチャ
W3C には、Web へのユニバーサルデザインの導入を目的としたマルチモーダルインタラ
クション（MMI）関連のグループがマルチモーダルウェブを目指した標準化活動を推進して
いる。2007 年 11 月に慶応大学でこのグループによるワークショップが開催され、WG1 で議
4
平成１７年（社）日本教育工学振興会調べ
- 45 -
論された内容の一部を寄書（ポジションペーパー）として提出した。
3.3.1.2 空間情報サービス
PND を活用する空間情報サービスの市場を広げるためには、協調領域の構築が重要であ
る。その基盤となる地図情報の相互運用のための標準化グループとして SVG Map コンソー
シアムが設立された。そのモデル・アーキテクチャは、当 WG での検討結果が活用されてお
り、そのアーキテクチャに基づき、"SVG Map Toolkit"が開発されている。
同コンソーシアムはまた、本 WG で得られた知見も参考にして、ｇコンテンツ流通推進協
議会（経済産業省関連組織 JIPDEC が事務局）において、LBCS/SVG 委員会に協力し、空間
情報サービスプラットホームとしての SVG の 2009 年度 JIS 化を目指して働きかけている。
3.3.1.3
PIM 関連情報とその応用
PIM オントロジに関しては、UML のクラス図による基本モデルとネットワークやアプリ
ケーションとの関係を記述した階層モデルを検討し、
その基本概念を IEC/TC100 の AGS に、
NP 提案をしている。PIM オントロジをネットワーク上に実装するためのアーキテクチャ、
ネットワーク上の実装環境としての SNS、利用者に付随するデータモデルなどについては、
新たな NP 提案を検討している。
3.3.1.4 ネットワークの自動設定
ネットワーク設定の自動化に関し、標準化及び関連動向の調査検討の結果、ネットワ
ークの持つ機能とアプリケーションや他の機器の持つ機能とを連携させるために、標準化
を検討する必要があることが合意された。現在そのためのデータモデル、モデルへの API
などについて、3.3.1.3 項と同様、IEC/TC100 へ NP 提案を行うための準備を行っている。
3.3.2 コンテンツ生成・流通・管理の概念モデルに基づく交換フォーマットの標準化成果
3.3.2.1 ディスプレイフォントの開発成果
(1) ディスプレイフォントに求められる要素
フォントの実証実験から、
・細いウエイト（L）は横画と縦画の太さ比が小さいほうが判別性が高い
・太いウエイト（B）では逆がよいという
という評価結果を得られた。
通常、印刷用の明朝書体ではウエイトの違いによって横画は共通の太さで固定して、縦
画や斜画や点画のウエイトを太めることで、同一の書風を保ちながらウエイトバリエーシ
ョンを形成している。そういった意味で、今回の実験結果は従来の印刷用明朝体にはあま
り無かったものである。
(2) ディスプレイフォント開発の今後
今後とも、社会生活の中で絶えず情報の利用シーンが変革していく。そこではデバイス
やコンテンツの特性、ユーザー特性などに連れて文字に求められる要素も変わってくる。
そこでは、
「どこでも（場所に応じてどんな媒体でも）
」
、
「誰でも（高齢者、幼児などへも）
」
、
- 46 -
利用環境、利用シーンに適合した「書体」の提供が求められていくことになる。
従って、従来の電子媒体に見られがちだった、単に読めればよいということでなく、コ
ンテンツの表示要素の重要な一つとして、文字が情報流通の基盤としての存在価値を高め
ていくため努力が必要だと想う。
そのためには、文字を開発する際のデザイン設計書と、個々の文字における細部のチュ
ーニングの考え方を記録として残し、それら知見を明文化して継承することが重要になる。
併せて、制作手法に関しても文字のパーツを部品化して文字としての品質を高めつつ、制
作プロセスの中での流用性を高めるような試みが必要になってくる。
さらには、フォント関連に知見のある人と、デバイスメーカー、コンテンツホルダー、
ソフトウェア開発者や学術研究者とが協力して実装レベルでの研究・評価を積極的に推進
していくべきと考える。
3.3.2.2
Proofreading のためのメタデータ（案）
Proofreading の定義に基づき RDF でラッピングすることを前提に、Dublin Core 拡張と
しての Proofreading のためのメタデータ（案）をまとめた。ポイントは定義に基づき、時
系列管理、分散 Proofreading、権限設定による階層化、査読への適用などを考慮したこと
である。なお、以下の分類は便宜上のものである（微妙なニュアンスの違いがあるため、
日本語表記とする）
。
(1) 人に関する語彙
各語彙に複数存在し得る。個々にプライオリティを付す仕組みを付ける。
a) 著者
編者を含む（基本語彙の“Creator”とは区別する。実際の文書を書き、または編纂など
を行い、文書内容の変更権を持つ者。翻訳者を含む。ただし監修者が存在する場合の関係
は別途規定する必要あり。装丁者、挿画者の扱いについても要検討）
b) 監修者
文書作成には関与していないが、文書内容の変更に対して一定の権限を有する者。
c) 編集者
出版を前提としたとき、当該出版物に対する編集権を持つ者。発行者ではない。メディ
アごとに編集賢者が異なる場合もあるため、その区別のための副語彙も必要。
d) 校正者
実際に校正を行う者。同一文書に対して一人の校正者が校正を行う場合、複数の校正者
が関与する場合に区分できる。さらに複数校正者が作業する場合においても、分担制をと
る場合と階層的に行う場合に分けられ、かつ最終決定権者が校正者、編集者、著者、監修
者等、その都度恣意的に決められることに配慮する必要がある。
e) 査読者
学会論文などの評価者を想定。具体的に文書に手を入れることはしないが、コメントを
- 47 -
付すことができる者。
(2) 作業に関する語彙
ここでは文字校正を対象とする（狭義の校正）
。したがって、配置、色彩等に関する校正
は別途扱うものとする（
【注】この限定は、本案の中だけに適用するものである）
。したが
って、校正機能としては文字列に対する追加、削除、置換、復元、コメント付加の４種類
になる。しかし置換は削除→追加、という手順で実現できるから、追加、削除、復元、コ
メント付加の３種類としてもよい。逆に、置換のみを定め、その中に追加・削除の機能を
包含する考え方も成り立つ。ここでは便宜的に前者の機能を採用する（直感的にわかりや
すい）
。
この語彙を付与すべき実体については、ここでは定めない。
a) 追加
指定位置に対して文字列を追加（挿入）する。追加文字列の量は規定しない。複数の章
を包含する文字列（文書）でもよい。
b) 削除
選択範囲の文字列を削除する。
c) 置換
選択範囲の文字列を置換する。置換される文字列と置換後の文字列の量的な差は問わな
い。
「削除」と「追加」によって置換を実現してもよい。また、
「置換」を利用して追加・
削除を実現してもよい。
d) 復元
校正用語に言う「イキ」を意味する。いったん追加・削除・置換等の修正を行った箇所
を前の状態に戻す機能である。同一箇所の文字列に対する校正が重畳的に行われた結果に
対する「イキ」がどこまで遡るかは、次項の語彙を併用して指定することになる。
e) コメント付加
これは機能として２種類に分類される。
文章に手を入れる（すなわち校正作業）ことはせず、採用の適否（評価）
、感想等を述べる
機能語彙である。対象範囲は、ひとつの段落から文書全体に至る適当とする範囲を指定で
きるものとする。
従来の校正においても、著者原稿そのものに疑義があるものについては、だまって赤を
入れてしまうのではなく、青ペンなどで（遠慮がちに）直して“？”などを入れるという
のがエチケットであるが、これも一種のコメントである。
もうひとつは、本来は「置換」したいところであるがその表現手段を持たないときにコ
メントとして記述するものである。新聞記事データ集配信における「字解」に似たもので
ある。たとえば「鄧小平」の「鄧」が内字になかったとき、“〓１＝登にオオザト”とい
った表現によって特定の文字を伝達した。この種の機能語彙である。
(3) 付加情報用語彙
- 48 -
校正作業は時空間に広がった作業である。すなわち時系列に、初校、再校、三校、…と
続く。最後は「責了」としてクローズする。その「本道」とは別に、組版側での「内校」
がある。さらに、同時並行で校正作業が行われることが多い。複数の校正者による分担校
正である。こうした広がりでの作業に対して、一種のワークフロー管理が求められる。こ
こでは、それらの代表的な必要語彙を抽出しておく。
a) タイムスタンプ
校正を行った時間（年月日時分秒）
。これは２項の属性になる。
b) 権限種別
複数の校正者が階層的に作業する場合の権限順位で、これは１項の属性になる。
この場合、権限上位者は下位者の構成結果をさらに改訂したり元に戻す（イキ）権限を
持つ。逆に言えば、“2-4 復元”は当該箇所の校正当事者か上位者に限られた機能に限定
される。このモデルでは最終決定権者は一人として考える。
c) 公開
構成された文書の公開・配布条件を規定する。
d) 表示
校正後の文書をどのように表示するかを規定する。校正作業が四校、五校と進んでいっ
たとき、どこまでを表示するかを選択できるようにするのが目的である。校正前後の文書
を並べて表示する機能もここで規定する。削除内容を「見え消し」にするかどうか、修正
箇所の色分け表示等についても、この属性を使用する。
最終的な組み上がり文書としての表示の可能性については別途検討するものとする。
e) 版管理
版管理の仕方を規定する。途中履歴をいつまで保存するかなどの情報も、この語彙属性
で規定する。
f) その他
以上の語彙以外で必要なもの（本項は検討が十分でないために仮に置いたものである）
(4) Proofreading ML の検討と今後の課題
著述から公開までの全ステージで、
統一的な思想の元に Proofreading が可能にならなけ
ればならない。そのための汎用的な言語、Proofreading ML を検討した。
編集・制作サイドで使用する Generic Format は XML ベースのフォーマットを想定してい
るため、ここで試案としてまとめた Proofreading ML のためのメタデータは文書フォーマ
ットとの親和性もよく、とくに問題は生じない。
しかし著述者が文書を 作成するために用いる ツールのフォーマット （Submission
Format）は一意に決定できない。理想的には「なんでもよい」フォーマットでありたい。
このような不特定多数のフォーマットに対して機能する言語を規定することは非常に困難
と考えられる。現実的な解をどこに求めるのかについて今後の検討を待たねばならない。
Reader’s Format 上での Proofreading にも同様の問題があり、Proofreading ML を有効に
- 49 -
用いる e-Book の総合的なモデルを早急に構築することが求められていると言えよう。
3.3.3
電子書籍、電子辞書、オーディオブック、教材コンテンツの標準化成果
WG1 での標準化検討内容は、JEITA を経由して IEC/TC100 の eBook 関連 TA10 に提案し、
国際標準化への寄与を行っている。
この寄与に関連する 2007 年度における IEC/TC100 TA10
の eBook 関連プロジェクトとして、電子書籍、電子辞書、オーディオブックの動向を次に
示す。
IEC/TC100 は、オーディオ、ビデオ、マルチメディアシステム及び機器の技術分野に関
連する国際標準化を行っており、民生用分野・業務用分野の機器の性能、測定方法及びマ
ルチメディアシステムの応用、システムと機器間のインターオペラビリティ（相互運用性）
などの規格化を推進している。TC100 は、他の TC における SC（Sub committee）に相当す
る組織である TA（Technical Area）からなり、迅速かつ柔軟に対応できる組織運営を行い、
各分野に対して業界共通のインフラ作りに取り組んでいる。
2006 年 5 月 IEC/TC100 ヘルシンキ AGM 会議における設立決定を受け、2006 年 9 月に新た
に電子出版・電子書籍をスコープとした TA10 が発足した。
電子出版及び電子書籍の分野は、
日本の技術力が強く、当分野の TAM は東京電機大学の植村八潮、TS はソニーの向井幹雄が
担当している。マルチメディア電子出版及び電子書籍分野では、日本の技術力が国際的に
先行しており、今回の会議でも国際標準化に対し日本として寄与していくことになるだろ
う。
同年 9 月ベルリンで第 1 回、翌 2007 年 10 月アルザスで第 2 回 TA10 国際会議を開催した。
同時に開催された AGM 会議において逐次現在までの進捗状況を報告している。
現在までに、
TS 62229 で電子出版の市場形成及び電子書籍コンテンツの流通・交換のための標準概念モ
デルを、次いで IS 62448 では 62229 で提案した Generic format を定義した。
現在、国際標準化に向けて以下のプロジェクトが進んでいる。
a) Generic format の Amendment 1 の検討
Extension for Generic format とし Annex A BBeB に Annex B XMDF を追加準備が進んで
おり、現在 CDV となっている。
b) Reader's format for e-publishing
Reader's format については、CDV 案が準備中である。
c) Proofreading markup language
アルザス会議で Proofreading markup language についてコメントがあった。
d) 電子書籍交換用ストレージメディア
配布ガイドラインについて資料に基づき検討が行われた。
e) 電子辞書の標準フォーマット（e-dictionary format）
アルザス会議で電子辞書ファイルフォーマットを標準化する必要性について報告があり、
NP 案の提案が求められた。
- 50 -
f) Digital Audiobook File Format CD 案の検討
米国からオーディオブックの NP 案（NP1293）が提出された。
3.4 今後の課題
マルチモーダルウェブという、最新の進化しつつある Web を対象に、それへのコンテン
ツの制作、活用、検索、運用といった多彩な場面を想定し、技術と市場について調査検討
を試みた。Web 自体が技術的に進化すると同時に、従来紙をはじめとする多様な媒体が Web
を活用しつつある状況なので、今後の課題とは言っても新たなサービスやビジネスの発掘
を含む展望とならざるを得ない。そのような観点から、課題を考察すると以下のような項
目が挙げられるであろう。
(1) 次世代 Web のサービスという観点では、Web の利用者がキーボードとマウスを使用す
る PC 利用者から、テンキーや十字キーしか使用しない、ケータイやデジタル TV 利用者
に移行する状況を想定してサービスやビジネスを検討する必要がある。
(2) そのような一般家庭の利用者が、Web を不満なく活用できるようにするためには、ホ
ームネットワークのインテリジェント化が急務である。そのためには、情報家電機器を
インテリジェント化し、XML によるメタデータやオントロジを活用する枠組みを、検討
する必要がある。
(3) 今回検討した RDF 関連技術、PIM 関連技術、ネットワーク設定自動化技術は、以上の
課題を実現するための要素技術として位置づけることができるが、これらの技術を具体
的なサービスに結びつけるためには、3.2.1.4 項で提案したようなネットワークオペレ
ータが必要になると考えられる。このような新しい事業領域を含むビジネスモデルの検
討が課題になる。
(4) 以上のようなビジネスやサービスを行う上で、PIM に代表されるメタデータとしての
個人情報のやりとりが必要になる。そのためには、個人情報を暗号化技術により非公開
情報とし、利用者の承諾の下にメタデータとして流通させる技術を確立する必要がある。
(5) 上記の個人情報を非公開にする環境の実現には、SNS をベースに公開された ID を活用
する方法が考えられ、3.2.1.4 項で紹介したような具体的なオープンな仕様も提案され
ているので、そのような仕様を活用して新たな個人・家庭ネットワーク環境を検討する
必要がある。
(6) 以上は、マルチモーダルウェブでのコンテンツを利用・管理する側の課題であるが、
マルチモーダルウェブでのコンテンツを制作する側としても、Web2.0 的なインタラクテ
ィブな機能を支援する標準的な枠組みを構築する必要がある。その実現技術として
Proofreading のためのメタデータの適用が考えられる。
(7) 電子書籍、電子辞書、オーディオブック、教材コンテンツ、カーナビなどの地図コン
テンツも、マルチモーダルウェブと連携することにより、新しい市場を開拓しつつある
ので、そのような動向をウォッチしていくことが必要である。
- 51 -
4. WG2：Web データアクセス活動報告
4.1 背景と目的
文書情報交換に関する情報基盤を整備するために、さまざまな情報端末を使って、Web
上に分散した膨大な資源にアクセスし、有用な情報を求めるための現実的な解として、
Indexing の一般化であるトピックマップ（TM）、その記述を容易にする文書スキーマ定義
言語(DSDL)、及び関連するセマンティク記述言語の充実がある。
これらの国際標準化動向をウォッチして、それと完全に整合(一致)する国内規格の開発
を行う。その結果として明らかになった国際(海外)規格等の問題点は、直ちに国際にフィ
ードバックして国際規格/海外規格の適正化も図る。
このような背景の下に WG2 が調査研究を行う課題を次に示す。
(1) トピックマップ (TM)
a) TM-4 の JIS 素案作成
b) TM-1、 -5、 -6、-7 の国際標準化動向の調査
c) TMCL、 TMQL の国際標準化動向の調査
(2) マルチモーダルサービス向上のためのデータ記述
文書スキーマ定義言語(DSDL)
a) DSDL-7 の JIS 素案作成
b) DSDL-1、-5、-8、-9 の国際標準化動向の調査
(3) スタイルセマンティｯク記述言語(XSL)
a) XSL の TS 普及動向確認
b) XSL と CSS との整合化の検討と国際提案
(4) XML データベースの問合せ言語及び関連規定の調査研究
a) Data model、XPath2.0、XSLT2.0 に関する海外標準化動向の調査
これらの調査研究の結果、期待される成果を次に示す。
・TM 関連国際規格に一致する JIS 素案
・DSDL 関連国際規格に一致する JIS 素案
・XML データベース関連規格の国内対応方針
・関連する国際(海外)標準化組織への各種提案(文書または口頭による提案)
- 52 -
4.2
活動内容
4.2.1 トピックマップ(TM)
(1) TM の JIS 素案開発
FCD13250 に基づいて、トピックマップの第 4 部(正準化)の JIS 素案を開発した。翻訳
の際に発見された問題点については、国内 SC34 専門委員会を通じて FCD コメントとして
提出した。
なお、トピックマップの第 4 部（TM-4）は、ISO/IEC13250 の 3 番目の JIS 化であり、次
にその概要について記す。
TM-4 は、第 2 部の実体を正準化するための算法を規定する。即ち、トピックマップデ
ータモデルで定義されている情報項目の整列順序を定義し、それらの情報項目及び情報項
目が持つ名前付き特性を XML 形式に直列化する変換規則を定義する。正準化により二つ
のデータ構造を比較し、同一のものであるかどうかを正確に判断することができるように
なる。
(2) TM の国際標準化動向
a) ISO/IEC 13250-1 トピックマップ 概観及び基本概念
他のパートの内容の進化に合わせて、本パートの記述も更新中。2008 年 4 月にノルウ
ェーのオスロで開かれる WG ミーティングで審議するために、新しい WD を作成中。特
に、付録 A Benefits and Promising Application of Topic Maps の記述内容について、
最近急増する適用事例を適切に反映するように努力がされている。
b) ISO/IEC 13250-4 トピックマップ 正準化
新しい FCD を作成中。13250-4 は、13250-2 で規定したデータモデルのインスタンス
を、XML Infoset で表現しているが、13250-2 データモデルで規定する情報項目及び名
前付き特性が変更されたため、その変更を吸収するための改正を行っている。
c) ISO/IEC 13250-5 トピックマップ 参照モデル
2007.11.24 に出版された CD のレビューを実施するとともに、FCD を準備中。
d) ISO/IEC 13250-6 トピックマップ 簡潔構文
2007.11.16 に出版された CD、
及び京都会議での議論を踏まえて、
新しい CD を準備中。
より良い構文にするために激しい議論が展開されている。例えば、想定する利用者、テ
ンプレートの記述方法、ステートメントの記述文法、デリミッタ、コメントなど、個人
の意図、慣れ親しんだ環境や嗜好に依存する部分も多く、全員がある程度満足できるも
のにすることの困難を乗り越えるための努力が続けられている。
e)ISO/IEC 13250-7 トピックマップ グラフ記法
2007.7.4 に出版された提案をもとに、WD を準備中。
(3) TM 関連規定(TMQL、TMCL)の国際標準化動向
a) ISO/IEC 18048 トピックマップ 問合せ言語
新しい FCD を準備中。問合せ条件の記述に使用する簡潔構文 (13250-6) の決定待ち
- 53 -
の状態になっている。
b) ISO/IEC 19756 トピックマップ 制約言語
新しい FCD を準備中。制約の記述に使用する簡潔構文 (13250-6) の決定待ちの状態
になっている。
c) ISO/IEC PDTR 29111 トピックマップ トピックマップを利用したダブリンコアメタ
データの表現
2007.9.10 に出版された PDTR の可決に基づいて、新しい PDTR を準備中。
d) NP RDF とトピックマップとの相互運用のための指針
現在、NP 投票中。投票期限は、2008.3.21
4.2.2 文書スキーマ定義言語(DSDL)
(1) DSDL の JIS 素案開発
ISO/IEC 19757-7 Character Repertoire Description Language は、現在 FCD 投票中で
ある。
今年度は、この FCD に基づいて、DSDL の第 7 部（文字レパートリ記述言語）の JIS 素案を
作成した。翻訳の際に発見された問題点については、国内 SC34 専門委員会を通じて FCD
投票のときに提出する予定である。
DSDL の第 7 部は、ISO/IEC19757 の 4 番目の JIS 化であり、次にその概要について記す。
XML 文書では、ISO/IEC10646 に含まれるほとんどすべての文字を使用することができる
が、その文字の一部しか使用しないという制約を設ける手段は、XML には存在しない。
この規格は、正規表現による指定及び ISO/IEC10646 のブロック指定などを論理演算によ
って組み合わせて、
文字レパートリを記述する。
文字レパートリ記述を Schematron や RELAX
NG などのスキーマ言語から呼び出すことによって、ISO/IEC10646 の文字の一部しか XML
文書で使用しないという制約を設けることができる。また、XML 文書全体ではなく、XML
文書の特定の部分だけについて、
文字レパートリ制約を設けることも可能になる。
よって、
文字の数が多い日本にとっては特に有益である。
(2) DSDL の国際標準化動向
ISO/IEC 19757-4 Namespace-based Validation Dispatching Language の JIS 原案を昨
年度に作成したが、その過程でいくつかの欠陥を発見した。JIS 原案作成者は SC34 におけ
る NVDL の Project Editor でもあるので、SC34 において defect report を発行し、Draft
Technical
Corrigendum を作成した。現在、SC34 において投票中である。
ISO/IEC 19757-3 Schematron の JIS 原案を昨年度に作成したが、その過程でいくつかの
欠陥を発見した。これらは、SC34 における Schematron の Project Editor である Rick
Jelliffee に連絡済みである。これらは、Schematron の拡張(amendment)のときに修正され
る予定である。
- 54 -
スキーマ言語群 DSDL については、一つの山を越えたといってよい。Part 2、3、 4 の規
格化は完了（これらは JIS 化も完了）し、Part 5、 7、 8、 9 についても FDIS に向かい
つつある。DSDL についての残件は、Part 1、6、10 と Amendment に過ぎない。
2007 年 11 月の JTC1/SC34/WG1 京都会議の結果について、簡単に報告する。
a) DSDL Part 1(Overview)
FCD 投票をもう一度行うことになった。
b) DSDL Part 2(RELAX NG)
正誤表の SC34 投票が有効数に足りず、再投票になった。
c) DSDL Part 3(Schematron)
拡張方針についての説明がエディタの Rick Jelliffe からあった。今後、Proposed Draft
Amendment を作成していく。
d) DSDL Part 4(NVDL)
正誤表の SC34 投票が有効数に足りず、再投票になった。
e) DSDL Part 5(Datatypes)
FCD 投票にかけることになった。
f) DSDL Part 6
ストリーム実装可能なパス式の規定と、それを Schematron からどう呼び出すかの規定を
まとめた CD を作成して、CD 投票にかけることになった。
g) DSDL Part 7(Character Repertoire Description Language)
FCD 投票にかけることになった。文字レパートリの登録簿となにを参照するかが課題で
あったが、Unicode consortium の CLDR と IANA の Character Set Registry の二つを参照
することになった。
h) DSDL Part 8(Document Schema Renaming Lanugage)
FDIS 投票にかけることになった。
i) DSDL Part 9(DTD 拡張)
FDIS 投票にかけることになった。
j) DSDL Part 10(validaiton Management)
DSDL の各パートを呼び出すための機構であるが、今後どう進むかが不明瞭なパートで
ある。実質的には、W3C の XProc がこの機構となることが期待されている。
4.2.3 XML データベース問合せ言語及び関連規定
(1) Data model
XQuery 1.0 and XPath 2.0 Data Model (XDM)は、W3C から 2007 年 1 月 23 日に勧告とし
て出版され、次を定義している。
a) XSLT プロセサ又は XQuery プロセサの入力情報
- 55 -
b) XSLT 言語、XQuery 言語及び XPath 言語で式が利用できる全ての値
データモデルは、XML 情報集合（XML Information Set）を基にしているが、W3C XML
Schema データ型の支援、文書ならびに複合値の集まりの表現、型付けした原子値、及び順
序付きの混成の列の支援を要件としている。
XDM では、概念として、次を定義している。
- 全てのデータモデルのインスタンスは、列である。
- 列は、0 以上の項目の順序付けされた集まりである。
- 項目は、ノード又は原子値のいずれかである。
- ルートノードが文書ノードである木は、文書として参照される。
- ルートノードが文書ノードでない木は、素片として参照される。
- 原子値は、原子型の値空間内の値であり、その原子型の名前で識別される。
- 原子型は、原始的な単純型又は他の原子型からの制限によって得られる型である。
- 24 の原始的な単純型がある。19 は、W3C XML Schema Part 2 で定義され、xs:untyped、
xs:untypedAtomic、xs:anyAtomicType、 xs:dayTimeDuration、及び
xs:yearMonthDuration は、XDM で定義される。
- 展開した QName は、空でもよい前置詞、空でもよい名前空間 URI、及び局所名から構
成される三つの値の集合である。
- 実装定義は、実装間で異なることができることを示すが、それぞれの個別の実装につ
いて実装者によって規定されなければならない。
- 実装依存は、実装間で異なることができることを示し、この規格又は全ての W3C 規格
によって規定されず、全ての個別の実装について実装者によって規定されることを必
要とされない。
- 文書順は、与えられた問合せ又は変換中にアクセスできる全てのノードの間で定義さ
れる。文書順は、絶対的な順序であるが、いくつかのノードの相対順序は実装依存で
ある。非公式に、文書順は、ノードが文書の XML 直列化で出現する順序である。
- 文書順は、安定している。二つのノードの相対順序は、順序が実装依存であるときで
さえ、与えられた問合せ又は変換処理中に変更されないことを意味する。
- 匿名型の名前は実装依存であり、利用可能なスキーマで宣言される全ての型について
プロセサにより提供される一意の型名である。
また、次についても述べている。
- データモデルのインスタンスで全てのノードは、一意である。
- 列は、XPath 1.0 のノード集合の置き換えである。
- データモデルは、スキーマ型の名前を表現するために展開した QNames を使用し、W3C
XML Schema Part 2 で定義される組み込み型、この規格で定義される五つの追加の型
を含み、さらに他の利用者定義又は実装定義の型を含んでもよい。
- 56 -
(2) XPath 2.0
XML Path Language (XPath) 2.0（XPath 2.0）は、XPath 1.0 の後継として W3C から 2007
年 1 月 23 日に勧告として出版された。XPath 2.0 は、XML 文書内のノードを特定するため
の言語であり、XQuery 1.0 及び XSLT 2.0 で使用される。
XPath 1.0 と XPath 2.0 との間の振舞いの違いを明らかにする一環として XML Path
Language (XPath) 2.0 勧告の“附属書 I XPath 1.0 との後方互換性（参考）”を翻訳した。
翻訳に当たって、用語を明らかにするために“H 用語（参考）”についても翻訳した。
また振舞いの違いについてもまとめた。但し、これ以外に個別の関数に関しても振舞い
に違いが存在する。
XPath 2.0 の特徴として、列及びデータ型の導入があげられる。
XPath 2.0 で、式及び関数の結果であるノード及び原子値は、(1)の XDM で定義されるよ
うに列として扱われ、式内での for 関数の利用といった新しい機能を提供している。
データ型の導入は、型の安全性を確保し、型を意識した演算を可能とする一方で、関数
及び演算の引数又は被演算子への型の要求、及び XPath 1.0 との非互換性といった利便性
とのトレードオフがある。
(3) XSLT 2.0
XSL Transformations (XSLT) Version 2.0（XSLT 2.0）は、XSLT 1.0 の後継として W3C
から 2007 年 1 月 23 日に勧告として出版された。XSLT 2.0 は、XML 文書を他の XML 文書に
変換するための言語である。
XSLT 1.0 と XSLT 2.0 との間の違いを明らかにする一環として XSL Transformations
(XSLT) Version 2.0 勧告の“附属書 J XSLT 1.0 からの変更（参考）”を翻訳した。
翻訳に当たって、用語を明らかにするために“H 用語（参考）”についても翻訳した。
また振舞いの違いについてもまとめた。但し、これ以外に個別の関数に関しても振舞い
に違いが存在する。
非互換の変更として、“附属書 J XSLT 1.0 からの変更（参考）”で次が述べられている。
- 空白除去の振舞い。
- 直列化の振舞い。
- [xsl:]version 属性を使用することによって後方互換性を保つことのできる振舞い。
- W3C XML Schema が適用されない状況で後方互換性の設定にもかかわらずに非互換の振
舞い。
- W3C XML Schema が適用される状況での振舞い。
新しい機能として、次のような機能が追加されている。
- 結果木素片データ型の廃止（列の導入）。
- 複数の結果出力。
- グループ化。
- 利用者による関数定義。
- 57 -
(4) 国内標準化への提言
a) XDM は、XPath 2.0、XQuery 1.0、及び XSLT 2.0 の基本となる概念を定義している規
格であり、XPath 2.0、XQuery 1.0、又は XSLT 2.0 を JIS として制定するときに、それ
らと共に JIS、TS、又は TR として制定したほうがよいと考える。
b) XSLT 2.0 は、現状で、実装がほとんどなく、利用されていないので、JIS として制定
する必要はないと考える。
c) XPath 2.0 は、XSLT 2.0 及び XQuery 1.0 で使用され、XML 文書内のデータを特定す
るための重要な規格である。XML データに対応しているデータベース管理システムは、
XQuery 1.0 に対応していることが多く、XQuery 1.0 は、Java Community Process（JCP）
において、Java Specification Requests（JSR） 225: XQuery API for JavaTM (XQJ)
（ http://www.jcp.org/en/jsr/detail?id=225 ）として XQuery を扱うための API の仕
様が策定されつつある。XQuery 1.0 の普及に伴い、XQuery 1.0 を JIS として制定する場
合に、XPath 2.0 についても JIS として制定する必要があると考える。
d) 上記の３規格は、以下の規格群（W3C の Web ページから抜粋）の一部であり、JIS
の制定に際して、これらの関係も考慮する必要がある。
The main XML Query documents:
- XQuery 1.0: An XML Query Language (W3C Recommendation)
- XML Syntax for XQuery 1.0 (XQueryX) (W3C Recommendation)
- XML Query (XQuery) 1.0 Requirements (W3C Working Group Note)
- XML Query 1.0 Use Cases (W3C Working Group Note)
- Building a Tokenizer for XPath or XQuery (Joint Note)
XSLT 2.0 shares a lot of the same functionality:
- XSL Transformations (XSLT) Version 2.0 (by the XSL Working Group)
XQuery 1.0 and XSLT 2.0 both use XPath 2.0:
- XML Path Language (XPath) 2.0 (W3C Recommendation; Joint)
- XPath Requirements Version 2.0 (Joint)
- XPath in turn is built on a number of Joint specifications :
- XQuery 1.0 and XPath 2.0 Data Model (W3C Recommendation; Joint)
- XSLT 2.0 and XQuery 1.0 Serialization (W3C Recommendation; Joint)
- XQuery 1.0 and XPath 2.0 Formal Semantics (W3C Recommendation; Joint)
- XQuery 1.0 and XPath 2.0 Functions and Operators (W3C Recommendation; Joint)
The XML Query and XSL Working Groups are developing Full-Text Search for XPath
2.0; this will then be available for future versions of XQuery and XSLT:
- XML Query and XPath Full-Text Requirements (Joint)
- XML Query and XPath Full-Text Use Cases (Joint)
- XQuery 1.0 and XPath 2.0 Full-Text (Joint)
- 58 -
The XML Query Working Group is developing an update facility for XQuery; this
lets you write Query expressions that change documents and perhaps save the
result.
- XQuery Update Facility
- XQuery Update Facility Requirements
- XQuery Update Facility Use Cases
The XML Query Working Group is starting work on the next verion of XML Query、
XQuery 1.1、 and also on scripting extensions for XQuery.
- XML Query (XQuery) 1.1 Requirements
- XQuery Scripting Extension 1.0 Requirements
4.2.4 スタイル指定言語
(1) XSL の TS 原案見直し
TS X0088 の原案作成を昨年度着手し完了したが、その後 W3C の原規定が勧告になったた
め、本年度はその見直しを行った。このとき、用語のゆれ等の洗い出しを行った。TS
X0088 では、なるべく原規定に忠実な翻訳に努めた。JIS 化はこれらのゆれが解消された
後に行う予定である。
いくつか問題となっているゆれ等について、主なものを次に列挙する。
a) XML
単に XML と表記した場合、XML 1.0 を指す場合と、XML 1.0 又は XML 1.1 のいずれ
かを指す場合とがある。
b) フォーマッタ
図中で“XSL フォーマッタ”と表記し、
本文中では“フォーマッタ”と表記している。
c) XSL 変換
図中で“XSL 変換（XSLT）”と表記し、本文中では“木変換”と表記している。
d) FO
“FO”は、“フォーマット化オブジェクト”を意味している。これは、場合によって
は“XSL-FO”と表記されていることもある。小文字で表記されている“fo”は、“fo
名前空間”として用いられている。しかし、“XSL 名前空間”という用語も出現する。
e) 引用符
用語やキーワードを引用符“”で囲んでいるものとそうでないものが混在しているが、
その基準があいまいであり、不統一となっている。
また、太字の用法に関しても不統一である。例えば、次の三つの表現が混在する。
writing-mode、“writing-mode”、<b>writing-mode</b>
f) 用語の訳し分け
例えば、本文中に writing-mode が出現するとき、用語としての writing-mode を示
- 59 -
す場合と、表記方法と訳すべき場合との判別は難しい。
(2) XSL と CSS の機能比較と整合の必要性
XML などによって構造を記述された文書情報に加えて、その文書情報の中のオブジェク
トを可視化する際のフォーマティングスタイルを指定することによって、編集可能性を残
したまま文書交換におけるレンダリング結果の保存(preserving)を可能にするため、スタ
イル指定言語が開発されてきた。FOSI、DSSSL などのスタイル指定言語の経験に基づき、
W3C は CSS 及び XSL を開発し、
さらにそれらの改版を続けている。
国内においても、
CSS level
1 及び XSL 1.0 は規定[1]、[2]として公表されている。
これらのスタイル指定言語は、いずれも文書情報において論理構造情報とスタイル指定
情報とを分離して扱うという ISO/IEC JTC1 の SC18、 SC34 の文書情報モデルに基づいてい
るが、CSS と XSL は W3C の中の異なるグループによって、異なる背景と利用者要求のもと
に開発された。
DSSSL は極めて複雑なスタイル指定まで可能にすると共に構造変換機能をも含めた高機
能スタイル指定言語であるが、構文として Scheme が使われていたため、その普及は Lisper
に限られていた。DSSSL の機能を保ちつつ、構文に XML を用いた言語として XSL は開発さ
れた。そこで、XSL は、XML 等によって構造記述された文書データを、ウェブブラウザ、書
籍における物理的ページの集合などの表示メディア上に、多様な文書内容をスタイル付け
し、レイアウトし、ページ付けする[4]。
HTML 改版の過程で、スタイル指定要素の導入が HTML の規定内容を複雑かつ大規模なも
のにする可能性があったため、HTML からできるだけスタイル指定要素を排除して、その機
能を CSS として分離することにより、HTML の交換性を高めた。
当初、CSS level 1 はページの概念のない Web 文書を対象にして、フォント、スペース、
カラーなどの比較的簡易なスタイルを扱っていた[3]が、その後 level 2 においてページモ
デルを導入する[5]とともに、多様なフォーマット要素(formatting object)への対応を可
能にし、さらに level 3 の検討が開始されている。
XSL は、Version 1.1 の公表[6]を経て、Version 2.0 の検討が始まっている。
これらの検討の中で、CSS と XSL のスコープの重なり部分が拡大し、互いに類似する機
能が増えると共に、同じ機能の異なる表現等も指摘されている。CSS、XSL の普及とスコー
プの重なりの拡大とともに、それらの利用者からは両言語の機能比較と対応する機能の整
合(機能表現の整合を含む)とに対する要求が高まっている[7]、[8]、[9]。
【備考】
4.2.4 (2)の記述は、以下から引用した。
川邉 裕彦、 木埜 達也: スタイル指定言語の機能比較と整合
－注に関連するフォーマット要素、画像電子学会第 234 回研究会、 2007-11-02
【参考文献】
[1] JIS X 4168:2004、 段階スタイルシート 水準 1(CSS1)、 2004-06.
- 60 -
[2] TR X 0088:2003、 拡張可能なスタイルシート言語(XSL) 1.0、 2003-09.
[3] Cascading Style Sheets、 level 1、 W3C Rec.、 1996-12.
[4] Extensible Stylesheet Language (XSL) Version 1.0、 W3C Rec.、 2001-10.
[5] Cascading Style Sheets、 level 2、 W3C Rec.、 1998-05.
[6] Extensible Stylesheet Language (XSL) Version 1.1、 W3C Rec.、 2006-12.
[7] 平成 18 年度ユビキタス社会を推進する情報基盤の標準化調査研究(UBQ1/WG1)成果
報告書、日本規格協会 情報技術標準化研究センター、2007-03、
http://www.jsa.or.jp/stdz/instac/index.htm
[8] アンテナハウス、W3C Print Symposium 2006 (3) XSL-FO と CSS の互換性、2006-10、
http://blog.antenna.co.jp/PDFTool/archives/2006/10/w3c_print_sympo_1.html.
[9] マルチモーダルウェブマイニング技術の標準化調査研究委員会 WG2 2007 年度計画、
日本規格協会 情報技術標準化研究センター、2007-07、
http://www.jsa.or.jp/stdz/instac/index.htm
(3) XSL と CSS の機能比較
新たに追加された特性があるだけでなく、XSL では writing-mode 及び参照方位の概念が
加わったため、left、right、top 及び bottom が、CSS におけるように単純に包含ブロック
に関係せず、
（直近の先祖の参照領域によって確立される）一般座標系に変換されるなど、
writing-mode 及び参照方位に対応した拡張がある。また、before、after、start、end、
inside、
及び outside の概念が追加されたため border や padding がこれらに対応するなど、
用語として継承されていても、概念が拡張されているものが多くあるので注意を要する。
特に margin は、CSS との互換を目的として提供されており、XSL への対応付けの詳細を
参照する必要がある。
フォーマット化特性（Formatting Property）における XSL と CSS との違いを、別表にま
とめたので、参照されたい。
[附属資料 WG2-3 参照]
(4) XSL を CSS に変更する際の機能的問題
－XSL と CSS の解釈の違いについて－
XSL と CSS でのモデルの違いに起因する解釈の違いを次に示す。
a) モデルの相違
XSL は「領域モデル」、CSS は「ボックスモデル」と呼ばれているが、どちらも、長
方形を入れ子に配置する点は同じである。この長方形には、padding、border、spac
（margin）といった属性が付いている。
XSL と CSS での大きな違いは、padding、border が長方形の外側に取られるのか、内
側に取られるのかということである。
- 61 -
XSL の領域モデル
|
V
+------------------------+
|
space
|
| +------------------+
|
| |
border
|
|
| |
+------------+
|
|
| |
|
padding |
|
|
-->| |
| +------+ |
|
|
| |
| | 内容 | |
|
|
| |
| |
|
|
| |
CSS のボックスモデル
|
V
+------------------------+
|
margin
|
-->| +------------------+
|
| |
border
|
|
| |
+------------+
|
|
| |
|
padding |
|
|
| |
| +------+ |
|
|
| |
| | 内容 | |
|
|
| |
| |
|
|
| |
XSL の属性の多くは、CSS との互換性のために設けられている。
特に、XSL における「margin」は、そのような目的で用意されているが、その振る舞
いは CSS と一致しない。XSL の margin は、start-indent、end-indent などに変換され
るが、start-indent、end-indent の継承の具合が、XSL と CSS で異なることなどにより、
意図した結果を得られないことが多い。
これは仕様の不理解が原因であるといえばそれまでであるが、混乱の原因となってい
ることに違いはない。
b) マージンの縮退
XSL でも CSS でも、上下に隣接する領域間のマージンは、大きい方が採用される。こ
れは、似ているが細部は両者で異なっている。
- 62 -
XSL では、大きい方が単純に採用されて、小さい方はゼロになる。
例えば、
|
|
+------+
↓上マージン小
↑下マージン大
│
+------+
|
|
という場合、XSL では上のブロックのマージンはゼロとみなされ、
|
|
+------+上マージンはゼロとなる
↑
│
+------+
|
|
となる。CSS では大きい方が共通のマージンとなる。
|
|
+------+
↑│
│↓
+------+
|
|
領域が入れ子の場合も同様である。
↑外マージン小
-------↑内マージン大
│
+------+
|
|
- 63 -
XSL では大きいほうだけが残る。
--------外マージンはゼロとなる
↑
│
+------+
|
|
CSS では大きい方が共通のマージンとなる。このとき、ボーダーの位置に注意が必要
である。
↑↑
││
--------内側の領域と外側の領域のボーダーは同じ位置になる
+------+
|
|
（5) XSL と CSS とが混在する場合の適用順序
－ <?xml-stylesheet?>の指定 －
XML 中に<?xml-stylesheet?>を書いてスタイルシートを指定することができる。
このとき、<?xml-stylesheet type="text/xml" href="stylesheet.xsl"?>
<?xml-stylesheet type="text/css" href="stylesheet.css"?>
のように、相反する(であろう)スタイルシートを指定したときの振る舞いは、
http://www.w3.org/TR/xml-stylesheet/による記述では、HTML の <link
el="stylesheet"> と同じ動作ということになっている。
HTML 4.01 14.3 External style sheets
http://www.w3.org/TR/REC-html40/present/styles.html#h-14.3
による記述では、外部スタイルシートを、常に有効にさせるか、ユーザに選択させるか
を指定することができる。
問題は、両方に「常に有効」を指定したときであろう。仕様には、その場合の振る舞
いについての記述が見当たらない。
4.3 成果のまとめ
今年度の WG2 の活動成果を次にまとめる。
4.3.1 トピックマップ(TM)
TM-4(ISO/IEC 13250-4)の JIS 素案を開発した。
- 64 -
[附属資料 WG2-1 参照]
4.3.2 文書スキーマ定義言語(DSDL)
DSDL-7(ISO/IEC 19757-7)の JIS 素案を開発した。
[附属資料 WG2-2 参照]
4.3.3 XML データベース問合せ言語及び関連規定
XML データベース問合せ言語及び関連規定として、Data model、XPath 2.0、XSLT 2.0
に関する海外標準化動向の調査を行い、それらの規定の重要な部分の翻訳を行った。
また、国内標準化への提言を 4.2.3(4)に示した。
4.3.4 スタイル指定言語
W3C の原規定が勧告になったため、TS X0088 の原案見直し及び用語のゆれ等の洗い
出しを行った。
XSL と CSS の機能比較と整合については、4.2.4(3)に示す“XSL と CSS の機能比較”の
リストが成果として得られた。この調査研究とリエゾンをとり、ほぼ同期して大阪工業
大学でも同テーマの研究が行われ、次の文献が発表されている。
- 梶間幸輝、 川邉 裕彦: CSS(PMM)と XSL の機能比較と整合 － ページモデル、 画像
電子学会第 35 回年次大会、 S.1-1、 2007-06-23
- 川邉裕彦、 木埜達也: スタイル指定言語の機能比較と整合 － 注に関連するフォー
マット要素、 画像電子学会第 234 回研究会、 2007-11-02
- 小田真彦、 木埜達也: CSS と XSL の機能比較と整合 － インラインオブジェクト、 画
像電子学会第 35 回年次大会、 S.1-2、 2007-06-23
4.3.5 2006 年度開発原案のフォロー
2006 年度までに開発された次の原案を制定するための作業(規格調整委員会及び情報
技術専門委員会への対応)を行い、2008 年 2 月の情報技術専門委員会で承認された。
(1) DSDL-3 の JIS 原案
(2) DSDL-4 の JIS 原案
(3) MIME-1 の JIS 原案
(4) MIME-2 の JIS 原案
(5) MIME-3 の JIS 原案
(6) MIME-5 の JIS 原案
(7) XSL 1.1 の TS 原案
次の原案については、JSA 内での手続きを完了し、2008 年 2 月末に METI に提出した。
(1) TM-2 の JIS 原案
(2) TM-3 の JIS 原案
- 65 -
4.4 今後の課題
4.4.1 トピックマップ(TM)
今年度に開発した TM-4(ISO/IEC 13250-4)の JIS 素案の翻訳対象は FCD テキストである
ため、今後は FDIS 投票結果を見てから、JIS 原案として完成させて JSA に提出する必要が
ある。また、2006 年度開発原案のフォローとして行った
(1) TM-2 の JIS 原案
(2) TM-3 の JIS 原案
については、情報技術専門委員会への対応を今後の課題として残している。
4.4.2 文書スキーマ定義言語(DSDL)
今年度に開発した DSDL-7(ISO/IEC 19757-7)の JIS 素案の翻訳対象は FCD テキストであ
るため、今後は FDIS 投票結果を見てから、JIS 原案として完成させて JSA に提出する必要
がある。
4.4.3 XML データベース問合せ言語及び関連規定
Data model、XPath 2.0、XSLT 2.0 に関する海外標準化動向調査の結果をさらに検討し
て、必要に応じて、JIS または TS の原案を作成することが望ましい。
4.4.4 スタイル指定言語
本年度に見直して制定された標準仕様書（TS）は、4.2.4(1)に示す問題があり、これら
が解決された後に、JIS 原案作成を行い JSA に提出する必要がある。
XSL と CSS の機能比較については、今年度の成果と関連する研究成果とをまとめ、それ
を W3C の対応する標準化グループにフィードバックすることが強く望まれる。
- 66 -
5. 今後の展望と課題
マルチモーダルウェブマイニングを可能にするための技術について、二つの WG によって
調査研究を推進した。WG によってアプローチの方法は幾分異なり、その結果、得られた WG
毎の成果と今後の課題は、WG1 については 3.3 項と 3.4 項、WG2 については 4.3 項と 4.4 項
に示されている。
いずれの WG の活動についても、この報告書をもってその活動を直ちに終了することはで
きない。マルチモーダルウェブマイニングというキーワードを世に提示して、それによっ
て得られる Web 応用を示した以上、本調査研究に参加した関係者は、その実現のために何
らかの方法で活動を続けることが望まれている。特にここでの活動をベースとして、国内
的/国際的に起動または関与した次の標準化活動については、社会的責任として今後も継続
する必要がある。
(1) IEC/TC100
Architectural model and usecase for PIM ontology
Reference model for home network configuration
SNS objects for multimedia information interchange
Interchange format for e-dictionary
Interchange format for proofreading
Electronic presentation media specific rendering
(2) JTC1/SC34
Topic maps (TM)
Document schema definition language (DSDL)
(3) W3C
XSL/CSS harmonization
(4) JIS
TM-4
TM-2
TM-3
DSDL-7
XSL
これらの内容をどのようにするかを検討する以前に、本調査研究のために集まったエキ
スパートに対して、如何にしてその専門的検討を継続していただく環境を提供するかが、
まず解決すべき課題である。
- 67 -
附属資料
[附属資料 WG2-1]： TM-4 JIS 素案（抜粋）
，トピックマップ
第 4 部 正準化
[附属資料 WG2-2]： JIS X 4177-3 素案（抜粋），文書スキーマ定義言語(DSDL)
第 7 部 文字レパートリ記述言語（CREPDL）
[附属資料 WG2-3]： フォーマット化特性（Formatting Property）における
XSL と CSS との違い
- 68 -
X XXXX-4：0000 (ISO/IEC 13250-4：2008)
〔附属資料
WG2-1〕
目 次
ページ
序文................................................................................................................................................................ 1
0
導入 ........................................................................................................................................................ 1
1
適用範囲 ................................................................................................................................................. 1
2
引用規格 ................................................................................................................................................. 1
3
正準化..................................................................................................................................................... 2
3.1
導入 ................................................................................................................................................. 2
3.2
表記規約 .......................................................................................................................................... 2
3.3
CXTM 文書情報項目....................................................................................................................... 2
3.4
トピックマップ情報項目表現の構築 .............................................................................................. 2
3.5
トピック項目表現の構築................................................................................................................. 2
3.6
トピック名項目表現の構築 ............................................................................................................. 2
3.7
異形項目表現の構築........................................................................................................................ 2
3.8
出現項目表現の構築........................................................................................................................ 2
3.9
関連項目表現の構築........................................................................................................................ 2
3.10
関連役割項目表現の構築............................................................................................................. 2
3.11
[reifier]特性表現の構築............................................................................................................... 2
3.12
[reified]特性表現の構築 .............................................................................................................. 2
3.13
[scope]特性表現の構築 ................................................................................................................ 3
3.14
[item identifiers]特性表現の構築 ............................................................................................... 3
3.15
[datatype]特性表現の構築 .......................................................................................................... 3
3.16
[type]特性表現の構築.................................................................................................................. 3
3.17
[value]特性表現の構築................................................................................................................ 3
3.18
文字列特性の符号化 .................................................................................................................... 3
3.19
位置による値の符号化 ................................................................................................................ 3
3.20
要素情報項目のためのデフォルト属性値 ................................................................................... 3
3.21
属性情報項目のためのデフォルト属性値 ................................................................................... 3
4
正規の整列順序 .................................................................................................................................... 3
4.1
導入 ................................................................................................................................................. 3
4.2
情報型と基本型の整列順序 ............................................................................................................. 3
4.3
文字列の比較................................................................................................................................... 3
4.4
集合の比較 ...................................................................................................................................... 3
4.5
ロケータのための比較順序 ............................................................................................................. 3
4.6
トピック項目のための整列順序...................................................................................................... 3
4.7
トピック名項目のための整列順序 .................................................................................................. 3
4.8
異形項目のための整列順序 ............................................................................................................. 3
（1）
X XXXX-4：0000 (ISO/IEC 13250-4：2008)
4.9
5
出現項目のための整列順序 ............................................................................................................. 3
4.10
関連項目のための整列順序 ......................................................................................................... 3
4.11
関連役割項目のための整列順序 .................................................................................................. 3
ロケータの正規化 ............................................................................................................................... 3
附属書 Ａ（参考）CXTM のための RELAX-NG スキーマ ......................................................................... 3
（2）
JIS
X XXXX-4：0000
日本工業規格（案）
(ISO/IEC 13250-4：2008)
トピックマップ － 正準化
Topic Maps - Canonicalization
序文
この規格は，2008 年に第 1 版として発行された ISO/IEC 13250-4:2008，Topic Maps - Canonicalization を
基に，技術的内容及び対応国際規格の構成を変更することなく作成した日本工業規格である。
なお，この規格で点線の下線を施してある参考事項は，対応国際規格にはない事項である。
0
導入
ISO/IEC13250 のこの部は、Canonical XTM、略して CXTM として知られる書式を定める。その書式は
XML 書式であり、二つの等しいトピックマップデータモデルインスタンス[JIS X XXXX-2]が、常にディス
クの上でバイト列レベルで同一の直列化結果を生じることを保証する特性を持つ。そして、不等価なイン
スタンスは常に異なる直列化結果を生じる。CXTM はこのように、二つのトピックマップ同士の直接の比
較を、その正準な直列化によって可能にする。
CXTM の目的は、異なるトピックマップの実装間において容易な可搬性のある、様々なトピックマップ
関連技術に対する試験項目を作成することである。
CXTM はトピックマップの相互交換のために用いられることを目的とはしないが、それもまた可能では
ある。トピックマップの相互交換のための標準書式は、XTM[ISO/IEC 13250-3]である。
1
適用範囲
この規格は、CXTM 書式を定め、トピックマップから CXTM ファイルがどのように作成されるかにつ
いて規定する。トピックマップデータモデル[JIS X XXXX-2]から XML 情報集合[XML Infoset]への変換。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 13250-4:2008，Topic Maps - Canonicalization (IDT)
なお，対応の程度を表す記号(IDT)は，ISO/IEC Guide 21 に基づき，一致していることを示す。
2
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格のうちで，西暦年を付記してあるものは，記載の年の版を適用し，その後の改正版（追補を含む。
）
には適用しない。西暦年の付記がない引用規格は，その最新版（追補を含む。）を適用する。
注記
次のそれぞれの規格は，文の中において規格を引用するのに使用される一意の識別子をもつ。
一意な識別子は，太字で示した名称とする。
JIS X 0221
国際符号化文字集合（UCS）
2
X XXXX-4：0000 (ISO/IEC 13250-4：2008)
ISO/IEC 10646, Information technology — Universal Multiple-Octet Coded Character Set (UCS)
注記
に一致している。
ISO/IEC 10646-1
ISO/IEC 10646-1:2000: Information technology - Universal Multiple-Octet Coded
CharacterSet (UCS) - Part 1: Architecture and Basic Multilingual Plane , ISO, 2000
ISO/IEC 10646-2
ISO/IEC 10646-2:2001 Information technology - Universal Multiple-Octet Coded
CharacterSet (UCS) - Part 2: Supplementary Planes, ISO, 2001
JIS X 4177-2:2004
及び
注 記
文書スキーマ定義言語(DSDL)－第 2 部：正規文法に基づく妥当性検証 - RELAX NG
追補 1:2006
ISO/IEC
19757-2,
Document
Schema
Definition
Languages
(DSDL)
-
Part
2:
Regular-grammar-based validation - RELAX NG が，この規格に一致している。
JIS X xxxx-2:2007
ISO/IEC 13250-2:2006,
注記
Unicode
トピックマップ
－
データモデル
Topic Maps — Data Model が，この規格に一致している。
The Unicode Standard, Version 4.0, The Unicode Consortium, Reading, Massachusetts, USA,
Addison-Wesley, 2003, ISBN 0-321-18578-1
RFC3986
Uniform Resource Identifiers (URI): Generic Syntax, Internet Standards Track Specification, January
2005
http://www.ietf.org/rfc/rfc3986.txt から入手できる。
注記
RFC3987
Internationalized Resource Identifiers (IRIs), Internet Standards Track Specification, January 2005
注記
XML-C14N
注記
XML-Infoset
注記
http://www.ietf.org/rfc/rfc3987.txt から入手できる。
Canonical XML Version 1.0, W3C Recommendation, 15 March 2001
http://www.w3.org/TR/2001/REC-xml-c14n-20010315/から入手できる。
XML Information Set (Second Edition), W3C Recommendation, 4 February 2004
http://www.w3.org/TR/2004/REC-xml-infoset-20040204/から入手できる。
以下、項目番号のみとし、規定文は省略した。
―――――――――――――――――――――
3
正準化
3.1
導入
3.2
表記規約
3.3
CXTM 文書情報項目
3.4
トピックマップ情報項目表現の構築
3.5
トピック項目表現の構築
3.6
トピック名項目表現の構築
3.7
異形項目表現の構築
3.8
出現項目表現の構築
3.9
関連項目表現の構築
3.10 関連役割項目表現の構築
3.11
[reifier]特性表現の構築
3.12 [reified]特性表現の構築
3
X XXXX-4：0000 (ISO/IEC 13250-4：2008)
3.13 [scope]特性表現の構築
3.14 [item identifiers]特性表現の構築
3.15 [datatype]特性表現の構築
3.16 [type]特性表現の構築
3.17 [value]特性表現の構築
3.18 文字列特性の符号化
3.19 位置による値の符号化
3.20 要素情報項目のためのデフォルト属性値
3.21 属性情報項目のためのデフォルト属性値
4
正規の整列順序
4.1
導入
4.2
情報型と基本型の整列順序
4.3
文字列の比較
4.4
集合の比較
4.5
ロケータのための比較順序
4.6
トピック項目のための整列順序
4.7
トピック名項目のための整列順序
4.8
異形項目のための整列順序
4.9
出現項目のための整列順序
4.10 関連項目のための整列順序
4.11
5
関連役割項目のための整列順序
ロケータの正規化
附属書 Ａ（参考）CXTM のための RELAX-NG スキーマ
X 4177-7：0000 (ISO/IEC 19757-7：2007)
〔附属資料
WG2-2〕
目 次
ページ
序文 ························································································································································································ 1
0
導入·················································································································································································· 1
1
適用範囲·········································································································································································· 1
2
引用規格·········································································································································································· 2
3
用語及び定義 ································································································································································· 2
4
表記法·············································································································································································· 3
5
レパートリ，核及び殻 ················································································································································ 3
6
構文·················································································································································································· 3
6.1
一般··············································································································································································· 3
6.2
RELAX NG スキーマ ··············································································································································· 3
6.3
NVDL スクリプト ····················································································································································· 4
6.4
文字クラス ·································································································································································· 5
7
意味·················································································································································································· 6
7.1
一般··············································································································································································· 6
7.2
char ··············································································································································································· 6
7.3
union············································································································································································· 7
7.4
intersection ·································································································································································· 7
7.5
difference ····································································································································································· 7
7.6
ref ·················································································································································································· 8
7.7
repertoire ····································································································································································· 8
8
検証·················································································································································································· 8
9
適合性·············································································································································································· 8
附属書 A（参考）例 ························································································································································· 10
A.1
ISO 8859-6 ································································································································································ 10
A.2
ISO 8859-15 ······························································································································································ 10
A.3
学年別漢字配当表の第 1 学年に配当されている漢字 ···················································································· 11
A.4
学年別漢字配当表の第 2 学年に配当されている漢字 ···················································································· 13
（1）
JIS
X 4177-7：0000
日本工業規格（案）
(ISO/IEC 19757-7：200X)
文書スキーマ定義言語(DSDL)第 7 部：文字レパートリ記述言語(CREPDL)
Document Schema Definition Languages (DSDL)-Part 7:Character
Repertoire Description Language(CREPDL)
序文
この規格は，200X 年に第 1 版として発行された ISO/IEC 19757-7 を基に，技術的内容及び対応国際規格
の構成を変更することなく作成した日本工業規格である。
0
導入
JIS X 4177 規格群は，Document Schema Definition Languages (DSDL)の集まりを規定する。DSDL は，
XML1.0（拡張可能なマーク付け言語）文書に適用される一つ又はそれ以上の検証プロセスを規定する。
DSDL においては幾つもの検証技術が標準化され，既に規格の形で提供されているもの及び産業界から提
供されているものを補完する。
JIS X 4177 規格群の主な目的は，検証に関する複数の技術を集めて一つの拡張可能な枠組みとし，技術
を順番又は並列に適用して一つ又は複数の検証結果を得ることである。DSDL は，現時点では設計も仕様
策定も行われていない検証技術も許容するように設計されている。
注記 現時点では，CREPDL スキーマを参照するための機構をもつスキーマ言語は存在しない。
レパートリの記述は，厳密である必要はない。厳密でない記述をするため，この規格は，核及び殻（そ
れらは下限及び上限を提供する。
）をそれぞれ提供する。
この規格の構成を，次に示す。箇条 5 は，レパートリの核及び殻を導入する。箇条 6 は，CREPDL スキ
ーマの構文を規定する。箇条 7 は，正しい CREPDL スキーマの意味を規定する。すなわち，CREPDL スキ
ーマによって記述されたレパートリに文字が含まれるのはどんな場合かを規定する。箇条 8 は，CREPDL
プロセサ及びそれらの振る舞いを定義する。箇条 9 は，CREPDL プロセッサの適合性を定義する。最後に、
附録 A は，CREPDL の使用例を提供する。
1
適用範囲
この規格は、Character Repertoire Description Language (CREPDL)を規定する。CREPDL スキーマは，文字
レパートリを記述する。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 19757-7:200X，Document Schema Definition Languages (DSDL)-Part 7:Character Repertoire
Description Language(CREPDL) (IDT)
なお，対応の程度を表す記号(IDT)は，ISO/IEC Guide 21 に基づき，一致していることを示す。
2
X 4177-7：0000 (ISO/IEC 19757-7：2007)
2
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格のうちで，西暦年を付記してあるものは，記載の年の版を適用し，その後の改正版（追補を含む。
）
には適用しない。西暦年の付記がない引用規格は，その最新版（追補を含む。）を適用する。
注記 次の文書のそれぞれには，本文中で参照するための一意の識別子が付与されている。一意の識
別子は，太字で示した名称とする。
JIS X 0221
注記
国際符号化文字集合(UCS)
対応国際規格：ISO/IEC 10646
JIS X 4159
Universal multiple-octet coded Character Set(IDT)
拡張可能なマーク付け言語(XML)
注記 W3C 勧告，Extensible Markup Language (XML) 1.0 が，この規格に一致している。この W3C
勧告は http://www.w3.org/TR/REC-xml から入手可能である。
JIS X 4158
注記
XML 名前空間
W3C 勧 告 ， Namespaces in XML が ， こ の 規 格 に 一 致 し て い る 。 こ の W3C 勧 告 は
http://www.w3.org/TR/REC-xml-names から入手可能である。
JIS X 4177-2
注記
文書スキーマ定義言語（DSDL）第 2 部正規文法に基づく妥当性検証 - RELAX NG
対応国際規格：ISO/IEC 19757-2
Document Schema Definition Languages (DSDL) - Part 2:
Regular-grammar-based validation - RELAX NG(IDT)
W3C 勧告 XML Schema Part 2
XML Schema Part 2: Datatypes (Second Edition), 2004 年 10 月 28 日
注記 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/から入手可能である。
IETF RFC 3986
Uniform Resource Identifiers (URI): Generic Syntax, Internet Standards Track Specification,
2005 年 1 月
注記 http://www.ietf.org/rfc/rfc3986.txt から入手可能である。
IETF RFC 3987
Internationalized Resource Identifiers (IRIs), Internet Standards Track Specification, 2005
年1月
注記 http://www.ietf.org/rfc/rfc3987.txt から入手可能である。
IANA Charsets
IANA CHARACTER SETS
注記 http://www.iana.org/assignments/character-sets から入手可能である。
Unicode
The Unicode Standard, The Unicode Consortium
注記 http://www.unicode.org/入手可能である。
CLDR
Unicode Common Locale Data Repository, The Unicode Consortium,
注記 http://www.unicode.org/cldr/から入手可能である。
以下、項目番号のみとし、規定文は省略した。
―――――――――――――――――――――
3
用語及び定義
4
表記法
5
レパートリ，核及び殻
6
構文
3
X 4177-7：0000 (ISO/IEC 19757-7：2007)
6.1
一般
6.2
RELAX NG スキーマ
6.3
NVDL スクリプト
6.4
文字クラス
7
意味
7.1
一般
7.2
char
7.3
union
7.4
intersection
7.5
difference
7.6
ref
7.7
repertoire
8
検証
9
適合性
附属書 A
A.1
ISO 8859-6
A.2
ISO 8859-15
A.3
学年別漢字配当表の第 1 学年に配当されている漢字
A.4
学年別漢字配当表の第 2 学年に配当されている漢字
参考文献
〔附属資料 WG2-3〕
フォーマット化特性（Formatting Property)における XSL と CSS との違い
1 一般的なアクセス性特性
特性
source-document
XSL1.1
CSS2
この特性は，“Source”の Dublin Core 定義に従って，このフォーマット化オブジェクト木の生成に使用される元の XML 文書に戻るポインタを提供する。
<uri-specification> [<uri-specification>]* | none | inherit
role
--該当ナシ--
XSLT 木構築中に識別が可能な場合には，この特性は，XML 要素又はこのフォーマット化オブジェクトの構築に使用された要素の役割に関して，聴覚読上げ器など，代替レ
ンダラにヒントを提供する。
<string> | <uri-specification> | none | inherit
--該当ナシ--
2 一般的な絶対位置決め特性
特性
XSL1.1
CSS2
absolute-position
値が“absolute”又は“fixed”の場合は，このフォーマット化オブジェクトによって生成される任意の正規領域は，それぞれ xsl-absolute 又は xsl-fixed に変更された領域クラスを
もつ。
auto | absolute | fixed | inherit
position
--該当ナシ--
CSS 定義に対する XSL の変更点： XSL は CSS 特性を簡略記述特性として扱う。その対応付けを次に示す。
static relative-position="static" absolute-position="auto"
relative relative-position="relative" absolute-position="auto"
absolute relative-position="static" absolute-position="absolute"
fixed relative-position="static" absolute-position="fixed"
static | relative | absolute | fixed | inherit
top
static | absolute | relative | fixed | inherit
この特性は，マージンの上辺が，ボックスの包含ブロックの上辺からどの程度下にずれているかを指定する。
CSS 定義に対するXSL の変更点：left，right，top 及びbottom は，（直近の先祖の参照領域によって確立される）一般の座標系に変換されCSS におけるように，“包含ブロッ
ク”に関係しない。
<length> | <percentage> | auto | inherit
right
<length> | <percentage> | auto | inherit
この特性は，ボックスのマージンの右辺がボックスの包含ブロックの右辺からどの程度左にずれているかを指定する。
CSS 定義に対するXSL の変更点：left，right，top 及びbottom は，（直近の先祖の参照領域によって確立される）一般の座標系に変換されCSS におけるように，“包含ブロッ
ク”に関係しない。
<length> | <percentage> | auto | inherit
bottom
<length> | <percentage> | auto | inherit
この特性は，ボックスのマージンの下辺がボックスの包含ブロックの下辺からどの程度上にずれているかを指定する。
CSS 定義に対するXSL の変更点：left，right，top 及びbottom は，（直近の先祖の参照領域によって確立される）一般の座標系に変換されCSS におけるように，“包含ブロッ
ク”に関係しない。
<length> | <percentage> | auto | inherit
left
<length> | <percentage> | auto | inherit
この特性は，ボックスのマージンの左辺がボックスの包含ブロックの左辺からどの程度右にずれているかを指定する。
CSS 定義に対するXSL の変更点：left，right，top 及びbottom は，（直近の先祖の参照領域によって確立される）一般の座標系に変換されCSS におけるように，“包含ブロッ
1
特性
XSL1.1
CSS2
ク”に関係しない。
<length> | <percentage> | auto | inherit
<length> | <percentage> | auto | inherit
特性
XSL1.1
CSS2
background-attachment
背景画像が指定される場合，この特性は，背景画像が表示域に関して固定されるか（fixed），文書と共にスクロールされるのか（scroll）を指定する。
CSS 定義に対する XSL の変更点：CSS 記述の最後の段落は適用されない。
3 一般的な聴覚特性
省略
4 一般的な境界，パディング及び背景特性
scroll | fixed | inherit
background-color
scroll | fixed | inherit
この特性は，要素の背景の色を， 値，又は背景にある色を透けて見せるためのキーワード transparent のいずれかに設定する。
CSS 定義に対する XSL の変更点：XSL は“rgb-icc”関数（5.10.2 色の関数を参照）をこの特性の有効値として追加している。
<color> | transparent | inherit
background-image
<color> | transparent | inherit
この特性は，要素の背景画像を設定する。
CSS 定義に対する XSL の変更点：<uri> 値は <uri-specification> に変更されている。
<uri-specification> | none | inherit
background-repeat
<uri> | none | inherit
背景画像が指定される場合，この特性は，画像が繰り返される（タイル状に敷き詰められる）かどうかを指定し，どのように繰り返されるかを指定する。ボックスの内容領域及
びパディング領域はすべてタイル状に覆われる。
CSS 定義に対する XSL の変更点：“水平”及び“垂直”は，参照方位に関連して定義される。“水平”とは“左”から“右”に向かう方向であり，“垂直”とは“上”から“下”に向かう
方向をいう。
repeat | repeat-x | repeat-y | no-repeat | inherit
background-position-horizontal
repeat | repeat-x | repeat-y | no-repeat | inherit
“background-image”が指定されている場合，この特性は，その初期位置を水平方向に指定する。
CSS 定義に対する XSL の変更点：“left”及び“right”は，参照方位に関連して定義される。
<percentage> | <length> | left | center | right | inherit
background-position-vertical
--該当ナシ--
“background-image”が指定されている場合，この特性は，その初期位置を垂直方向に指定する。
CSS 定義に対する XSL の変更点：“top”及び“bottom”は，参照方位に関連して定義される。
<percentage> | <length> | top | center | bottom | inherit
border-before-color
--該当ナシ--
ブロック領域又は行内領域の前辺の境界の色を指定する。
<color> | inherit
border-before-style
--該当ナシ--
前辺の境界スタイルを指定する。
<border-style> | inherit
border-before-width
--該当ナシ--
前辺の境界幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
2
特性
XSL1.1
CSS2
<length-conditional>前辺の境界の幅及び任意の条件を指定する複合値。
<border-width> | <length-conditional> | inherit
border-after-color
--該当ナシ--
ブロック領域又は行内領域の後辺の境界の色を指定する。
<color> | inherit
border-after-style
--該当ナシ--
後辺の境界スタイルを指定する。
<border-style> | inherit
border-after-width
--該当ナシ--
後辺の境界幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<length-conditional>後辺の境界の幅及び任意の条件付けを指定する複合値。
<border-width> | <length-conditional> | inherit
border-start-color
--該当ナシ--
ブロック領域又は行内領域の開始辺の境界の色を指定する。
<color> | inherit
border-start-style
--該当ナシ--
開始辺の境界スタイルを指定する。
<border-style> | inherit
border-start-width
--該当ナシ--
開始辺の境界幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<length-conditional>開始辺の境界の幅及び任意の条件付けを指定する複合値。
<border-width> | <length-conditional> | inherit
border-end-color
--該当ナシ--
ブロック領域又は行内領域の終了辺の境界の色を指定する。
<color> | inherit
border-end-style
--該当ナシ--
終了辺の境界スタイルを指定する。
<border-style> | inherit
border-end-width
--該当ナシ--
終了辺の境界幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<length-conditional>終了辺の境界の幅及び任意の条件付けを指定する複合値。
<border-width> | <length-conditional> | inherit
border-top-color
--該当ナシ--
上辺の境界の色を指定する。
<color> | inherit
border-top-style
<color> | inherit
上辺の境界スタイルを指定する。
<border-style> | inherit
border-top-width
<border-style> | inherit
上辺の境界幅を指定する。
<border-width> | inherit
border-bottom-color
<border-width> | inherit
下辺の境界の色を指定する。
<color> | inherit
<color> | inherit
3
特性
border-bottom-style
XSL1.1
CSS2
下辺の境界スタイルを指定する。
<border-style> | inherit
border-bottom-width
<border-style> | inherit
下辺の境界幅を指定する。
<border-width> | inherit
border-left-color
<border-width> | inherit
左辺の境界の色を指定する。
<color> | inherit
border-left-style
<color> | inherit
左辺の境界スタイルを指定する。
<border-style> | inherit
border-left-width
<border-style> | inherit
左辺の境界幅を指定する。
<border-width> | inherit
border-right-color
<border-width> | inherit
右辺の境界色を指定する。
<color> | inherit
border-right-style
<color> | inherit
右辺の境界スタイルを指定する。
<border-style> | inherit
padding-before
<border-style> | inherit
ブロック領域又は行内領域の前辺のパディング幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<length-conditional>前辺のパディングの幅及び任意の条件付けを指定する複合値。
<padding-width> | <length-conditional> | inherit
padding-after
--該当ナシ--
ブロック領域又は行内領域の後辺のパディング幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<length-conditional>後辺のパディングの幅及び任意の条件付けを指定する複合値。
<padding-width> | <length-conditional> | inherit
padding-start
--該当ナシ--
ブロック領域又は行内領域の開始辺のパディング幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<length-conditional>開始辺のパディングの幅及び任意の条件付けを指定する複合値。
<padding-width> | <length-conditional> | inherit
padding-end
--該当ナシ--
ブロック領域又は行内領域の終了辺のパディングの幅を指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<length-conditional>終了辺のパディングの幅及び任意の条件付けを指定する複合値。
<padding-width> | <length-conditional> | inherit
padding-top
--該当ナシ--
ブロック領域又は行内領域の上辺のパディング幅を指定する。
<padding-width>| inherit
padding-bottom
<padding-width>| inherit
ブロック領域又は行内領域の下辺のパディング幅を指定する。
<padding-width>| inherit
padding-left
<padding-width>| inherit
ブロック領域又は行内領域の左辺のパディング幅を指定する。
4
特性
padding-right
XSL1.1
CSS2
<padding-width> | inherit
<padding-width>| inherit
ブロック領域又は行内領域の右辺のパディング幅を指定する。
<padding-width> | inherit
<padding-width>| inherit
特性
XSL1.1
CSS2
font-family
この特性は，フォントファミリ名及び／又は汎用ファミリ名の優先リストを指定する。
CSS 定義に対する XSL の変更点： <string>名前は，構文上，文字列として表わされる。
5 一般的なフォント特性
[[ <family-name> | <generic-family>],]* [<family-name> | <generic-family>] | inherit
[[ <family-name> | <generic-family>],]* [<family-name> | <generic-family>] | inherit
font-selection-strategy
auto | character-by-character | inherit
font-size
--該当ナシ--
この特性は，ベタの場合のフォントのサイズを記述する。
CSS 定義に対する XSL の変更点：XSL は，特性定義の一部として，CSS2 15.5（http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm）から次のテキストを取り入れている。
'font-size'は，利用者エージェント依存の許容マージン内でマッチしなければならない。通常，変倍可能なフォントのサイズは，最も近似する整数の画素に丸められるが，ビッ
トマップフォントの場合は，20% までが許容範囲である。他の特性で“em”値などによる計算を更に続ける場合は，“font-size”の指定値ではなく，使用される値に基づく。
<absolute-size> | <relative-size> | <length> | <percentage$gt; | inherit
<absolute-size> | <relative-size> | <length> | <percentage$gt; | inherit
“font-stretch”特性は，フォントファミリから，通常体，圧縮体，又は拡張体を選択する。
font-stretch
font-size-adjust
normal | wider | narrower | ultra-condensed | extra-condensed | condensed |
semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | inherit
この特性によって，文書作成者は，代替フォントで最初に選択したフォントの x-height を維持する要素にアスペクト値を指定することができる。
<number> | none | inherit
font-style
<number> | none | inherit
“font-style”特性は，フォントファミリ内の通常体（“roman”又は“upright”として参照されることもある），イタリック体，及び斜体を要求する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
backslant 利用者エージェントのフォントデータベースで“backslant”として分類されたフォントを指定する。
normal | italic | oblique | backslant | inherit
font-variant
normal | italic | oblique | inherit
この特性によって，テキストが大文字に変換される限り，“text-transform”を適用することによって同じ効果が得られる。
CSS 定義に対する XSL の変更点：XSL では，特性定義の一部として，CSS2 15.5（http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm）から次のテキストを取り入れてい
る。
“normal”は“small-caps”として分類されないフォントにマッチする。すなわち，“small-caps”は，“small-caps”として分類されるフォント，スモールキャップが合成されるフォン
ト，又はすべての小文字が大文字に置換されるフォントにマッチする。通常フォントの大文字を電子的に変倍して，スモールキャップフォントを合成してもよい。
normal | small-caps | inherit
font-weight
normal | wider | narrower | ultra-condensed | extra-condensed | condensed |
semi-condensed | semi-expanded | expanded | extra-expanded | ultra-expanded | inherit
normal | small-caps | inherit
“font-weight”特性はフォントのウェイトを指定する。
CSS 定義に対する XSL の変更点：XSL には，特性定義の一部として，CSS2 15.5.1（http://www.w3.org/TR/REC-CSS2/fonts.html#q46）から次のテキストを取り入れている。
ファミリ内の他のウェイトと数字で示されたウェイトの値との関係は，ウェイトの順序付けをそのファミリ内に保持することだけを目的としている。利用者エージェントは，視覚
的な順序を保持する方法で，名前と値を対応付けなければならない。すなわち，ある値に対応付けられた書体は，それより小さい値に対応付けられた書体より太くなければ
ならない。利用者エージェントがファミリ内のフォントとウェイトの値とをどのように対応付けるかについての保証はない。しかし，典型的な手法を次に示す。フォントファミリが
5
特性
XSL1.1
CSS2
既に九つの値でウェイトを分類している場合（例えば，OpenType などはそうしている），フォントのウェイトは直接対応付けられることが望ましい。
“Medium”に分類された書体も“Book”，“Regular”，“Roman”又は“Normal”に分類された書体も存在する場合は，通常，“Medium”は“500”に割り当てられる。
“Bold”に分類されたフォントはウェイトの値“700”に対応することが多い。
ファミリに存在するウェイトの数が九つよりも少ない場合，“空き”を埋めるデフォルトアルゴリズムは次である。“500”が割り当てられない場合，“400”と同じフォントを割り当
てられる。“600”，“700”， “800”，又は“900”の値がいずれも割り当てられないままである場合は，次に太い割り当てキーワードと同じ書体に割り当てられるが，そうでない場
合は，次に細い書体を割り当てる。“300”，“200”，又は “100”のいずれも割り当てられないままである場合は，次に細い割当てキーワードに割り当てられる。そうでない場合
は，次に太いものが割り当てられる。
“font-weight”の各値について，より太い書体が存在するという保証はない。例えば，通常の書体及び太字の書体しかないフォントもあれば，異なる書体のウェイトが八つあ
るフォントもある。
normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | inherit
normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | inherit
6 一般的なハイフン付け特性
特性
country
XSL1.1
CSS2
両端揃え方策，行分割及びハイフン付けなど，言語結合サービス／ロケール結合サービスで，フォーマッタが使用する国名を指定する。
none | <country> | inherit
language
--該当ナシ--
両端揃え方策，行分割及びハイフン付けなど，言語結合サービス／ロケール結合サービスで，フォーマッタが使用する言語を指定する。
none | <language> | inherit
script
--該当ナシ--
両端揃え方策，行分割及びハイフン付けなど，言語結合サービス／ロケール結合サービスで，フォーマッタが使用するスクリプトを指定する。
none | auto | <script> | inherit
hyphenate
--該当ナシ--
フォーマッタによるこのフォーマット化オブジェクトのフォーマット化の際に，行分割中にハイフン付けが使用できるかどうかを指定する。
false | true | inherit
hyphenation-character
--該当ナシ--
ハイフン付けによる分割が生じた場合に，表示される Unicode 文字を指定する。
<character> | inherit
hyphenation-push-character-count
--該当ナシ--
hyphenation-push-character-count の値は，ハイフン付け文字の後のハイフン付けされた単語内の最小数を指定する。
<number> | inherit
hyphenation-remain-character-count
--該当ナシ--
hyphenation-remain-character-count の値は，ハイフン付け文字の前のハイフン付けされた単語の最小値を指定する。
<number> | inherit
--該当ナシ--
7 一般的なマージン特性-ブロック
特性
XSL1.1
CSS2
margin-top
ボックスの上マージンを設定する。
CSS 定義に対する XSL の変更点：
・“margin-top”は CSS との互換性を目的として提供される。
・CSS の“margin”特性の XSL への対応付けの詳細については，5 特性の洗練化及び解決を参照。
6
特性
margin-bottom
XSL1.1
CSS2
<margin-width> | inherit
<margin-width> | inherit
ボックスの下マージンを設定する。
CSS 定義に対する XSL の変更点：
・“margin-bottom”は CSS との互換性を目的として提供される。
・CSS の“margin”特性の XSL への対応付けの詳細については，5 特性の洗練化及び解決を参照。
<margin-width> | inherit
margin-left
<margin-width> | inherit
ボックスの左マージンを設定する。
CSS 定義に対する XSL の変更点：
・“margin-left”は CSS との互換性を目的として提供される。
CSS の“margin”特性の XSL への対応付けの詳細については，5 特性の洗練化及び解決を参照。
<margin-width> | inherit
margin-right
<margin-width> | inherit
ボックスの右マージンを設定する。
CSS 定義に対する XSL の変更点：
・“margin-right”は CSS との互換性を目的として提供される。
・CSS の“margin”特性の XSL への対応付けの詳細については，5 特性の洗練化及び解決を参照。
<margin-width> | inherit
space-before
<margin-width> | inherit
このフォーマット化オブジェクトが生成する領域の前の間隔に間隔指定子の値を指定する。
<space> | inherit
space-after
--該当ナシ--
このフォーマット化オブジェクトが生成する領域の後の間隔に間隔指定子の値を指定する。
<space> | inherit
start-indent
--該当ナシ--
このフォーマット化オブジェクトが生成する各ブロック領域に対して，包含する参照領域の内容長方形の開始辺から，そのブロック領域の内容長方形の開始辺までの距離を指
定する。
<length> | <percentage> | inherit
end-indent
--該当ナシ--
このフォーマット化オブジェクトが生成する各ブロック領域に対して，包含する参照領域の内容長方形の終了辺から，そのブロック領域の内容長方形の終了辺までの距離を指
定する。
<length> | <percentage> | inherit
--該当ナシ--
8 一般的なマージン特性-行内
特性
space-end
XSL1.1
CSS2
このフォーマット化オブジェクトが生成する任意の領域の後の間隔に最小値，最適値及び最大値を指定し，更にこの間隔の条件付け及び優先順位も指定する。
<space> | <percentage> | inherit
space-start
--該当ナシ--
このフォーマット化オブジェクトが生成する任意の領域の前の間隔に最小値，最適値及び最大値を指定し，更にこの間隔の条件付け及び優先順位も指定する。
<space> | <percentage> | inherit
--該当ナシ--
V1.1 仕様書では次の 4 つの特性が追加されています。
margin-top
7 一般的なマージン特性の margin-top を参照
7
特性
XSL1.1
CSS2
7 一般的なマージン特性の margin-bottom を参照
margin-bottom
7 一般的なマージン特性の margin-left を参照
margin-left
7 一般的なマージン特性の margin-right を参照
margin-right
9 一般的な相対位置決め特性
特性
XSL1.1
CSS2
relative-position
static | relative | inherit
--該当ナシ--
V1.1 で次の 4 つの特性が追加になりました。
top
right
bottom
left
2 一般的な絶対位置決め特性の top を参照
2 一般的な絶対位置決め特性の right を参照
2 一般的な絶対位置決め特性の bottom を参照
2 一般的な絶対位置決め特性の left を参照
10 領域配置特性
特性
XSL1.1
CSS2
“alignment-adjust”特性を使用することによって，フォーマット化オブジェクトが生成する領域をより正確に配置することができる。
alignment-adjust
auto | baseline | before-edge | text-before-edge | middle | central | after-edge |
text-after-edge | ideographic | alphabetic | hanging | mathematical | <percentage> | <length>
| inherit
--該当ナシ--
この特性は，オブジェクトがその親に関連してどのように配置されかを指定する。
alignment-baseline
baseline-shift
auto | baseline | before-edge | text-before-edge | middle | central | after-edge |
text-after-edge | ideographic | alphabetic | hanging | mathematical | inherit
--該当ナシ--
“baseline-shift”特性の使用によって，親領域の主要ベースラインに関連して，主要ベースラインの位置を変更することができる。
8
特性
XSL1.1
CSS2
baseline | sub | super | <percentage> | <length> | inherit
display-align
--該当ナシ--
この特性は，ブロック進行方向で，参照領域の子供である領域の配置を指定する。
auto | before | center | after | inherit
--該当ナシ--
“dominant-baseline”特性は，スケールベースライン表の決定又は再決定に使用される。
dominant-baseline
relative-align
auto | use-script | no-change | reset-size | ideographic | alphabetic | hanging | mathematical
| central | middle | text-after-edge | text-before-edge | inherit
--該当ナシ--
この特性は，ブロック進行方向において，二つ以上の領域間の配置を指定する。
before | baseline | inherit
--該当ナシ--
11 領域寸法特性
特性
block-progression-dimension
XSL1.1
CSS2
この特性は，このフォーマット化オブジェクトが生成する各領域に，内容長方形のブロック進行寸法を指定する。
auto | <length> | <percentage> | <length-range> | inherit
content-height
--該当ナシ--
外部図形などのオブジェクトの内容高さを指定する。
auto | scale-to-fit | scale-down-to-fit | scale-up-to-fit | <length> | <percentage> | inherit
content-width
--該当ナシ--
外部図形などのオブジェクトの内容幅を指定する。
auto | scale-to-fit | scale-down-to-fit | scale-up-to-fit | <length> | <percentage> | inherit
height
<length> | <percentage> | auto | inherit
inline-progression-dimension
<length> | <percentage> | auto | inherit
この特性は，このフォーマット化オブジェクトが生成する各領域に，内容長方形の行内進行寸法を指定する。
auto | <length> | <percentage> | <length-range> | inherit
max-height
--該当ナシ--
これら二つの特性，“max-height”及び“min-height”によって，文書作成者は，ボックスの高さを一定の範囲に制限することができる。
CSS 定義に対する XSL の変更点：XSL では，この特性は“行内進行寸法”又は“ブロック進行寸法”のいずれかに対応し，適用可能な “writing-mode”特性及び“参照方位”特
性の値を基本とする。
<length> | <percentage> | none | inherit
max-width
<length> | <percentage> | none | inherit
これら二つの特性，“max-width”及び“min-width”によって，文書作成者は，ボックスの幅を一定の範囲に制限することができる。
CSS 定義に対する XSL の変更点：XSL では，この特性は“行内進行寸法”又は“ブロック進行寸法”のいずれかに対応し，適用可能な “writing-mode”特性及び“参照方位”特
性の値を基本とする。
<length> | <percentage> | none | inherit
min-height
--該当ナシ--
この特性は，ブロックレベル要素及び置換された要素が生成するボックスの内容の高さを指定する。
CSS 定義に対する XSL の変更点：XSL では，この特性は“行内進行寸法”又は“ブロック進行寸法”のいずれかに対応し，適用可能な“writing-mode”特性及び“参照方位”特
性の値を基本とする。
<length> | <percentage> | none | inherit
これら二つの特性，“max-height”及び“min-height”によって，文書作成者は，ボックスの高さを一定の範囲に制限することができる。
CSS 定義に対する XSL の変更点：XSL では，この特性は“行内進行寸法”又は“ブロック進行寸法”のいずれかに対応し，適用可能な“writing-mode”特性及び“参照方位”特
性の値を基本とする。
9
特性
min-width
XSL1.1
CSS2
<length> | <percentage> | inherit
<length> | <percentage> | inherit
これら二つの特性，“max-width”及び“min-width”によって，文書作成者は，ボックスの幅を一定の範囲に制限することができる。
CSS 定義に対する XSL の変更点：XSL では，この特性は“行内進行寸法”又は“ブロック進行寸法”のいずれかに対応し，適用可能な “writing-mode”特性及び“参照方位”特
性の値を基本とする。
<length> | <percentage> | inherit
scaling
<length> | <percentage> | inherit
変倍が基本のアスペクト比を保持する必要があるかどうかを指定する。
uniform | non-uniform | inherit
scaling-method
--該当ナシ--
この特性を使用すると，ビットマップ図形をフォーマット化する際に使用されるトレードオフの変倍/ サイズ変更における優先度を示すことができる。
auto | integer-pixels | resample-any-method | inherit
width
--該当ナシ--
この特性は，ブロックレベル要素及び置換される要素が生成するボックスの内容幅を指定する。
CSS 定義に対する XSL の変更点：XSL では，この特性は“行内進行寸法”又は“ブロック進行寸法”のいずれかに対応し，適用可能な“writing-mode”特性及び“参照方位”特
性の値を基本とする。
<length> | <percentage> | auto | inherit
<length> | <percentage> | auto | inherit
V1.1 では、新しく、次の 2 項目が追加になりました。
allowed-height-scale
一連のトークンであり，それぞれ許可された倍率値を特定する。
[ any | <percentage> ]* | inherit
allowed-width-scale
--該当ナシ--
一連のトークンであり，それぞれ許可された変倍率の値を特定する。
[ any | <percentage> ]* | inherit
--該当ナシ--
12 ブロック及び行関連特性
特性
hyphenation-keep
XSL1.1
CSS2
ハイフン付けが所定の参照領域内の適合する最後の行で実行可能かどうかを制御する。
auto | column | page | inherit
hyphenation-ladder-count
--該当ナシ--
フォーマッタがブロック領域内に生成する連続したハイフン付け行領域の数を制限する。
no-limit | <number> | inherit
last-line-end-indent
--該当ナシ--
フォーマット化オブジェクトが生成し，返す最後のブロック領域の最後の行領域の子に適用される字下げ，及びフォーマット化オブジェクトの次にくる兄弟が行領域ではないブ
ロック領域である場合に，そのフォーマット化オブジェクトが生成又は返す任意の行領域に適用する字下げを指定する。
<length> | <percentage> | inherit
line-height
--該当ナシ--
CSS 定義に対する XSL の変更点：XSL では，“line-height”特性は半リーディング特色を決定する際に使用される。
normal | <length> | <number> | <percentage> | <space> | inherit
line-height-shift-adjustment
normal | <length> | <number> | <percentage> | inherit
この特性を使用すると，行の高さをベースライン移動をもつ内容に対して調整するかどうかを制御することができる。
consider-shifts | disregard-shifts | inherit
line-stacking-strategy
--該当ナシ--
隣接する行を互いに関連して位置決めするための方策を選択する。
10
特性
XSL1.1
CSS2
line-height | font-height | max-height | inherit
linefeed-treatment
--該当ナシ--
“linefeed-treatment”特性は，洗練化の過程における行送りの取扱い，すなわち，Unicode 符号位置が U +000A である文字流し込みオブジェクトを指定する。
ignore | preserve | treat-as-space | treat-as-zero-width-space | inherit
--該当ナシ--
“white-space-treatment”特性は，行送りを除く文字流し込みオブジェクトの洗練化の過程において，XML の空白として分類される取扱いを指定する。
white-space-treatment
text-align
ignore | preserve | ignore-if-before-linefeed | ignore-if-after-linefeed |
ignore-ifsurrounding-linefeed | inherit
この特性は，ブロックの行内内容がどのように配置されるかを記述する。
CSS 定義に対する XSL の変更点： 特性の値の意味を次に示す。
start： 内容が行内進行方向で開始辺に配置されることを指定する。
center： 内容が行内進行方向で中央寄せされることを指定する。
end： 内容が行内進行方向で終了辺に配置されることを指定する。
justify： 内容が行内進行方向で利用可能な幅を満たすまで拡張されることを指定する。
inside： ページの綴じ代が開始辺上にある場合，配置は“start”となる。綴じ代が終了辺上にある場合，配置は“end”となる。いずれでもない場合は，配置には“start”を使用す
る。
outside： ページの綴じ代が開始辺上にある場合，配置は“end”となる。綴じ代が終了辺上にある場合，配置は“start”となる。いずれでもない場合は，配置には“end”を使用す
る。
left： text-align="start" として解釈される。
right： text-align="end" として解釈される。
<string>： 表列のセルを配置するための文字列を指定する。CSS2 勧告における列の水平レイアウトの箇条の詳細及び例を参照。この値は，フォーマット化オブジェクトが表
セルの子孫である場合に限り適用される。他のフォーマット化オブジェクトに設定する場合は，“start”として扱われることになる。
start | center | end | justify | inside | outside | left | right | <string> | inherit
text-align-last
--該当ナシ--
center | justify | left | right | <string> | inherit
フォーマット化オブジェクトが生成し，返す最後のブロック領域の最後の行領域の子の配置，後続する兄弟が行領域ではないブロック領域であるフォーマット化オブジェクトが
生成又は返す任意の行領域の配置，及び最後に U+000A をもつすべての行の配置を指定する。
relative | start | center | end | justify | inside | outside | left | right | inherit
text-indent
この特性は，ブロック内のテキストの最初の行の字下げを指定する。
CSS 定義に対する XSL の変更点：“text-indent”特性は，フォーマット化オブジェクトが生成又は返す最初のブロック領域の最初の子 L が行領域である場合は，L の開始字
下げに対する調整を指定する。
<length> | <percentage> | inherit
white-space-collapse
--該当ナシ--
<length> | <percentage> | inherit
“white-space-collaspe”特性は，領域木を構築する過程での連続する空白の取扱いを指定する。
false | true | inherit
wrap-option
--該当ナシ--
フォーマット化オブジェクトの内容の行ラッピング（行分割）の取扱い方法を指定する。
no-wrap | wrap | inherit
--該当ナシ--
13 文字特性
特性
character
XSL1.1
CSS2
表示される Unicode 文字の符号位置を指定する。
<character>
--該当ナシ--
11
特性
letter-spacing
XSL1.1
CSS2
この特性は，テキストの文字間における間隔の振舞いを指定する。
CSS 定義に対する XSL の変更点：XSL に追加されている値の型を次に示す。
<space>：この値を使用することによって，利用者は，文字間のデフォルト間隔の他に，調整の範囲を指定することができる。
最小値及び最大値は，調整の限界を指定する。
normal | <length> | <space> | inherit
suppress-at-line-break
normal | <length> inherit
この特性は fo:character のみに適用され，フォーマッタが生成する行分割に隣接して文字が現れた場合に，文字の表現が抑制されるかどうかを決定する。
auto | suppress | retain | inherit
text-decoration
--該当ナシ--
この特性は，要素のテキストに付加される装飾を記述する。
CSS 定義に対する XSL の変更点：XSL においては，“underline”値の指定は次のように拡張される。下線の配置は，“inline-progressiondirection”が水平又は垂直に方向付け
されているか，及び“language”特性に依存する。水平のテキストに対しては，下線はテキストの下側に位置する。垂直のテキストに対しては，位置は“language”特性の値によ
る。すなわち，下線は，下線を引くテキストの前端又は後端のいずれかの近くに配置される。
none | [ [ underline | no-underline] || [ overline | no-overline ] || [ line-through |
no-linethrough ] || [ blink | no-blink ] ] | inherit
text-shadow
none | [ underline || overline || line-through || blink ] | inherit
この特性は，要素のテキストに適用される影効果をカンマで区切ったリストで指定する。
CSS 定義に対する XSL の変更点： “text-shadow”特性は継承せず，レンダリング特色に変換される。このレンダリング特色は，表現効果が集合的にこの特性が指定される
フォーマット化オブジェクトの子によって返される領域群内のグリフイメージに適用される。すなわち，与えられた任意のグリフ領域に対して，グリフイメージ，印のある領域の
一部が背景を含まない，複製され，陰オフセット量によって移動し，（指定されていれば）色付けされ，ぼやけされ，背景が表現された後で且つグリフイメージ自身が表現され
る前に表現される。影は，影効果の部分に色指定がない場合は，グリフイメージ自身を色付けるために使われる色で，影効果の部分に色指定がある場合は，指定色で色付け
られる。一つ以上の影効果が指定された場合は，最後に指定された色が最初に表現され，先行する効果は，影効果のリストに指定されている逆順に表現される。
none | [<color> || <length> <length> <length>? ,]* [<color> || <length> <length> <length>?] |
inherit
text-transform
この特性は，要素のテキストの大文字化効果を制御する。
CSS 定義に対する XSL の変更点： この特性の使用については，難しい国際化問題が存在する。CSS の互換性については保持されているが， XSL でこの特性を使用す
ることは推奨しない。
capitalize | uppercase | lowercase | none | inherit
treat-as-word-space
none | [<color> || <length> <length> <length>? ,]* [<color> || <length> <length> <length>?] |
inherit
capitalize | uppercase | lowercase | none | inherit
この特性は，文字が単語間隔又は正規の文字として扱われるかどうかを決定する。
auto | true | false | inherit
word-spacing
--該当ナシ--
この特性は，単語間隔を指定する。特性の値の意味を次に示す。
normal | <length> | <space> | inherit
normal | <length> | inherit
14 色特性
特性
XSL1.1
color
この特性は，要素のテキスト内容の前景の色を記述する。
CSS 定義に対する XSL の変更点：XSL は，この特性の有効値として“rgb-icc”関数（5.10.2 色の関数を参照）を追加している。
CSS2
color-profile-name
内部参照のための色プロファイルの名前を指定する。
<color> | inherit
<color> | inherit
12
特性
XSL1.1
CSS2
<name> | inherit
rendering-intent
--該当ナシ--
“rendering-intent”特性によって，デフォルト以外の色プロファイルのレンダリング目的を規定することができる。
auto | perceptual | relative-colorimetric | saturation | absolute-colorimetric | inherit
--該当ナシ--
15 浮動体関連特性
特性
clear
XSL1.1
CSS2
この特性は，要素のボックスのどの側が先行して浮動するボックスに隣接しないかを示す。
CSS 定義に対する XSL の変更点： 開始浮動体は，領域クラスが“xsl-side-float”である領域が，“float”特性が“left”又は“start”として指定された fo:float によって生成された
ことを意味するものとして定義される。
終了浮動体は，領域クラスが“xsl-side-float”である領域が，“float”特性が“right”又は“end”として指定された fo:float によって生成されたことを意味するものとして定義される。
内側浮動体は，領域クラスが“xsl-side-float”である領域が，“float”特性が“inside”として指定された fo:float によって生成されたことを意味するものとして定義される。
外側浮動体は，領域クラスが“xsl-side-float”である領域が，“float”特性が“outside”として指定された fo:float によって生成されたことを意味するものとして定義される。
側浮動体は，開始浮動体又は終了浮動体のいずれかを意味するものとして定義される。
領域の境界長方形の前辺が浮動体の後辺の後に位置決めされている場合，又は，領域が側浮動体の親参照領域の子孫ではない場合，領域は側浮動体を“clear”として定義
される。
フォーマット化オブジェクトが生成する領域が側浮動体を取り除く場合に，ブロックレベルフォーマット化オブジェクトは側浮動体を“to clear”として定義される。
XSL では，この特性はブロックレベルフォーマット化オブジェクト及び fo:float に適用される。
側浮動体を生成する fo:float に適用される場合，clear 特性は fo:float のアンカ領域には適用されない。
start | end | left | right | inside | outside | both | none | inherit
float
left | right | both | none | inherit
この特性は，ボックスが左に浮動するのがよいか，右に浮動するのがよいか，又は全く浮動しないのがよいかを指定する。
CSS 定義に対する XSL の変更点： XSL では，“before”，“start”，及び“end”の値が追加されている。
XSL では，この特性を fo:float にのみ適用する。
before | start | end | left | right | inside | outside | none | inherit
intrusion-displace
left | right | none | inherit
この特性は，詰めが存在する場合の位置ずれの方法を決定する。
auto | none | line | indent | block | inherit
--該当ナシ--
16 保持及び区切り特性
特性
XSL1.1
CSS2
break-after
次のフォーマット化オブジェクトをフォーマットすることによって生成される最初の正規領域がある場合には，それは，ページ領域，段領域などの特定の文脈に配置された最
初の領域となることを指定する。
auto | column | page | even-page | odd-page | inherit
break-before
--該当ナシ--
このフォーマット化オブジェクトをフォーマットすることによって生成される最初の領域が，ページ領域，段領域など，特定の文脈に配置される最初の領域であることを指定す
る。
auto | column | page | even-page | odd-page | inherit
keep-together
--該当ナシ--
この特性は，フォーマット化オブジェクトに“keep-together”条件を強制する。
13
特性
XSL1.1
CSS2
<keep> | inherit
keep-with-next
--該当ナシ--
この特性は，フォーマット化オブジェクトに“keep-with-next”条件を強制する。
<keep> | inherit
keep-with-previous
--該当ナシ--
この特性は，フォーマット化オブジェクトに“keep-with-previous”条件を強制する。
<keep> | inherit
orphans
--該当ナシ--
“orphans”特性は，ページの下部に残さなければならない段落の最小行数を指定する。
CSS 定義に対する XSL の変更点： XSL では，“orphans”特性は，フォーマット化オブジェクトが生成する最初の領域内にある行領域の最小数を指定する。
<integer> | inherit
widows
<integer> | inherit
“widows”特性は，ページの上部に残さなければならない段落の最小行数を指定する。
CSS 定義に対する XSL の変更点： XSL では，“widows”特性は，フォーマット化オブジェクトが生成する最後の領域内にある行領域の最小数を指定する。
<integer> | inherit
<integer> | inherit
17 レイアウト関連特性
特性
clip
XSL1.1
CSS2
“clip”特性は，“overflow”特性の値が“visible”以外である要素に適用される。
<shape> | auto | inherit
overflow
<shape> | auto | inherit
この特性は，内容の包含ブロックとして動作している要素のボックスがオーバフローする場合に，ブロックレベル要素の内容が切り取られるかどうかを指定する。
CSS 定義に対する XSL の変更点： 次の二つの値が定義されている。error-if-overflow / repeat
visible | hidden | scroll | error-if-overflow | repeat | auto | inherit
reference-orientation
visible | hidden | scroll | auto | inherit
領域の“参照方位”特色は，フォーマット化オブジェクトの“参照方位”特性から間接的に派生する。
0 | 90 | 180 | 270 | -90 | -180 | -270 | inherit
span
--該当ナシ--
この特性は，ブロックレベルオブジェクトが現在の段に配置されるのが望ましいか，又は複数段の区画のすべての段にまたがるのが望ましいかを指定する。
none | all | inherit
--該当ナシ--
18 リーダ及び罫線特性
特性
leader-alignment
XSL1.1
CSS2
内容及び特性値が同じである複数の fo:leader に，共通する参照領域又はページに関連して，互いに配置されるパタンが存在するかどうかを指定する。
none | reference-area | page | inherit
leader-pattern
--該当ナシ--
リーダがどのように埋まるかの規定を提供する。
space | rule | dots | use-content | inherit
leader-pattern-width
--該当ナシ--
繰返しリーダ内の各繰返し周期の長さを指定する。
use-font-metrics | <length> | <percentage> | inherit
--該当ナシ--
14
特性
leader-length
XSL1.1
CSS2
この特性は，fo:leader の最小，最適及び最大の長さを指定する。
<length-range> | <percentage> | inherit
rule-style
--該当ナシ--
けい（罫）線のスタイル（パタン）を指定する。
none | dotted | dashed | solid | double | groove | ridge | inherit
rule-thickness
--該当ナシ--
包括的なけい（罫）線の太さを指定する。
<length>
--該当ナシ--
19 動的な効果があるフォーマット化オブジェクトに関する特性
特性
XSL1.1
CSS2
active-state
“active-state”特性を使用すると，fo:multi-property-sets のうちのどれを fo:multi-properties フォーマット化オブジェクト内の子流し込みオブジェクトのフォーマットに使用するか
を制御できる。
link | visited | active | hover | focus
auto-restore
--該当ナシ--
fo:multi-switch が先祖の fo:multi-switch によって隠蔽される場合に，初期のの fo:multi-case を復元するのが望ましいかどうかを指定する。
true | false
case-name
--該当ナシ--
この特性は，fo:multi-toggle オブジェクトの切換えのために fo:multi-case オブジェクトを選択できることを目的としている。
--該当ナシ--
case-title
fo:multi-case に説明タイトルを指定する。
<string>
destination-placement-offset
--該当ナシ--
“destination-placement-offset”特性は，ページの冒頭から，最初の宛先領域を包含する最も内部の行領域までの距離を指定する。
--該当ナシ--
external-destination
fo:basic-link に宛先資源を指定する。素辺識別子が設定されている場合は下位資源を指定する
empty string | <uri-specification>
indicate-destination
--該当ナシ--
昇順又は降順たどりの際，リンクターゲットに属する領域は，機構依存の方法で，指示される
true | false
internal-destination
--該当ナシ--
fo:basic-link の宛先流し込みオブジェクトを指定する。
empty string | <idref>
show-destination
--該当ナシ--
宛先資源がどこで表示されるのが望ましいかを指定する。
replace | new
starting-state
--該当ナシ--
適用されるフォーマット化オブジェクトが最初にどのように表示されるかを指定する。
show | hide
switch-to
--該当ナシ--
この fo:multi-toggle がどの fo:multi-case オブジェクトに切り換えるかを指定する。
xsl-preceding | xsl-following | xsl-any | <name>[ <name>]*
--該当ナシ--
15
特性
target-presentation-context
XSL1.1
CSS2
“external-destination”特性の値が空の文字列である場合，又は，外部宛先が制限表示文脈が意味をなす処理構造化メディア型ではない場合は，この特性は無視される
use-target-processing-context | <uri-specification>
target-processing-context
--該当ナシ--
“external-destination”特性の値が空の文字列である場合，又は，外部宛先が処理構造化メディア型ではない場合は，この特性は無視される。
document-root | <uri-specification>
target-stylesheet
--該当ナシ--
“external-destination”特性の値が空の文字列である場合，又は，外部宛先がスタイルシートを使用するメディア型ではない場合は，この特性は無視される。
use-normal-stylesheet | <uri-specification>
--該当ナシ--
20 索引に関する特性 （V1.1 新設）
特性
index-class
XSL1.1
CSS2
索引キーを，やはり索引キーが指定されているフォーマット化オブジェクトと結び付ける。
<string>
index-key
--該当ナシ--
索引キーを，指定されるフォーマット化オブジェクトに結び付ける。
<string>
page-number-treatment
--該当ナシ--
索引内のページ番号がハイパーリンクであるのが望ましいかどうかを指定する。
link | no-link
merge-ranges-across-index-key-references
--該当ナシ--
異なる fo:index-key-reference フォーマット化オブジェクトからの一連のページ番号が，一つの範囲に併合されるかどうかを指定する。
merge | leave-separate
merge-sequential-page-numbers
--該当ナシ--
fo:index-key-reference 又は fo:indexpage-citation-list 内の一連のページ番号を，（merge-ranges-across-indexkey-reference が“merge”の場合に）一つの範囲に併合するかど
うかを指定する。
merge | leave-separate
--該当ナシ--
異なる fo:index-key-reference フォーマット化オブジェクトによって同じページへの複数の参照がそれぞれの引用ページ項目を保持するか，単独の引用ページ項目が保持さ
merge-pages-across-index-key-references れるかを指定する。
merge | leave-separate
ref-index-key
--該当ナシ--
フォーマット化オブジェクト木内のオブジェクトの“index-key”を指定する。
<string>
--該当ナシ--
21 マーカに関する特性
特性
XSL1.1
CSS2
marker-class-name
この特性は，fo:marker が同じ名前をもつその他のオブジェクトと共にグループ内にあるものとして識別する。それぞれが候補となって，“retrieve-class-name”特性の値が同じ
である fo:retrieve-marker によって検索される。
<name>
retrieve-class-name
--該当ナシ--
この特性は，fo:marker の子供が fo:retrieve-marker によって検索される場合に，その fo:marker の“markerclass-name”特性値は，この特性の値と同じでなければならないこと
16
特性
XSL1.1
CSS2
を制約する。
<name>
--該当ナシ--
この特性は，fo:marker の子供が fo:retrieve-marker によって検索される場合の優先度を指定する。
retrieve-position
first-starting-within-page | first-including-carryover | last-starting-within-page |
last-endingwithin-page
--該当ナシ--
page | page-sequence | document
--該当ナシ--
retrieve-boundary
V1.1 で次の二つの特性が追加されました。
用語“包含ページ”は，ここでは，検索された fo:marker の子によって生成又は返された最初の領域を含むページを意味するために使われる。
retrieve-boundary-within-table
page | table
--該当ナシ--
この特性は，他の同じように命名された fo:marker の親によって返される領域に関連する fo:marker の親によって返される領域に基づいて，fo:marker の子が
fo:retrieve-table-marker によって検索されるための優先度を指定する。
retrieve-position-within-table
first-starting-within-page | first-including-carryover | last-starting-within-page |
last-endingwithin-page
--該当ナシ--
22 数値から文字列への変換に関する特性
特性
format
XSL1.1
CSS2
この特性は，XSLT の数値から文字列への変換属性で定義されている。
<string>
grouping-separator
--該当ナシ--
この特性は，XSLT の数値から文字列への変換属性で定義されている。
<character>
grouping-size
--該当ナシ--
この特性は，XSLT の数値から文字列への変換属性で定義されている。
<number>
letter-value
--該当ナシ--
この特性は，XSLT の数値から文字列への変換属性で定義されている。“auto”の値は，属性が指定されない場合の XSLT 定義に対応する。
auto | alphabetic | traditional
--該当ナシ--
23 ページ付け及びレイアウト特性
特性
blank-or-not-blank
XSL1.1
CSS2
この特性は，参照されるページマスタがページシーケンスのこの点で選択に適合する場合に，決定のための選択規則の一部を形成する。
blank | not-blank | any | inherit
column-count
--該当ナシ--
区画内の段の数を指定する。
<number> | inherit
--該当ナシ--
17
特性
column-gap
XSL1.1
CSS2
段が複数ある区画において，隣接する段間の幅を指定する。
<length> | <percentage> | inherit
extent
--該当ナシ--
region-start 若しくは region-end の幅行内進行方向，又は，region-before 若しくは region-after のブロック進行方向を指定する。
<length> | | inherit
flow-name
--該当ナシ--
流し込みの名前を定義する。
<name>
force-page-count
--該当ナシ--
“force-page-count”特性は，ページシーケンスでページ数を強制的に制約するために使用される。
auto | even | odd | end-on-even | end-on-odd | no-force | inherit
initial-page-number
--該当ナシ--
このページシーケンスで使用される初期ページ番号を設定する。
auto | auto-odd | auto-even | <number> | inherit
master-name
--該当ナシ--
マスタを識別する名前。
<name>
master-reference
--該当ナシ--
文書内に存在するマスタ名を参照しなければならない。
<name>
maximum-repeats
--該当ナシ--
ページの部分シーケンスで，ページ数を最大に制約する。
<number> | no-limit | inherit
media-usage
--該当ナシ--
“media-usage”特性を使用すると，スタイルシートによって指定されたページを表示するために選択された表示メディアをどのように使用するかを制御することができる。
auto | paginate | bounded-in-one-dimension | unbounded
odd-or-even
--該当ナシ--
この特性は，ページシーケンスのこの点で，参照されるページマスタが選択に適合する場合に，決定するための選択規則を部分的に形成する。
odd | even | any | inherit
page-height
--該当ナシ--
ページの高さを指定する。
auto | indefinite | <length> | inherit
page-position
--該当ナシ--
この特性は，参照されるページマスタがページシーケンスのこの点で選択に適合する場合に，決定するための選択規則を部分的に形成する。
only | first | last | rest | any | inherit
page-width
--該当ナシ--
ページの幅を指定する。
auto | indefinite | <length> | inherit
precedence
region-name
flow-map-name
--該当ナシ--
どれが単純ページマスタの隅まで拡張するかに関して，region-before，region-after，region-start，又は region-end のいずれの区画が優先するかを指定する。
true | false | inherit
--該当ナシ--
xsl-region-body | xsl-region-start | xsl-region-end | xsl-region-before | xsl-region-after |
<name>
--該当ナシ--
この特性は，fo:page-sequence 上の流し込みマップ参照特性の値を後で参照する流し込みマップの名前を指定する。
<name>
--該当ナシ--
18
特性
flow-map-reference
XSL1.1
CSS2
ページシーケンス内の領域に流し込みを指定するために流し込みマップを指定する。
<name>
flow-name-reference
--該当ナシ--
領域への流し込みの特定の割当ての流し込み元リストの一連の流し込みに用いられる流し込みを指定する。
<name>
region-name-reference
--該当ナシ--
領域への流し込みの特定の割当ての流し込み目標リストの一連の流し込みに用いられる流し込みを指定する。
<name>
--該当ナシ--
24 表特性
特性
border-after-precedence
XSL1.1
CSS2
border-after に対するこのフォーマット化オブジェクトの境界規定の優先順位を指定する。
force | <integer> | inherit
border-before-precedence
--該当ナシ--
border-before に対するこのフォーマット化オブジェクトの境界規定の優先順位を指定する。
force | <integer> | inherit
border-collapse
--該当ナシ--
この特性は，表の境界モデルを選択する。値“separate”は，分離境界モデルを選択する。値“collapse”は，縮退境界モデルを選択する。
CSS 定義に対する XSL の変更点： XSL で追加された値の意味を次に示す。collapse-with-precedence
collapse | collapse-with-precedence | separate | inherit
border-end-precedence
collapse | separate | inherit
border-end に対するこのフォーマット化オブジェクトの境界規定の優先順位を指定する。
force | <integer> | inherit
border-separation
--該当ナシ--
“border-separation”特性は，隣接するセルの境界間の距離を指定する。
<length-bp-ip-direction> | inherit
border-start-precedence
--該当ナシ--
border-start に対するこのフォーマット化オブジェクトの境界規定の優先順位を指定する。
force | <integer> | inherit
caption-side
--該当ナシ--
この特性は，表ボックスに関連する表題ボックスの位置を指定する。
CSS 定義に対する XSL の変更点： 次の表記方向関連値を追加する。before / after / start / end
before | after | start | end | top | bottom | left | right | inherit
column-number
top | bottom | left | right | inherit
fo:table-cell については，これは，表セルがまたがる最初の列数を指定する。
<number>
column-width
--該当ナシ--
“column-width”特性は，その値が“column-number”によって提供される列の幅を指定する。
<length> | <percentage>
empty-cells
--該当ナシ--
分離境界モデルでは，この特性は，可視内容のないセルの周囲にある境界のレンダリング及び可視内容のないセルの背景のレンダリングを制御する。
show | hide | inherit
ends-row
show | hide | inherit
このセルによって行が終了するかどうかを指定する。
19
特性
XSL1.1
CSS2
true | false
number-columns-repeated
--該当ナシ--
“number-columns-repeated”特性は，表列の規定を n 回繰り返すことを指定する。
<number>
number-columns-spanned
--該当ナシ--
fo:table-column については，“number-columns-spanned”特性は，from-table-column() 関数の使用によってこの fo:table-column フォーマット化オブジェクトからの特性を使用
する表セルがまたがる列数を指定する。
fo:table-cell については，“number-columns-spanned”特性は，現在の列から始まる列進行方向で，このセルがまたがる列数を指定する。
<number>
number-rows-spanned
--該当ナシ--
“number-rows-spanned”特性は，現在の行から始まる行進行方向で，このセルがまたがる行数を指定する。
<number>
starts-row
--該当ナシ--
このセルが行を始めるかどうかを指定する。
true | false
table-layout
--該当ナシ--
“table-layout”特性は，表セル，行及び列をレイアウトするために使用されるアルゴリズムを制御する。
auto | fixed | inherit
table-omit-footer-at-break
auto | fixed | inherit
“table-omit-footer-at-break”特性は，表の最後の領域が表によって生成された領域の末尾にない場合に，その表が fo:table-footer フォーマット化オブジェクトの内容で終了す
るのが望ましいかどうかを指定する。
true | false
table-omit-header-at-break
--該当ナシ--
“table-omit-header-at-break”特性は，表の最初の領域が表によって生成された領域の先頭にない場合に，その表が fo:table-header フォーマット化オブジェクトの内容で始ま
るのが望ましいかどうかを指定する。
true | false
--該当ナシ--
25 表記方向関連特性
特性
direction
XSL1.1
CSS2
この特性は，ブロックの基本表記方向，Unicode 双方向（BIDI）アルゴリズムの埋込み及び上書き（UNICODE UAX#9 を参照）の方向を指定する。
CSS 定義に対する XSL の変更点：
•
行内オブジェクト上での“direction”及び“unicode-bidi”の固有の使用は，行内進行方向に設定して，Unicode 双方向（BIDI）アルゴリズムによって使用される。この
方向は，現在の表記方向が決定した行内進行方向，及び，Unicode 双方向（BIDI）アルゴリズムが決定した暗黙の方向を上書きしてもよい。
•
“writing-mode”特性との一致を確実にするため，“direction”特性は，“writing-mode”特性が方向378 TS X 0088 : 2006 を設定する場合は，必ず，“writing-mode”特性
が設定するのと同じ行内進行方向を設定する値に初期化される。“direction”特性が同じフォーマット化オブジェクトに明示的に指定される場合は，“direction”特性
の値は，“表記方法”が設定する行内進行方向を上書きすることになる。
•
この特性は，グリフの方向が行内進行方向に対して垂直であるテキストにのみ影響する。そのため，垂直の表意文字のテキストの“glyph-orientation-vertical”に対
して初期値が指定された場合，この特性が影響を及ぼすことはない。垂直テキストに指定された“glyph-orientation-vertical”特性の値が 90 度又は -90 度であれ
ば，この特性の影響を受ける。注記垂直テキストでは，行内進行方向が“tb”となるのが典型的であるが，この場合，これは，グリフ方位が 90 度のテキストの行内
進行方向“lr”及びグリフ方位が -90 度であるテキストの行内進行方向“rl”に対応する。
•
“writing-mode”特性は，行内コンテナなど，参照領域を生成するブロックを定義するフォーマット化オブジェクトに使用される。この特性は，ブロック進行方向及び行
内進行方向も確立する。“direction”特性は 行内進行方向を変更するだけであり 主として 参照領域でもない行内領域を生成するフォーマット化オブジェクトに使
20
特性
XSL1.1
•
CSS2
CSS を XSL に対応付けする際，すべてのブロックレベル方向性制御に対して，“direction”特性ではなく，XSL の“writing-mode”特性を使用するのが望ましい。
XSL の“writing-mode”特性も任意の行内コンテナオブジェクト又はブロックコンテナオブジェクトに使用するのが望ましい。“direction”特性の使用については，
fo:bidi-override フォーマット化オブジェクトの Unicode 双方向（BIDI）アルゴリズムの制御/ 上書きに限定されるのが望ましい。
ltr | rtl | inherit
ltr | rtl | inherit
この特性は，“表記方法”が指定したパス方向に関連して，グリフの方向を指定する。
glyph-orientation-horizontal
<angle> | inherit
--該当ナシ--
この特性は，“表記方法”が指定したパス方向に関連して，グリフの方向を指定する。
glyph-orientation-vertical
auto | <angle> | inherit
--該当ナシ--
“height”が主要ベースラインの上のアセンダ領域に使用されることを指定する。
text-altitude
use-font-metrics | <length> | <percentage> | inherit
--該当ナシ--
“depth”が主要ベースラインの上のディセンダ領域に使用されることを指定する。
text-depth
use-font-metrics | <length> | <percentage> | inherit
--該当ナシ--
CSS 定義に対する XSL の変更点： 値に関する説明の後に続く一般的な記述の第1 段落の文章は，“文字の表示の最終的な順序は…”と読むのが望ましい。
unicode-bidi
normal | embed | bidi-override | inherit
normal | embed | bidi-override | inherit
それぞれの記述方法の値は，参照領域の上に記述した値のそれぞれに示される三つの方向特性すべてを指定する。
writing-mode
lr-tb | rl-tb | tb-rl | lr | rl | tb | inherit
--該当ナシ--
26 その他の特性
特性
content-type
XSL1.1
CSS2
この特性は内容型を指定し，利用者エージェントがこの特性を使用して，オブジェクトのレンダリングプロセサを選択してもよい。
<string> | auto
id
--該当ナシ--
fo: 名前空間をもつ結果木のすべてのオブジェクト内にある一意の識別子。
<id>
provisional-label-separation
--該当ナシ--
list-item-label の終わりと list-item-body の始まりの間の暫定的な距離を指定する。
<length> | <percentage> | inherit
provisional-distance-between-starts
--該当ナシ--
list-item-label の開始字下げと list-item-body の開始字下げとの間の暫定的な距離を指定する。
<length> | <percentage> | inherit
ref-id
--該当ナシ--
指定された一意の識別子をもつオブジェクトを参照する。
<idref> | inherit
score-spaces
--該当ナシ--
“text-decoration”特性が空白に適用されるかどうかを指定する。
true | false | inherit
--該当ナシ--
21
特性
visibility
XSL1.1
CSS2
“visibility”特性は，要素が生成するボックスがレンダリングされるかどうかを指定する。
visible | hidden | collapse | inherit
src
visible | hidden | collapse | inherit
URI 参照を指定して，このオブジェクトの内容として含まれる画像/ 図形データ，又は色プロファイルデータなどの外部資源を配置する。
<uri-specification> | inherit
--該当ナシ--
z-index
auto | <integer> | inherit
auto | <integer> | inherit
V1.1 では、次の特性が追加になりました。
change-bar-class
この特性は，fo:change-bar-begin と fo:change-bar-end 要素との名前を関連付ける
<name>
change-bar-color
--該当ナシ--
変更バーの色を指定する
<color>
change-bar-offset
--該当ナシ--
変更されたことをマークされる文章を含む段領域の辺から生成された変更バーの中心までの距離を指定する。
<length>
change-bar-placement
--該当ナシ--
この特性は，段領域に関係して，変更バーが発生するかどうかを決定する。
start | end | left | right | inside | outside | alternate
change-bar-style
--該当ナシ--
変更バーのスタイルを指定する。
<border-style>
change-bar-width
--該当ナシ--
変更バーの太さを指定する。
<border-width>
intrinsic-scale-value
--該当ナシ--
基本のサイズに相当する変倍率を指定する。
<percentage> | inherit
page-citation-strategy
--該当ナシ--
この特性は，どのページ領域の集合がページ番号引用フォーマット化オブジェクトによって考慮されるかを指定する。
all | normal | non-blank | inherit
scale-option
--該当ナシ--
図形の幅又は高さに適用する変倍率を取り出すかどうかを指定する。
width | height | inherit
--該当ナシ--
27 簡略記述特性
特性
background
XSL1.1
CSS2
“background”特性は，各背景特性，すなわち，background-color，background-image，background-repeat，background-attachment 及び background-position をスタイルシートの
同じ位置に設定するための簡略記述特性である。
[<background-color> || <background-image> || <background-repeat> ||
<backgroundattachment> || <background-position>] | inherit
22
[<background-color> || <background-image> || <background-repeat> ||
<backgroundattachment> || <background-position>] | inherit
特性
XSL1.1
background-position
“background-image”が指定されている場合，この特性はその初期位置を指定する。
CSS 定義に対する XSL の変更点： XSL は，CSS 特性を簡略記述特性として扱う。
CSS2
[ [<percentage> | <length> ]{1,2} | [ [top | center | bottom] || [left | center | right] ] ] | inherit [ [<percentage> | <length> ]{1,2} | [ [top | center | bottom] || [left | center | right] ] ] | inherit
border
ボックスの上下左右すべての境界に、同じ幅、色及びスタイルを設定するための簡略特性とする。
[ <border-width> || <border-style> || <color> ] | inherit
border-bottom
[<'border-width'> || <'border-style'> || <'color'>] | inherit
下境界の幅、スタイル及び色を設定するための簡略記述特性とする。
[ <border-width> || <border-style> || <color> ] | inherit
border-color
[<'border-bottom-width'> || <'border-style'> || <'color'>] | inherit
border-top-color, border-right-color, border-bottom-color, border-left-color を一個所でまとめて設定するための簡略記述特性とする。
[ <color> | transparent ]{1,4} | inherit
border-left
<border-color>{1,4} | inherit
左境界の幅、スタイル及び色を設定するための簡略記述特性とする。を指定する。
[ <border-width> || <border-style> || <color> ] | inherit
border-right
[<'border-left-width'> || <'border-style'> || <'color'>] | inherit
右境界の幅、スタイル及び色を設定するための簡略記述特性とする。。
[ <border-width> || <border-style> || <color> ] | inherit
border-style
[<'border-right-width'> || <'border-style'> || <'color'>] | inherit
border-top-style, border-right-style, border-bottom-style, border-left-style を一個所でまとめて設定するための簡略記述特性とする。
<border-style>{1,4} | inherit
border-spacing
<border-color>{1,4} | inherit
長さは，隣接するセル境界を分離する距離を指定する。
CSS 定義に対する XSL の変更点： XSL は，CSS 特性を簡略記述特性として扱う。
<length> <length>? | inherit
border-top
<length> <length>? | inherit
上境界の幅、スタイル及び色を設定するための簡略記述特性とする。
[ <border-width> || <border-style> || <color> ] | inherit
border-width
[<'border-top-width'> || <'border-style'> || <'color'>] | inherit
border-top-width, border-right-width, border-bottom-width, border-left-width を一個所でまとめて設定するための簡略記述特性とする。
値が一つだけ存在する場合は、上下左右お境界すべてに適用する。値が二つ存在する場合は、上下境界に最初の値を設定し、左右境界には２番目の値を設定する。値が三
つ存在する場合は、上境界に最初の値を、左右境界に２番目の値を、下境界には３番目の値をそれぞれ設定する。
<border-width>{1,4} | inherit
cue
<border-width>{1,4} | inherit
CSS2 参照：“cue”特性
<cue-before> || <cue-after> | inherit
font
<cue-before> || <cue-after> | inherit
“font”特性は，簡略記述特性であるが，後に記述するように例外的な簡略記述特性であり，“fontstyle”，“font-variant”，“font-weight”，“font-size”，“line-height”及び
“font-family”をスタイルシートの同じ位置で設定するために使用される。
[ [ <font-style> || <font-variant> || <font-weight> ]? <font-size> [ / <line-height>]?
<fontfamily>] | caption | icon | menu | message-box | small-caption | status-bar | inherit
margin
ブロック領域又は行内領域の“margin-top”，“margin-right”，“margin-bottom”及び“margin-left”を設定するための簡略記述特性である。
CSS 定義に対する XSL の変更点： ● マージンは，CSS との互換性を保持するために提供される。
<margin-width>{1,4} | inherit
padding
[ [ <font-style> || <font-variant> || <font-weight> ]? <font-size> [ / <line-height>]?
<fontfamily>] | caption | icon | menu | message-box | small-caption | status-bar | inherit
<margin-width>{1,4} | inherit
ブロック領域又は行内領域の“padding-top”，“padding-bottom”，“padding-left”及び“padding-right”を設定するための簡略記述特性である。
23
特性
page-break-after
XSL1.1
CSS2
<padding-width>{1,4} | inherit
<padding-width>{1,4} | inherit
CSS 定義に対する XSL の変更点： XSL は CSS 特性を簡略記述特性として扱う。
auto | always | avoid | left | right | inherit
page-break-before
auto | always | avoid | left | right | inherit
CSS 定義に対する XSL の変更点： XSL は CSS 特性を簡略記述特性として扱う。
auto | always | avoid | left | right | inherit
page-break-inside
auto | always | avoid | left | right | inherit
CSS 定義に対する XSL の変更点： XSL はこれを簡略記述特性として扱う。
CSS では，“page-break-inside”の定義は“page-break-before”及び“page-break-after”の定義と共有されていた。ここでのテキストは編集されており，“page-break-inside”に有
効な値の選択のみを含み，“before”，“after”，“inside”の三つ組を除外している。
avoid | auto | inherit
position
avoid | auto | inherit
使用される位置決め機構を指定する。
CSS 定義に対する XSL の変更点： XSL は CSS 特性を簡略記述特性として扱う。
static | relative | absolute | fixed | inherit
size
static | relative | absolute | fixed | inherit
この特性は，ページボックスのサイズ及び向きを指定する。
CSS 定義に対する XSL の変更点： これは，XSL の“page-height”特性及び“page-width”特性に対応付けされる CSS 簡略記述特性として扱われる。
<length>{1,2} | auto | landscape | portrait | inherit
vertical-align
<length>{1,2} | auto | landscape | portrait | inherit
この特性は，行ボックス内部において行内レベル要素が生成するボックスの垂直位置決めに影響する。
CSS 定義に対する XSL の変更点： XSL は CSS 特性を簡略記述特性として扱う。
baseline | middle | sub | super | text-top | text-bottom | <percentage> | <length> | top |
bottom | inherit
white-space
この特性は，要素内の空白がどのように操作されるかを宣言する。特性の値の意味を次に示す。
CSS 定義に対する XSL の変更点： XSL は，空白の縮退の制御，空白及び改行の処理，ラップを別々の特性に分割する。
XSL は CSS 特性を簡略記述特性として扱う。
normal | pre | nowrap | inherit
xml:lang
baseline | middle | sub | super | text-top | text-bottom | top | bottom | <percentage> |
<length> | inherit
normal | pre | nowrap | inherit
ハイフン付けなどの言語サービス及び行区切りの決定において，フォーマッタが使用する言語及び国名を指定する。これは，システム依存の方法で，行組みに影響を与える
ことがある。
<country-language> | inherit
--該当ナシ--
28 利用者インタフェース
特性
XSL1.1
CSS2
ポインティング装置に表示されるカーソルの型を指定する。
cursor
[[<uri> ,]* [ auto | crosshair | default | pointer | move | e-resize | ne-resize | nw-resize |
n-resize | se-resize | sw-resize | s-resize | w-resize | text | wait | help ]] | inherit
--該当ナシ-outline
CSS2 の輪郭線が境界と異なる点は：1.輪郭線はスペースをとらない。 2.輪郭線は長方形でなくても良い。
--該当ナシ--
outline-width
[<'outline-color'> || <'outline-style'> || <'outline-width'> ] | inherit
幅の特性
24
特性
outline-style
color
XSL1.1
CSS2
--該当ナシ--
<border-width> | inherit
--該当ナシ--
<boder-style> | inherit
--該当ナシ--
<color> | inherit
線種の特性
色の特性
25
この事業は、競輪の補助金を受けて
実施したものです。
http://ringring-keirin.jp/
財団法人 日本自転車振興会
競輪補助事業
平成 19 年度 Web 資源有効活用を推進する情報基盤の標準化調査研究補助事業
「マルチモーダルウェブマイニング技術の標準化調査研究」
成果報告書
発行
印刷
平成 20 年 3 月
財団法人 日 本 規 格 協 会
情報技術標準化研究センター
〒100-0014 東京都千代田区永田町 2-13-5
電話（03）3592-1408
株式会社
スタンダード・ワークス
〒107-8440 東京都港区赤坂 4-1-24
日本規格協会ビル内
電話（03）3585-4558
－禁無断転載―

電子成果品にスタイルシートを格納した場合の JS 電子納品チェック

都庁合格 戦略講義 - 公務員試験専門予備校：CSS

資料解釈 特講 - 公務員試験専門予備校：CSS

同じブロックを同じページに配置

Cmsdesigner 作り方のコツ（初心者用）

電子書籍の組版ってどうなの？

ホームページ HTML/CSS 編 カリキュラム

- XMLコンソーシアム