W3C Publishing Working Groupで軽量SMIL(次世代SMIL?)について議論始まる

 W3CのPublishing Working Group の2017年9月18日の電話会議で、SMIL lite(軽量のSMIL)が(おそらく)始めて議論されています。先のエントリで紹介したWeb Pulications
での利用が想定されています。Web Pulications はEPUBと統合されて、EPUB4的な立ち位置になる可能性も示唆されているので、次世代SMILといえる立ち位置になりうるのかもしれません。まだ、議論は始まったばかりのようで、どこに向かうのかはわかりませんが。

 要件リストは、Essential Requirements(不可欠な要件)とAdvanced Requirements(高度な要件)にわけて整理されています。Essential Requirements はざっと見た感じ、現行のEPUB3ですでに実現できていることが並んでいるようですが、Advanced Requirements では、現行のEPUBでは実現できていない手話動画とテキストの同期も想定した動画のサポートや、音声解説を付けた動画のサポートが挙げられています。

 議事録を読むと、SMIL lite は XMLではなく、JSON で行く可能性が今のところ高そうですね。 

 なお、SMIL (Synchronized Multimedia Integration Language) は、DAISY や EPUB 3 では、テキストと音声の同期あるいは音声(録音音声またはTTSによる読み上げ)の再生の制御のために使用されています。現行の EPUB 3 におけるSMILのサポートは音声に限定されていますが、聴覚障害者のために手話動画とテキストを同期させたEPUBを作るため、動画のサポートが EPUB 3 仕様策定の段階から要望としてあがっていたようです。そういう経緯があったためか、EPUB Media Overlays 3.0の仕様では、動画をサポートしないことがわざわざ言及されています(最新の EPUB 3.1 でも同じです)。今回の SMIL lite の議論もこの経緯を受けてということだと思われます。

Although future versions of this specification might incorporate support for video media (e.g., synchronized text/sign-language books), this version supports only synchronizing audio media with the EPUB Content Document.

 

 最後に議事録からSMIL lite に関係するところを転載します(ここでも河村宏さんの名前が…)。

1. Requirement for SMIL Lite

Garth Conboy: “SMIL lite” == “grin”

Tzviya Siegman: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Marisa DeMeglio: link in GotoChat
… we’ve been looking at design reqs for syncronized multimedia

Rachel Comerford: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia

Marisa DeMeglio: allowing talking books to talk

Tzviya Siegman: can you give a quick overview?

Marisa DeMeglio: EPUB3 didn’t have a lot of problems with media overlays
… we can look at something lighter than SMIL
… we used a slim subset in EPUB3
… but SMIL adoption in the world at large hasn’t been huge
… so we can look at other formats
… we do need to link chunks of text with chunks of audio
… you still need structural semantics for navigation etc
… making video + text transcripts more accessible is a requirement
… and there are some things not included in media overlays
… I’ve been emailing with dweck
… like having multiple granularities of navigation–from para by para to word by word
… text + sign language
… video + descriptive audio
… all those are not covered by media overlays
… our next step is deciding what format to do

Garth Conboy: That multi-resolution MO approach was discussed some years ago, and I think prototyped in Readium, I think. It’s a cool idea.

Marisa DeMeglio: first question is about formats–XML or not XML

Dave Cramer: what’s the status of audio sync on the web at large?

Marisa DeMeglio: I don’t know of anything

Ivan Herman: I don’t know much more
… I love your understatement… SMIL adoption is terrible
… we will have to define a SMIL-lite which has any hope for implementation

Bill Kasdorf: is there an active SMIL WG?

Ivan Herman: we will also have to ensure there will be several implementations on top of browsers

Laurent Le Meur: I agree with Ivan when he says we’ll have to create polyfills
… if this is the case, if JS is the language that will use SMIL, then XML is not the best structure for that
… JSON has the lead, a structure JS loves
… SMIL is so complex, there are too many features
… we can track as JSON structure

Garth Conboy: Marisa is also correct, when saying MO/SMIL(lite) adoption in EPUB Reading Systems is pretty good.

Laurent Le Meur: as for the requirements, we should make sure the structure we define doesn’t prevent us from adding advanced features later

Ric Wright: one other area is where there is a SMIL implemenation is for animation of SVG
… this has been implemented by browsers

Avneesh Singh: the main objective of this work was lack of support of SMIL on the web
… and then additional things came up
… that were not covered in EPUB3 MO
… media fragments is the one thing in the web which is used
… if we can find out groups in web who are trying to solve similar problems
… we can try to do it together

Charles LaPierre: ETS and Mark Hakkinen has done lots of work with SMIL
… they might have some insight
… they use this for assessments

Tzviya Siegman: the larger group should comment about requirements
… this is not part of our charter… so what should we do with these requirements? What are next steps?

Ivan Herman: as usual, this was the topic I wanted to put on the queue
… that’s an admin problem
… this whole issue of SMIL lite is not in our charter, but is a necessary thing
… this would be rec-track work
… the traditional way to do something like this would be to form a separate CG
… that would look at an initial spec plus one or two polyfills, showing it is possible
… once the CG says we have this, it solves these requirements, it’s polyfilled, it has users
… the most obvious way would be to then form a new WG

Garth Conboy: From charter: “This specification should generally be a functional superset of EPUB 3.1. Functional round-tripping to/from EPUB 3.1 considered highly desirable.” So, would could argue it’s kinda in our charter, as it’s in EPUB 3.1.

Ivan Herman: I still believe something like SMIL is still necessary for the web, and not only for WP
… even if WP is driving this here
… the web in general would benefit
… we then could get experts from other places for a CG
… I have some colleagues in Amsterdam who worked on original SMIL
… some of them are still around; I can approach them
… but a WG would be too much for them

Tzviya Siegman: the next steps are to clean up requirements and share them
… we should pass this on to APA, and share with Janina

Ivan Herman: there are some other media-related groups, like a video group
… they might have feedback
… and outside w3c there are other groups

Marisa DeMeglio: to comment on SMIL
… DAISY was in smil WG
… we used SMIL more than anyone else, but used less of it
… our use case was really different from everyone else’s
… they used it for short presos, annotations, etc.
… we used for entire books
… I’m not sure that reawakening the SMIL group would be good
… we might look elsewhere for overlap

Ivan Herman: it’s going to be very light, very concentrated

Tzviya Siegman: it might come down to how you position it
… I can help with that

Avneesh Singh: that’s a valid point from marisa_demeglio
… we need more strength to make it an implementable standard
… we need to strike a balance for something useful for our requirements as well as for others
… that IPTV was looking for something like SMIL
… Hiroshi can be a liason
… and Mark H can also help

Tzviya Siegman: we have people volunteering to be liasons
… joanie might know who to talk about at the browsers

Avneesh Singh: I will contact Mark Hakkinen and Hiroshi Kawamura

Bill Kasdorf: I was going to ask Marisa if there is a link she can share that documents the subset of SMIL that is actually used by DAISY

Marisa DeMeglio: bill_kasdorf: http://www.idpf.org/epub/31/spec/epub-mediaoverlays.html#sec-overlays-def

Bill Kasdorf: marisa: thanks, I didn’t realize that the MO spec in EPUB 3.1 was the subset you were talking about. That’s great to know because that is what folks are actually using in the publishing world.

WebとEPUB(そして、その先にある出版)を繋ぐものとなるか、”Web Publications” #html5jpub

 2017年9月24日に開催されるHTML5カンファレンスのセッションの1つ、html5j 電子出版部セッションにパネリストの1人として登壇させていただくことになりました。

 このセッションのテーマは、端的に言うとW3Cで議論されている”Web Publications(以下、WP)”という仕様をテーマにしています。これについては、セッションに先立って公開されている村上真雄さんの以下のスライドに詳しいのですが、私の理解では、いろいろな意味で、WebとEPUBの間を繋ぐ役割を果たすものではないかと思います。

 

 WPの特徴は、htmlファイルなどをとりまとめる役割を果たす、EPUBで言うところのOPFファイルに相当する「マニフェスト」と呼ばれるファイルを持つことで、これにWPに関するメタデータを持たせたり、読む順序(htmlを表示する順序)の情報を持たせることで、wpを複数のhtmlを1つのコンテンツのようにあつかうことができるようになるようです。EPUBを簡易にしたような仕様のように思えます。

 仕様はまだ定まっていないので、はっきりとしたことはいえないところがありますが、一番シンプルなパターンがおそらく以下のようなパターンで、画像はもちろん、Webと同じような方法で動画、音声も扱えたりするのでしょう。逆に言えば、EPUBで扱えるSMILは扱えるのかな(難しいか・・)

manifest(表示する順序の情報やメタデータを持つ)
├-html1
├-html2
├-html3
(中略)
└html10

 
 EPUBと違い、スクリプトの使用におそらくは制限はなく、閲覧環境はウェブブラウザになると思うので、EPUBではできないようなインタラクティブなコンテンツ、動的なコンテンツ、APIを叩くようなコンテンツもつくれルのではないかと思うので、ウェブサイトをそのままWP化することもできるはず。

 オンライン上に展開されているWPを利用することはもちろん、オフラインでWPを利用することも想定されているようです。

図の説明はキャプションの後の本文にあり
“Accessing a Portable Web Publication in packed state from the Web via a Service Worker.” from Portable Web Publications for the Open Web Platform (W3C First Public Working Draft 15 October 2015)
 上の図は、オフラインでのWPの利用を示した図で、Webにアクセスできる環境にあるときに必要に応じてService Workerでサーバーに接続してラップトップコンピューターがウェブブラウザ上でWPを取得(更新?)してキャッシュすることを示している(らしい)。

 EPUB寄りの目線でみれば、オンラインで利用されることが想定されていることが「へぇ」ポイントかもしれない。ここはWeb寄りの立場で見るか、EPUB寄りの立場で見るかで、WPのどこに「へぇ」するかは違うのかもしれない。

図の説明はキャプションの後の本文にあり。
“Accessing a Portable Web Publication in an unpacked state directly from the Web. ” from Portable Web Publications for the Open Web Platform (W3C First Public Working Draft 15 October 2015)
 上の図はHTTPリクエストでサーバーに接続してラップトップコンピューターがウェブブラウザからパッケージされていないWPを取得する図。普通にWebにアクセスするのと同じということでしょうか。

 ページネーションや目次などのナビゲーションや閲覧環境も電子書籍のUIを取り入れたものが構想されているようです(しかも、ブラウザ上で)。理想的にいくならば、WebのよいところとEPUBのよいところをそれぞれ取り入れたものになりそうですし、WPがWebとEPUBを橋渡しすることで、WebやEPUBにもお互いの長所を取り入れる効果が期待できるような気がする。UIについては、以下で書いたこともありますが。電子書籍のリーディングシステムとWebブラウザが相互に影響しあって、それぞれのUIのよいところをとりいれるとよいと思う。

 パッケージングして、1つのファイルにできるようになることも想定されていて、その場合は、Packaged Web Publications(PWP)と呼ばれるようです。パッケージングの仕様は方向性がよくわかりませんが、オフラインで利用したり、持ち運んだりする場合は、1つのファイルとして扱えることが必須なような気がします。

図の説明はキャプションのあとの本文にあり
“The same content can be turned into an archived file and back without any inherent changes to the core content or associated digital assets” from Portable Web Publications for the Open Web Platform (W3C First Public Working Draft 15 October 2015)
上の図は、同じコンテンツがコンテンツのコアな部分の変更を伴わずにオフライン、オンライン両方で利用できることを示した図。スマートフォンがパッケージされて1つのアーカイブファイルをオフラインで利用し、ラップトップコンピューターがパッケージされずに展開されたWPをオンラインで利用している。

 W3Cのドキュメントを読むと、WPがフォローする範囲といいますか、想定されるユースケースはかなり広いようで、Web寄りの立場から見れば、オフラインでも読めるWebという見方もできそうですし、EPUB寄り、出版寄りの立場から見れば、EPUBにちかいもの、しかし、EPUBよりも自由度の高い出版物と見えるような気がする。立ち位置によってだいぶWPも違うものに見えるかもしれない。Webと出版を両端におくとするなら、私のイメージは以下の図のような感じで、WebとEPUBに若干重なりながら、webとEPUBの間に立つ立ち位置のように思えます。立ち位置によって全く違うものに見えるかもしれない。

Webと出版を両端において、WPの位置づけを示した図。Webが左、出版が右端にあり、出版のすぐそばにEPUBがあり、EPUBとWebの少し間のあるところにWPがEPUBとwebに重なりつつ置かれています

 EPUBは仕様上、長さに上限も下限もありませんが、現状、Amazonのような書店で販売され、紙版と並行して出されるコンテンツが圧倒的に多い気がします。その意味では、EPUBのコンテンツの長さやンテンツのあり方は、今のところ紙の出版物に規定されている(されてしまっている?かもしれない?)(もちろんEPUB全てがそうというわけではありません)。

 WPはおそらく紙の出版物(少なくも図書)の代替として出されることは、主なユースケースにならないのではという気もしています。Webよりも長く、本より短いサイズのコンテンツに向いているものかもしれない。2011年に以下のようなエントリを書いたことがありますが、WPに該当する部分があるかもしれない(、これも今読み返すとだいぶ外れているのですが)。

 ビジネスモデル、というべきなのか、分かりませんが、制作者からどのような過程を経て、WPがユーザーの手に渡るのかという点も気になります。電子書籍に以下の図のようにプラットーフォームごとにコンテンツへのリーチから、DRM、課金、アノテーション、リーディングシステムまで囲い込む垂直統合型が基本になっています。垂直統合型が悪いというわけではないのですが、それだけだと、ユーザー側の選択肢が狭められてしまうので、可能な部分をプラットフォームの機能をレイヤーごとに分けて水平分業型にできないかと考えたこともありますが、

プラットフォーマーがアカウント、リーチ(検索)、DRM、課金、アノテーション、リーディングシステムをそれぞれで抱えている図

Webと親和性が高そうなWPは、おそらくWebに準じた水平分業型に近いものになるのではないか。電子書籍領域のそばに水平分業型のWPというコンテンツがドンと出てくることで、以下の図にあるように水平に伸びてくるレイヤーが電子書籍から出てくるかもしれない。

左端にWeb、右端に電子書籍、中央にWPがある横軸の図で、アカウント、リーチ(検索)、DRM、課金、アノテーション、リーディングシステムの各レイヤーが並んでいる図。webはリーチ、アノテーション、ブラウザのレイヤーを有している(アカウント、DRM、課金レイヤーはない)。最も右端の電子書籍部分はプラットフォーマーが全てのレイヤーを独自に囲い込んでいるが、中央に近づくと、一部のレイヤー(リーチ、アノテーション、DRM、リーディングシステム)を他の電子書籍プラットフォーマーと共有したり、WPともレイヤー(リーチ、アノテーションなど)を共有している。中間にあるWPはWebよりな位置ではWebと同じレイヤー構造で、電子書籍よりの位置では、アノテーションや課金は電子書籍とレイヤーを共有している。

アクセシビリティの観点からいえば、自分の使いやすいリーディングシステムは人によって異なるので、プラットフォーム側に使用するリーディングシステムを固定されない方が望ましい。自分の使いやすいリーディングシステムやブラウザで複数のプラットフォームのコンテンツやWPが使えるようになるとよいなぁと思ったりする(ちなみに以下の図で複数で共有されているリーディングシステムレイヤーは1つのリーディングシステムで複数のプラットフォームを共有するということではなく、利用者にとって使いやすいリーディングシステムで複数のプラットフォームを利用できるということを示している)。

 2012年にも以下のエントリを書いたことがあります。今、改めて読み返すとこれはこれで結構ツッコミどころが多いのですが、WPの目指すところはこれに近いイメージはあるかもしれないとも感じています。

 PWPは、次世代のEPUBになる可能性もあるようです。WPとEPUBよりは、WPとWebのほうが親和性が高いように思えるので、WPとEPUBが統合したら、出版とWebの融合もかなり進むのではないかという気がする(しかし、その場合、EPUB3とだいぶ異なる仕様になるので、後方互換性は大丈夫かという懸念も)。

 思いつくところをいろいろと書きましたが、さあ、どうなるのでしょうか。WPのアクセシビリティはどうなるか、という点も気になるところ。

参考ドキュメント