BISC Grid

Кстати, об упоминаемом BISC Grid в прошлой статье: существует рабочая группа и проект EPUBTest, в котором можно, например, посмотреть состояние современных систем чтения контента и их соответствия спецификациям и объем поддерживаемых фич, а так же протестировать свой собственный viewer на предмет соответствия. Процедура, впрочем, не из легких.

Проект — коллективное детище трех организаций: Digital Publishing Forum (IDPF), BISG и DAISY Consortium.

Список участников тоже неплох: Apex Covantage, Aptara, DAISY Consortium, Firebrand Technologies, Google, Hachette Book Group, HarperCollins, Ingram/VitalSource, International Digital Publishing Forum (IDPF), Iviago, John Wiley & Sons, Kaplan, Kobo Inc., Newgen, Penguin Random House, Safari Books Online, and Sourcebooks.

EPUB 3 EDUPUB Profile

Недавно в Фениксе (штат Аризона) завершилась конференция, посвященная новому метастандарту EDUPUB. На epubzone опубликовали весьма любопытный отчет по этому поводу. Далее коротко о том, что будет представлять из себя EPUB 3 EDUPUB Profile.

Отмечается, что основной целью конференции было выработать решения о том, что войдет в начальный (initial) и последующие релизы.  Встреча проходила в двух параллельных направлениях: интеграция с IMS и работа непосредственно над EDUPUB профилем спецификации EPUB 3.

Стандарты IMS

Были рассмотрены рекомендации IMS и выделено 4 ключевых приоритета:

  1. Требования к фреймворку (foundation requirements): поддержка LTI1.2, поддержка rich outcomes (часть LTI) и повышение оффлайновой устойчивости (persistence).
  2. Определиться с метрикам для поддержки аналитики грядущей спецификацией фреймворка Caliper
  3.  Поддержка на уровне LTI потребителей (LTI consumer — любой потребитель инструментов, например LMS), LTI ссылок на веб-инструменты (tools по спеку LTI могут быть любыми, например EPUB-публикация)  и приложения так, чтобы они могли быть встроенными в EDUPUB контент.
  4. Поддержка LTI в мобильных приложениях

Достигнуто соглашение, что обязательным для первоначальной EDUPUB-спецификации будет только первый пункт. Немаловажно, что оговорено, что включение кода или скриптов внутрь EDUPUB является допустимой, но плохой практикой. Пункты 2-4 будут включены в последующий версии спецификаций.

EDUPUB соответствие контента спецификации (content conformance)

Договорились, что имеющиеся инструменты EPUBCheck и EPUBTestgrid должны ускорить возможность сертификации контента, систем чтения и инстурментов создания контента. Требования EDUPUB Content Conformance определены как:

  • Валидная EDPUB 3.0.1 публикация и package-файл.
  • Метаданные
    • Как минимум один экземпляр schema:acessibilityFeature
    • Обязательный (здесь и далее must) dc:type со значением «edupub»
    • Обязательное определение учительская или ученическая версия издания
    • Определение, когда документ — исходник печатного ли издания или учительского издания
    • Другие опциональные (should) метаданные:
      • аудитория, образовательная роль, тип деятельности и др.
      • возможно, RDFa/Schema.org или др.
    • Метаданные должны строго соответстовать контенту и соответствовать тому, что они описывают (например, alt для img и MathML)
  • Структурная целостность документа
  • Если используется словарь, валидация обязательна
  • Валидация section/heading требований с учетом семантики и корректности ее исползования.
  • Скриптовые компоненты (scriptable components) требуют дополнительных метаданных поверх спецификации отдельно распространяемых объектов (distributable objects)
    • Все компоненты должны быть в iframe
    • Следует предполагать, что они находятся в отдельном домене (CORS) —  не прямой скриптинг, через iframe boundary.
    • Весь кроссдок — через postMessage
    • Messaging определяется в spine
  • Стоит ли ограничивать reflowable-публикации использованием только scriptable components, будет определено в ближайшее время.
  • Если есть аннотации, учесть их соответствие спецификации Open Annotation, а все target ссылки должны валидироваться.
  • Для фиксированных лэйаутов обязательным является требовавние включения reflowable-альтренативы, путем реализации multiple renditions.
  • Если включено разбиение страниц (pagebreak markers существуют как часть EDUPUB спецификации), список nav — обязателен.
  • Соответствие требованию корректного следования контента LTI-ссылкам и прочим результирующим сервисам (например, оценки) с соответствием зависимости системе чтения.

Сертификация систем чтения EDUPUB

  • Требования соответствия контента (Content Requirements):
    • Соответствие спецификации EPUB 3.0.1
    • Соответствие спецификациям LTI и Rich Outcomes (?)
    • Обязательная поддержка рендеринга Scriptable Components
    • Обязательная поддержка multiple-rendition публикаций
    • Импорт и отображение аннотаций
    • Поддержка спецификации EPUB Scriptable Components
      Packaging and Integration 1.0: правильно обрабатывать свойство  epubsc:required-params
    •  EPUB Scriptable Components 1.0 API
      • Ограничения скриптинга уровнем контейнера
      • Если не определен на уровне spine, обеспечить поддержку postMessage
    • Подробнее об аннотациях
      • Адаптация Open Annotation W3C
      • Обязательно xHTML5 (нет такого в природе, но ок) в теле аннотации
      • JSON-LD сериализация
      • EPUB CFI в качестве внутреннего ссылочного аппарата
      • Определить уровень специфичности (specificity) — релиз, публикация, в работе.
        • Синтаксические органичения, позволяющие исполльовать не RFD-форматы
        • Позволить упаковку (bundling) коллекций аннотаций (+zip для транспорта) и определение целевой аудитории (учитель, возраст и тд)
        • Импорт аннотаций обязателен (must), экспорт — опционален (should)

Релиз спецификации предварительно назначен на май.

Сертификация инструментов производства (Authoring Tools) EDUPUB

Инструменты должны производить валидный EDUPUB и производить валидацию на соответствие спецификации.

  • Соответствие контентым спецификациям
  • Проверять корректность LTI-ссылок
  • Предоставлять матрицу доступного функционала
    • Добавлено третьими лицами
    • Многоуровневое сертифицирование (бронза, серебро, золото), на основе данных матрицы функционала

Дальнейшие шаги

Принятые решения:

  • Группа разработки EPUBCheck завершает имплементацию тестов для Content Conformance
  • Рабочая группа BISC Grid выполнит исследование возможности расширения сетки для EDUPUB в контексте сертификации систем чтения
  • Для сертификации инструментов производства контента еще требуется определить, кто будет ответственным исполнителям по этим задачам
  • Определено, что Альянс EDUPUB будет отвечать за сертификацию, тогда как IMS будет отвечать за технические стороны вопроса: соответствие спецификациям и так далее.

EPUB-WEB

Любопытный документ выпустил IDPF  — EPUB-WEB — своего рода манифест (white paper, unofficial draft), который, вероятно, определит будущее Digital Publishing’а (далее DP) в части его слияния с глобальной сетью. Документ, как минимум, стратегический и уделяет внимание двум направлениям развития спецификаций — по линиям W3C и IDPF.

Основная суть заключается в том, чтобы стереть границу между классическим вебом и отдельно стоящими цифровыми публикациями: пользователи должны иметь возможность динамически переключаться между ними в любой момент. Контент, созданный в первую очередь для сети, может быть легко сохранен для оффлайнового использования как «цифровая публикация» (любимый DP термин), и обратно без каких-либо трудозатратных действий по рефакторингу или оптимизации. Издатели и пользователи получат возможность использовать оба или выбирать из этих режимов. Таким образом декларируется, что цифровые публикации должны стать полноценным подмножеством Open Web Platform.

Единственным существенным различием между EPUB и web на взгляд авторов манифеста является целостность (completeness) «пакета» данных. В случае с EPUB система чтения может быть уверена, что все данные в таком пакете содержат нужные свойства, подчиняются определенной спецификацией иерархии и удовлетворяют требованиям консистентности.

В свою очередь, это позволяет иметь один стандартный подход и к обработке контента, и к его воспроизведению. Эта целостность как ограничение — ключевое отличие текущего онлайн-представления от оффлайнового (portable view).

Очевидно, что работа по внедрению этой концепции потребует существенного понижения и упрощения требований к сложности чтения контента браузерами.

Издателям

Отмечается, что раньше издатели не были вовлечены столь сильно в ИТ процессы, и от многих это потребует налаживания новых процессов по взаимодействию с принципиально иными профессиональными сообществами и парадигмами. Тем не менее, этот же вектор развития приведет к развитию принципиально новых подходов к контенту и инструментам. В особенности в STM-издательствах (Science, Technics, Medicine), где специфичность контента велика: аудио, графики, формулы, результаты исследований в специфических форматах — все это может стать частью интегрального подхода к цифровой печати.

Примечательно, что авторы рассматривают такой подход как подходящий для применения и в закрытом документообороте — внутренние технические спецификации и тд и тп.

Разработчикам систем чтения (reading systems)

Им также будет легче, тк в EPUB 3 используется достаточно широкий набор технологий парадигмы OWP, и, более того, системы чтения часто полагаются на такого рода реализации уровня браузерного ядра. Предполагается, что это будет зафиксировано документально и даст существенный прирост пользовательской базе и сообществу разработчиков.

Веб-дизайнерам

Синергетический эффект от взаимодействия между традиционным книгоиздательским сообществом и веб-дизайнерским приведет к значительному улучшению UI/UX. Кроме того, повысит качество адаптации к различным средам выполнения (очевидно, что объем опыта веб-сообщества в этих вопросах также на порядок больше аналогичного в DP).

Браузеры

Предполагается, что использование «пакетного» подхода снимет ряд ограничений уровня браузерного взаимодействия. Например, в случае узких каналов, предварительно скачанный пакет/архив с контентом, позволит не зависеть далее от сети. Сюда же стоит добавить возможное ad-hoc взаимодействие между пользователями. В целом, этот пункт следует  в фарватере работы над архивным форматом упаковки контента (см. «Специализированный архивный формат»).

Библиотекам и архивным сервисам

Целостность и использование компрессии EPUB-WEB документа играет значительную роль для повышения привлекательности формата как архивного и библиотечного.

Рядовым пользователям

У пользователя будет выбор использования одного и того же контента на множестве устройств: начиная от специализированных и заканчивая любимым браузером. Издателю же не придется выбирать за пользователя. Тот же самый контент может плавно мигрировать между системами со всей пользовательской метаинформацией, вроде заметок и закладок.

Обратная совместимость

EPUB-WEB, вероятно, не будет обратно-совместимым с EPUB3. Однако, непосредственно контент уже выполнен на базе ядра OWP-технологий: HTML, CSS, SVG, Javascript etc, что позволяет снизить издателям трудозатраты на внедрение. Основная часть изменений затронет уровень упаковки, структурных описаний и метаданных публикаций. Те издательства, которые уже вложились в переход с EPUB 2 на 3 так или иначе окажутся впереди.

Специализированный архивный формат

На мой взгляд, едва ли не самая интересная часть документа. Существует определенное количество форматов для оффлайнового архивного хранения документов и описания упаковки цифровых публикаций — OCF, ODF, OOXML. При этом ни один из них не является универсальным и поддерживаемым повсеместно в DP-экосистемах. EPUB-WEB же нуждается в нативном для классического веба формате архивирования. При этом стоит отметить, что мы имеем дело с достаточно специфическими нуждами, что должно быть покрыто расширением такого базового  generic-формата.

Не менее важным в достижении интероперабельности является описание процесса перехода публикации от онлайн к оффлайн представлению и наоборот.

W3C Web Application Working Group недавно опубликовала документ со статусом First Working Draft для Streamable Package Format for the web (web -packaging). Что опять же, на мой взгляд, является технологически революционным и для глобальной сети. Этот документ содержит описание формата упаковки веб-приложений (RIA) для локальной загрузки и выполнения. Хотя, возможно, он и не будет принят за основу, и придется искать иные пути решения.

Структура цифровых публикаций

EPUB3 уже содержит в себе определения базовых технологий для решения вопросов со структурами данных — JSON, XML, (x)HTML. Уже сейчас ясно, что все имеющиеся реализации придется сильно оптимизировать для нужд EPUB-WEB в контексте OWP.

Здесь, кстати, приводится интересный пример с одностраничной публикацией, которая, вероятно, станет самым распространенным случаем: EPUB-WEB должен иметь набор описания всего пакета по умолчанию  (spine, manifest etc), чего нет в текущем формате EPUB3.

Идентификация документа и фрагментов

В глобальной сети HTTP URI служит базовым методом идентификации ресурса или его фрагмента. В переносимых (portable) цифровых публикациях нет никакого эквивалентного метода, тк по определению оффлайновая публикация не обладает никаким HTTP адресом. Имеющаяся внутренняя спецификация для определения фрагментов (CFI) и их местоположения в документе так же не подходит для этих целей.

EPUB-WEB должен будет определить способ, каким образом использовать URI для идентификации фрагментов и документов в сети, так чтобы не вносить изменений в уже имеющуюся схему. Возможно, будет иметь смысл использовать спецификацию W3C Media Fragments (media-frags) в части случаев. Здесь пока больше вопросов, чем ответов.

Обнаружение метаданных

Необходимо определить синтаксис для инлайновых мета-данных. О чем речь: необходим механизм, определенным образом размечающий контент и делающий его машиночитаемым — поисковики, архивные системы крайне в этом нуждаются. В принципе, сам HTML в базе уже позволяет это делать — RDFa и/или Microdata для метаданных вроде заголовков и авторов. Отмечается, что это помогло бы в тч качественнее поддерживать i18n (интернационализация), чем использование JSON или XML.

Стилизация, лэйауты и пагинация

К сожалению, OWP в целом и CSS частности страдают отсутствием решений в части ожиданий сообщества книгоиздателей в вопросах типографики, лэйаутов и прочего. Очевидно, что нативная поддержка постраничного представления рассматривается как критическая функциональность. Текущая спецификация EPUB не определяет этого для reflowable-контента, хотя определенные попытки были в экспериментах по созданию спецификации EPUB Adaptive Layout (PGT).

Безопасность и политики защиты контента

Модель защиты контента глобальной сети в  интересующей нас части базируется на same-origin policy (CORS), которая в свою очередь не применима к переносимым (portable) документам. С другой стороны, господствующая концепция защиты EPUB-контента основана на предположении, что к контенту применяется некоторая внешняя проприетарная DRM-технология. Очевидно, что нужно будет искать компромиссное решение как для онлайн, так и для оффлайн случаев.

Контроль представления и персонализация

Персонализация — первейший механизм необходимый при чтении длинных произведений. Технологии вроде CSS Media Queries прекрасно зарекомендовали себя  в части адаптации контента к различным устройствам, однако, это не то же самое, что персонализация. Управление представлением не описано системно и не имеет документального «фреймворка» под собой. В настоящий момент каждый разработчик берет на себя самостоятельно разработку концепции и реализации такого рода функционала. Очевидно, что EPUB-WEB должен включать в себя такого рода документ.

Перенос контента между сервисами

Разные системы воспроизведения контента могут иметь отличающиеся представления о воспроизведении: pre-paginated, reflowable, image-based и тп. Наличие профилей (profiles) по умолчанию позволило бы избежать недостаточного описания документа при его попадании в среду, где принят иной тип воспроизведения. Добавления в юзер агент специальных правил позволило бы запускать «улучшенное» поведение системы воспроизведения в пределах заданного домена без риска нарушить целостность и функциональность базовой публикации.

EPUB 3.1 чего ожидать

Media

  1. Вероятно, будет выбран формат 3d
  2. Тем, кто сильно зависим от спека Media Overlays в части использования функционала текст-аудио, поможет включение оптимизированных speech-кодеков в качестве Core Media Type из опций — AMR/3GP, OPUS & USAC.

Scripting

Вызов и выполнение скриптов при push или удаленных запросах — довольно рядовая LTI (Learning Tools Interoperability) функицональность, например: LMS (Learning Management System) отправляет оценку результата выполнения задания внутри E(DU)PUB.

Open Web Platform Alignment

  1. Сериализация HTML
    Лично мне не нравится использование термина «сериализация», когда речь идет всего лишь об XML-нотации и нескольких сомнительных инкостылированных соглашениях (подробнее можно ознакомиться на html5docor, а также посмотреть «спек» polyglot markup). Бытует мнение, что использование HTML5 в xHTML нотации неуклонно снижается и количество инструментов, требующих подобного также аналогично. Собственно, предложение касается возможности использование обеих нотаций внутри EPUB 3.1.
  2. Уход от @epub:type к @role — в принципе логичное движение в контексте предыдущего пункта и парадгимы OWP
  3. Возврат OCF File System Container как сервер-ориентированной манифестации. OCF 2.0.1 File System Container был удален в OCF 3.0 с предложением вернуться к нему в будущем. Ноги растут также из OWP и его манифестации в свежеиспеченном EPUB-WEB

Media overlays

  1. Возможность пользовательского определения text-audio синхронизации (сейчас жестко определяется издательством)
  2. Поддержка функционала для слабослышащих (DAISY Consortium)

Package File

  1. Поддержка стилей для азбуки Брайля (в сотрудничествес W3C) и метаданные для определения кодов Брайля
  2. Дополнительные метаданные для режимов представления навигации, например для стандартного UI-решения постраничной навигации слайдером.
  3. Добавление кастомных атрибутов по принципам определенным в EPUB 3.0.1 Content Documents

И самая моя любимая часть — @deprecated

Почти все касаются задач, которые прекрасно решаются или стандартными средствами JS или HTML.

  1. epub:switch ненужный инлайновый фолбэк
  2. epub:trigger аналогичная история
  3. Кастомные биндинги

Включение дополнительных спецификаций (ориг. modular specifications)

  1. Region-based Navigation (кстати, пока в статусе proposal) — тип навигации для графического контента, главным образом, комиксов и прочих графических изданий.
  2. Multiple Renditions (proposal) — спецификация определяющая документы, с вариативностью рендера (язык, тип контента, FXL, reflowable etc).
  3. EPUB Previews (proposal) — спек, определяющий, каким ообразом создавать демо-версии контента (например, в маркетинговых целях), и каким образом связывать их с полной публикацией.
  4. EPUB Scriptable Components — включает драфты двух спецификаций — API и Packaging and Integration
  5. Open Annotations — имплементация стандарта аннотирования по W3C Open Annotation

Ну, и багфиксы.

Twitter Bootstrap в государственных проектах

Очень здорово увидеть Twitter Bootstrap в проекте http://parkingcab.mos.ru. Судя по некоторым признакам, там еще использовался boilerplate.

И это радует. В отличие от http://pgu.mos.ru, этот ресурс действительно хорошо выглядит и  работает в мобильных устройствах.

Приложение для оплаты парковки в Москве

Департамент информационных технологий города Москвы выпустил приложение для оплаты парковки в Москве.

Для пользования, нужно зарегистрироваться на сайте http://pgu.mos.ru

Затем перейти на сайт https://parkingcab.mos.ru, где вам будет предложено ввести номер телефона и пин-код, которые потом можно будет использовать в мобильном приложении для авторизации.

С хорошим все понятно (риспект и уважуха), а теперь немного критики:

1) На https://parkingcab.mos.ru попасть весьма непросто. Попал случайно нажав на кнопку «Личный кабинет» на странице http://parking.mos.ru/search_map/ внизу. Ожидал, кстати, что попаду в личный кабинет pgu.mos.ru, но через несколько редиректов был выведен на parkingcab.mos.ru

2) Невозможность авторизации через стандартную пару login/password из pgu.mos.ru — обязательно нужно провязать мобильный телефон. В принципе понятно, чем это вызвано, но ввиду пункта 1 сделать это не очень удобно.

Открытые ГИС!


Конференция для пользователей и разработчиков ГИС с открытым исходным кодом 17—18 ноября 2012 года.

Пройдет в Московском конгресс-центре Измайлово-Альфа по адресу м.Партизанская, Измайловское ш., д.71, корп.А

Очень интересной должна быть секция OpenStreetMaps и веб-гис.
 

Заставят делиться картоосновами?

4 мая 2012г. прошла встреча между Минэкономразвития и ОПТС с целью

создать рабочую группу для решения вопросов в отрасли геодезии и картографии, связанных с использованием новых форматов частно-государственного партнерства

Настораживает конец новости

Наибольший интерес в ходе обсуждения вызвали вопросы об использовании частного капитала при создании космических аппаратов дистанционного зондирования земли (ДЗЗ), мониторинга и развития Государственных геодезических сетей (ГГС), а также создании открытого фонда готовых цифровых картографических материалов подготовленных коммерческими организациями с возможностью их передачи заинтересованным лицам установленным порядком.

Интересно, как заставят делиться, игнорируя защиту интеллектуальной собственности и авторское право.