Организация CIP4 разработала стандарт JDF для автоматизации производственных процессов в печатной индустрии. Давайте подробнее рассмотрим сам формат и сегодняшнее состояние стандарта JDF.
XSLT *
Язык преобразования XML-документов
Новости
DesktopETL — кросс-платформенный прототип ETL-системы, или как регулярно загружать XML/JSON и сохранять в XLS/CSV
Идея моего домашнего проекта началась с простой, на первый взгляд, задачи: с потребности конвертировать файлы формата XML в формат XLS (или CSV) для последующего анализа. И я был наивен, чтобы попробовать решение «в лоб» и с помощью Excel импортировать богатый внутренний мир SAP Business Objects, описанный в иерархической структуре XML, в табличную форму, — и примерно через час мое сознание, в очередной раз выдав исключение о переполнении памяти, подключило опыт, который намекнул, что иерархические структуры заранее неизвестной глубины проще всего обрабатывать посредством рекурсии. Так появился лаконичный скрипт на Python. Потом еще один. И еще. Потом скрипты пошли в массы среди коллег по цеху. Появились фантазии и мечты, например возможность каждые пять минут забирать XML (или JSON) из кафки (Apache Kafka), трансформировать на лету и класть, например, в DWH. Вполне ожидаемо, что была масса вопросов к скриптам и просьба «быстренько поправить». И в какой-то момент, как в том классическом анекдоте про «закопанную стюардессу», я понял, что хватит… Так и появился MVP, который я хотел бы представить в этой статье.
Проверка XML. Schematron
Так или иначе, все сервисы сталкиваются с задачами валидации. Часто они сводятся к простым и однотипным проверкам: заполнены ли все обязательные поля, верен ли формат телефонного номера, кредитной карты и пр. Но существуют проекты, в которых условия и правила проверок более разнообразные, да и те временами требуют серьёзного пересмотра. Внесение же изменений или создание дополнительных правил валидации требует непростых согласований и привлечения внимания нескольких команд разработчиков, обновления документации.
Недавно мне довелось поучаствовать в проекте, особую роль в котором занимают функции форматно-логического контроля входящих документов. Как следствие, у меня появились некоторые варианты решения подобных задач. Одним из них я и хочу поделиться.
Автоматическая генерация технической документации
Продолжая тему использования Asciidoc (и других аналогичных форматов) для организации процессов непрерывного документирования, хочу рассмотреть тему автоматический генерации технической документации.
Автоматическая генерация документации — распространенный, но очень расплывчатый термин. Я понимаю под этим термином извлечение для представления в удобном виде информации, содержащейся в исходном коде и настройках документируемой программы (информационной системы).
Истории
Прогрессивная загрузка XML страниц
Прогрессивная загрузка XML страниц — это загрузка с одновременным показом уже загруженных и обработанных частей XML страницы пока XSLT шаблон всё ещё обрабатывает остальные части.
У нас есть очень большой XML. Это статья с очень большим количеством комментариев. На медленном и нестабильном мобильном интернете её загрузки можно и не дождаться. Во время загрузки случается обрыв связи и XML остаётся не догруженным. Казалось бы можно просто обновить страницу и браузер бы просто догрузил недостающую часть. Но нет. Браузер грузит страницу заново и снова это не удаётся и мы видим ошибку вместо страницы.
Но выход из этой ситуации есть. Мы разделим XML на маленькие кусочки которые будут успевать загрузиться на медленном канале и попадут в кеш. Бонусом мы получаем защиту от недогруза и прогрессивную загрузку.
Межпланетная файловая система — Простой блог в IPFS при помощи XSLT
Существует проблема: У сайта в IPFS нет возможности использовать серверные скрипты для формирования страницы. Если использовать генерацию страниц перед загрузкой то добавив новый пункт меню в каждую страницу мы изменим хеш этих страниц. Так что всю сборку страниц нужно производить силами браузера.
Обычно формируют содержание страниц при помощи JavaScript. Это знакомая технология но у неё есть свои недостатки.
Я буду использовать XSLT. Это древняя технология шаблонов которая давно встроена в браузеры но мало кто ей пользуется. Возможно потому что шаблоны заставляют писать много текста и из за путаницы с пространствами имён и множества ошибок без внятного объяснения. Также не смотря на то что есть уже XSLT 3.0 в браузерах по прежнему доступен только XSLT 1.0.
XSLT работает так:
- Пользователь открывает в браузере XML документ.
- В заголовке XML документ содержит ссылку на XSLT шаблон.
<?xml-stylesheet href="xslt/запись.xslt" type="text/xsl" ?>
- Шаблон в браузере на основе XML документа и других данных формирует xHTML документ.
- Браузер отображает полученный xHTML документ.
Привязав множество страниц к одному шаблону можно менять отображаемый xHTML документ не меняя XML документы. Таким образом при смене дизайна не будет меняться хеш XML документов а значит старые их копии будут источниками для новых в IPFS.
Для поисковиков в данном способе тоже есть плюсы. Они ограничиваются обработкой XML документа получая только уникальный контент страницы без элементов навигации и остальных блоков которые повторяются на каждой странице.
Интерактивная игра на XSLT
Когда-то давным-давно придумали люди язык XML и увидели, что это хорошо. И стали использовать его везде, где можно, и даже там, где не следует. Форматы хранения и передачи данных, конфиги, веб-сервисы, базы данных… Казалось, оглянись вокруг — XML, XML повсюду. Время прошло, люди одумались, насочиняли разных других форматов данных (или спрятали XML внутри архивов) и XML-безумие как-бы приутихло. Но с тех славных пор практически любая система умеет в XML и интегрировать такие системы (кто сказал Apache Camel?) лучше и проще всего, используя XML-документы.
А где XML, там и XSLT — язык, предназначенный для преобразования XML-документов. Язык этот специализированный, но обладает свойством полноты по Тьюрингу. Следовательно, язык пригоден для «ненормального» использования. Вот, например, существует решение задачи о 8 ферзях. Значит, можно и игру написать.
Для нетерпеливых: рабочая программа на JSFiddle, исходники на GitHub.
Семантическая разметка: LaTeX, DocBook или ???
Как многие отмечают там в комментариях статья отстой, человек не разбирается и смешал всё в кучу, попробую поделиться своими выводами от использования разных разметок.
Как я разбирал docx с помощью XSLT
Задача обработки документов в формате docx, а также таблиц xlsx и презентаций pptx является весьма нетривиальной. В этой статье расскажу как научиться парсить, создавать и обрабатывать такие документы используя только XSLT и ZIP архиватор.
Генерация автоматических тестов: Excel, XML, XSLT, далее — везде
Проблема
Есть определенная функциональная область приложения: некая экспертная система, анализирующая состояние данных, и выдающая результат — множество рекомендаций на базе набора правил. Компоненты системы покрыты определенным набором юнит-тестов, но основная «магия» заключается в выполнении правил. Набор правил определен заказчиком на стадии проекта, конфигурация выполнена.
Более того, поскольку после первоначальной приемки (это было долго и сложно — потому, что “вручную") в правила экспертной системы регулярно вносятся изменения по требованию заказчика. При этом, очевидно, неплохо — бы проводить регрессионное тестирование системы, чтобы убедиться, что остальные правила все еще работают корректно и никаких побочных эффектов последние изменения не внесли.
Основная сложность заключается даже не в подготовке сценариев — они есть, а в их выполнении. При выполнении сценариев “вручную", примерно 99% времени и усилий уходит на подготовку тестовых данных в приложении. Время исполнения правил экспертной системой и последующего анализа выдаваемого результата — незначительно по сравнению с подготовительной частью. Сложность выполнения тестов, как известно, серьезный негативный фактор, порождающий недоверие со стороны заказчика, и влияющий на развитие системы («Изменишь что-то, а потом тестировать еще прийдется… Ну его...»).
Очевидным техническим решением было бы превратить все сценарии в автоматизированные и запускать их регулярно в рамках тестирования релизов или по мере необходимости. Однако, будем ленивыми, и попробуем найти путь, при котором данные для тестовых сценариев готовятся достаточно просто (в идеале — заказчиком), а автоматические тесты — генерируются на их основе, тоже автоматически.
Под катом будет рассказано об одном подходе, реализующим данную идею — с использованием MS Excel, XML и XSLT преобразований.
SSI сайт: HTML, XML, XSLT
Достопочтенное Ретро! Благо ты или зло?
Вздохом какого ветра к нам тебя занесло?
© Роберт Рождественский
Есть вещи, которые просто нравятся, их приятно держать в руках, они просты, они понятны. Время их расцвета ушло, но сами они не канули в лету, и к ним возвращаются снова и снова. Это касается не только предметов материального мира. Всегда найдётся программист, которому интересно писать на ассемблере, или прямо в машинных кодах, любитель простоты, минимализма, ретро. Попробуем вернуться к SSI, благо, это и проще ассемблера, и значительно моложе.
Angular XSLT module
Этот вопрос и явился причиной того, что я решил написать данную статью.
Итак, разрешите представить вашему вниманию «химеру» под названием Angular XSLT module. Ангулар разделяет business логику и view логику, но с модулем XSLT, view логику Angular можно вообще отдать XSLT.
Есть конечно пара подводных камней, это:
1) Результат не будет рендерится,
2) Angular команды не будут вызываться.
Но легким движением руки, эти проблемы решаются на раз-два!
Публикация DITA в PDF с использованием DITA Open Toolkit. Разметка страниц — обзор layout-master
Использованы материалы книги «Dave Pawson, XSL-FO — Making XML Look Good in Print, 2002».
Ближайшие события
Публикация DITA в PDF с использованием DITA Open Toolkit
Пишу в DITA. В качестве редакторов попробовал Adobe FrameMaker и oXygen. В качестве выходного формата использую PDF. В целом, базовый шаблон вполне удовлетворяет. Однако, есть желание доработать его, например, под требования ГОСТ. В связи с этим начал изучать технологию публикации DITA в PDF. Своими изысканиями решил поделиться с коллегами по цеху в данной и в дальнейших статьях. Итак…
Dagaz: Вновь об XSLT
PHPStamp — честная генерация DOCX документов из шаблона
Задача состояла именно в генерации шаблона для многократного использования, который не придется править вручную или прибегать к сторонним программам для его доработки.
PHP-расширение dom_varimport: быстрое преобразования вложенных массивов в DOMDocument
Но сейчас речь не о преимуществах и недостатках XSLT (я уверен, и противники, и сторонники этой технологии найдутся в изобилии). Я бы хотел описать один прием, который удобно применять в существующих проектах с XSLT-шаблонами, и привести ссылку на библиотеку, реализующую данный прием с хорошей производительностью.
Передаем данные в XSLT, минуя генерацию текстового представления XML
Представьте, что у нас есть контроллер, генерирующий некоторый вложенный PHP-список объектов для отображения на странице. Он должен этот массив преобразовать в XML, который потом пойдет на вход XSLT-шаблону. Хорошо бы, чтобы данное преобразование из структур PHP в XML выполнялось не вручную в каждом контроллере, а был некоторый промежуточный слой абстракции, который умеет применять XSLT-шаблон прямо к PHP-данным, минуя текстовое XML-представление. Так мы уменьшим вероятность ошибок, да и письмо сократится. Мы сможем работать с XSLT-шаблонами напрямую, минуя XML-представление данных.
Некоторое время назад я написал на Си PHP-расширение dom_varimport (также выложено на GitHub). Оно содержит одноименную функцию, на вход которой подается объект DOMDocument и PHP-массив любой вложенности. Функция заполняет переданный ей DOMDocument XML-представлением входного массива, и делает она это очень быстро — примерно в 20 раз быстрее, чем делал бы код, написанный на чистом PHP. Большой документ размером около 1 МБ с тысячами вложенных свойств и объектов формируется примерно за 1-2 миллисекунды.
Например, вызов:
Xalan, Saxon и 8 ферзей
Сегодня я хочу рассказать об XSLT. Этот, весьма своеобразный, язык может оказаться очень полезным в тех случаях, когда требуется обработать XML-данные, сколь нибудь не тривиальным образом. Я расскажу о двух наиболее популярных (в среде Java-разработчиков) реализациях XSLT-процессора, подробно остановлюсь на вопросах их использования из Java-кода и попытаюсь сравнить их производительность. В качестве теста для сравнения производительности, я буду использовать широко известную задачу о расстановке 8-ми ферзей на шахматной доске.
Поскольку решение подобных задач, с использованием XSLT вряд ли можно отнести к категории нормальной деятельности, топик помещен в соответствующий раздел. В то же время, я надеюсь, что эта статья будет полезна, в качестве учебного материала.
Импорт KeePass БД паролей в KWallet
На предприятии где а работаю очень любат всякие штучки для «безопасности» и к сожалению все по винду. Но вот незадача, у меня стоит линукс а мне прислали пароли в БД для KeePass (заметка: не хочу ставить mono приложение KeePass под линукс). Windows виртуальная машина стоит, но держать ее открытой всегда не охота, всетаки память отъедает которой и так не хватает. Вот тогда-то у меня и родилась идея перенести все пароли из этой базы данных для KeePass в мой KWallet.
JAXB и XSLT с использованием StAX
Причем выдернуть надо было только некоторые тэги с расположенные на различной «глубине». XSLT «в лоб» ломался от недостатка памяти. Пришлось подумать и вспомнить о потоковом парсере.