Hacker News Digest

Страница XSLT.RIP объявляет о смерти технологии XSLT, обвиняя в этом Google. На минимальной веб-странице всего три строки: заголовок "Если вы это читаете, XSLT был убит Google" и два коротких соболезнования. Это мемориальная страница, созданная в знак уважения к технологии, которая, по мнению автора, прекратила свое существование из-за действий Google.

Страница оформлена в виде простого XML-документа с XSLT-стилем, что создает ироничный контент. Несмотря на скудность информации, это явный протест против прекращения поддержки XSLT, технологии, которая долгое время использовалась для преобразования XML-документов. Фраза "Rest in peace" (Вечная память) подчеркивает, что автор рассматривает это как окончательную кончину технологии, а не просто изменение в политике поддержки.

• Google не «убивает» XSLT, а лишь прекращает поддержку в браузере, что вызывает споры о том, насколько это технически оправдано.
• Сайт xslt.rip использует нарочито ретро-дизайн, чтобы подчеркнуть иронию ситуации, но это вызывает споры о том, насколько это уместно.
• Обсуждение поднимает вопрос о том, что XSLT всё ещё используется в медицинских записях и других нишах, где XML по-прежнему важен.
• Некоторые участники считают, что Google просто не хочет вкладывать ресурсы в поддержку устаревших стандартов, в то время как другие считают, что это естественный процесс устаревания технологий.

После четырёх лет разработки Stalwart представил полную реализацию JMAP для календарей, контактов, адресных книг, хранения файлов и обмена. Это делает Stalwart первым сервером JMAP, поддерживающим всю семью протоколов совместной работы, открывая новую эру для открытого и эффективного группового ПО. Новые стандарты включают JMAP для Календарей (замена CalDAV), Контактов (альтернатива CardDAV), Файлов (замена WebDAV), а также JSCalendar и JSContact — современные JSON-версии iCalendar и vCard.

JMAP решает проблемы устаревших технологий, предлагая вместо громоздкого XML и несовместимых форматов простые, последовательные API поверх JSON. Протоколы обеспечивают лучшую производительность, простоту реализации и надёжность. Эта реализация знаменует сдвиг в проектировании ПО для совместной работы, позволяя разработчикам строить на единой, когерентной платформе. Поддержка клиентов пока развивается, но такие проекты, как Mailtemi и Parula, уже работают с новыми стандартами.

• Stalwart — первый сервер с полной поддержкой JMAP, но документация и UX оставляют желать лучшего, что затрудняет его внедрение.
• JMAP-совместимые клиенты всё ещё отсутствуют, что делает внедрение Stalwart сложным для конечных пользователей.
• Отсутствие клиентов и серверов, поддерживающих JMAP, затрудняет внедрение, даже если Stalwart технически превосходит IMAP и CalDAV.
• Сообщество обсуждает, что для внедрения JMAP нужно как минимум один из: либо крупный провайдер (Gmail, Fastmail) начнёт поддерживать его, либо Thunderbird и другие клиенты добавят поддержку.

Поисковик Marginalia запустил пилотную программу с экспериментальной поддержкой немецкого, французского и шведского языков. Ранее система была ориентирована исключительно на английский, и её код содержал англоцентричные допущения. Поддержка всех языков одновременно невозможна из-за их фундаментальных различий: японский требует специальной нормализации из-за нескольких алфавитов и отсутствия пробелов между словами, а латинский имеет десятки форм каждого слова с гибким порядком слов.

Система обработки языка включает несколько этапов: извлечение текста, определение языка, разбиение на предложения, нормализацию Unicode, стемминг, POS-теггинг и извлечение ключевых слов. Основные проблемы включают несовершенство стемминга (например, "universe" и "university" считаются одинаковыми), культурные различия в нормализации (например, "tröjan" и "trojan" в шведском) и проблему начальной загрузки для TF-IDF в новых языках. Для решения используется конфигурируемый XML-файл с языковыми настройками и грамматическими паттернами.

• Обсуждение показало, что Marginalia не только индексирует, но и предоставляет API и поисковые виджеты для сторонних проектов.
• Участники обсудили возможность интеграции Marginalia в качестве поискового бэкенда для сайтов-агрегаторов, подобно тому, как HN использует Algolia.
• Разработчик Marginalia упомянул, что работает над фильтрацией по доменам и скоро выпустит публичный API.
• Также обсуждались детали реализации: RDRPOSTagger используется для POS-теггинга, но с оптимизациями, чтобы ускорить обработку.
• Участники отметили, что Marginalia — это не только поисковый движок, но и инструмент для поиска по собственным закладкам и комментариям.

В Kotlin-компиляторе скрыта ошибка, срабатывающая при сборке проекта в турецкой локали. Из-за неё при попытке скомпилировать код в турецкой локали возникает ошибка парсинга XML от компилятора: строчка var category: CompilerMessageSeverity? = CATEGORIES[qName.toLowerCase()] в функции CompilerOutputParser некорректно обрабатывает турецкий символ I (U+0049), который при приведении к нижнему регистру становится не i (U+0069), а ı (U+0131) — точкой надстрочного i без точки. Из-за этого ключ i не находится в словаре CATEGORIES, и код ошибочно считает, что это неизвестный тег, и выдаёт сообщение об ошибке.

Ошибка скрывалась в коде с 2016 по 2021 год, пока не была обнаружена и исправлена. Теперь код корректно использует локально-независимый toLowerCase(Locale.ROOT), и проблема решена. Это яркий пример того, как тонкости локализации могут вызывать ошибки в интернационализированном ПО, особенно при обработке текста.

• Проблема "турецкое I" встречается везде, где не указывается локаль при работе со строками, и это приводит к багам, когда вместо "I" в турецкой локали превращается в "ı" (без точки) и наоборот.
• Современные языки и фреймворки должны предоставлять единообразные и предсказуемые API, но вместо этого они вынуждают разработчиков указывать локаль каждый раз, что приводит к ошибкам.
• Пользователи с турецкой локалью страдают от багов, которые не могут быть обнаружены автоматически, потому что большинство разработчиков тестируют только на английской локали.
• Это также является примером более широкой проблемы: API-функции, которые не принимают Locale параметр, вместо этого полагаясь на дефолтной локали, что может привести к ошибкам.

Эксперимент показал, что формат данных существенно влияет на точность понимания таблиц LLM. Лучший результат показал Markdown-KV (key-value пары в markdown) с точностью 60,7%, но он потребовал в 2,7 раза больше токенов, чем самый экономный CSV. XML и INI также показали высокую точность (56% и 55,7%), тогда как CSV и JSONL оказались наихудшими — около 44%. Это указывает на возможность улучшения RAG-пайплайнов простой сменой формата данных, хотя эффективность часто требует компромисса с количеством токенов.

• Результаты тестирования GPT-4.1-nano показали, что точность извлечения данных из таблиц варьируется от 40% до 60% в зависимости от формата, при этом Markdown-KV показал наилучший результат.
• Многие участники раскритиковали методологию исследования, указав на использование только одной, слабой модели (GPT-4.1-nano) и недостаточный размер данных для оценки влияния контекстного окна.
• Было высказано сомнение в практической целесообразности использования LLM для обработки табличных данных, учитывая доступность более точных и эффективных традиционных инструментов (например, Python-скриптов, SQL).
• В качестве альтернативы предложены агентные подходы, где LLM генерирует код (например, SQL-запросы или функции) для последующего выполнения, что показало высокую эффективность в реальных задачах.
• Обсуждались потенциально более эффективные форматы данных (XML с короткими тегами, TOML, KSON) и необходимость тестирования на более мощных моделях (GPT-5, Claude, Gemini) для получения репрезентативных результатов.

Я ухожу с поста сопровождающего libxml2, поэтому проект временно остаётся без поддержки.

До конца 2025 года я буду исправлять регрессии в релизе 2.15.

Спасибо за вашу тяжёлую работу!

Спасибо за долгое сопровождение libxml2!

Я изучаю код libxml2 и libxslt. У меня есть время на поддержку, но нужно разобраться с последними изменениями, например, с управлением буферами ввода-вывода. Как лучше связаться для вопросов?

Спасибо за поддержку ключевых библиотек интернета, используемых в миллионах продуктов по всему миру. Удачи!

От лица миллионов пользователей благодарю за вашу работу!

• Основной сопровождающий libxml2, Nick Wellnhofer, уходит после десяти лет неоплачиваемой работы и форкает проект под лицензией AGPL.
• Сообщество обсуждает кризис поддержки критически важной инфраструктуры из-за проблем с финансированием open-source.
• Поднимается вопрос о чрезмерной сложности XML и необходимости больших библиотек вроде libxml2; предлагаются более минималистичные альтернативы (например, TinyXML2, libexpat).
• Упоминается спорная политика безопасности libxml2 «без эмбарго», что вызывает обеспокоенность по поводу будущих уязвимостей.
• Обсуждается бизнес-модель продажи исключений из GPL для коммерческого использования как потенциальное решение для поддержки.
• Отмечается упадок XSLT из-за проблем с libxml2 и планы по удалению его поддержки из браузеров.
• Высказывается мнение, что сложные стандарты вроде XML с большими RFC являются неустойчивыми и что при выборе технологий следует учитывать простоту поддержки.

Как RSS победил Microsoft

Корпоративные гиганты пытались монополизировать контент-синдикацию, но проиграли простому формату.

ICE vs RSS: закрытость против открытости

В 1998 году Microsoft, Adobe, CNET и другие запустили спецификацию ICE — дорогой, сложный и закрытый стандарт для лицензирования и перепубликации контента. ICE обещал издателям контроль и монетизацию, но требовал $50 000 за сервер и поддержку консорциума.

RSS появился в 1999 как бесплатный XML-виджет на портале My Netscape: любой блоггер мог добавить ленту обновлений в общий список «каналов». Формат был проще, короче и не требовал денег.

Деньги vs массы

ICE продавали крупным издателям: Reuters, Vignette, iSyndicate. RSS раздавали бесплатно: первые агрегаторы Headline Viewer и my.userland.com запустились без бюджета и без лицензий. Пока консорциум взимал плату, тысячи блоггеров уже создавали ленты в блокноте.

Итог

К 2005 году ICE умер: дорого, сложно, никто не пришёл. RSS стал воздухом: читалки, подписки, podcast-фид. Победил не потому что был лучше технически, а потому что был открытым и бесплатным.

• RSS удобен читателям, но не выгоден издателям: в ленту сложно встроить рекламу и отследить аудиторию.
• Пользователи по-прежнему цепляются за RSS: уходят с платформ, которые его убрали (Twitter, Reddit), и сами собирают фиды.
• Google Reader убил, а не стандарт: после закрытия сервиса ленты исчезли, но подкасты, XKCD, Microsoft-фиды живы.
• Технически RSS «мёртв» 15 лет, по факту — нишевой, но стабильный инструмент; альтернативы (ICE, ActivityPub) не прижились.
• Новые идеи: RSS-газета на бумаге, JSON-лента, почтовые ящики внутри ридеров — всё решает те же старые проблемы монетизации и курирования.

Если бы OpenDocument использовал SQLite

Мысленный эксперимент: заменить ZIP-контейнер в формате ODP на базу SQLite.
Плюсы: компактнее, быстрее открытие/сохранение, меньше памяти, встроенная версионность.

Текущий ODP

ODP-файл — это ZIP-архив с XML-файлами (content.xml, styles.xml, meta.xml, settings.xml) и папкой Pictures с ресурсами.
Пример: 49-слайдовая презентация — 78 файлов, 11 МБ.

Недостатки ZIP-контейнера

1. Сложное инкрементальное обновление
   При каждом «Сохранить» перезаписывается весь архив, что медленно и «съедает» ресурс SSD.
2. Медленный старт
   При открытии нужно распаковать и распарсить большой XML.
3. Отсутствие версионности
   Нет простого способа хранить историю изменений.
4. Избыточные данные
   Каждая картинка — отдельный файл, даже если она используется многократно.

Преимущества SQLite

• Инкрементальные изменения
  Обновляются только нужные строки; сохранение происходит мгновенно и безопасно (благодаря транзакциям).
• Мгновенный старт
  Данные уже структурированы; нет необходимости распаковывать и парсить XML.
• Встроенная версионность
  Таблицы slide_history, image_versions позволяют откатываться к любому состоянию.
• Дедупликация ресурсов
  Один и тот же рисунок хранится единожды; ссылки через image_id.
• Сжатие и индексы
  SQLite сжимает данные и строит индексы по ключам (номера слайдов, идентификаторы объектов).

Схема SQLite-документа (упрощённо)

CREATE TABLE slides(
  slide_id INTEGER PRIMARY KEY,
  title TEXT,
  xml_content BLOB,
  z_order INTEGER
);
CREATE TABLE images(
  image_id INTEGER PRIMARY KEY,
  data BLOB,
  mime_type TEXT,
  sha256 BLOB UNIQUE
);
CREATE TABLE slide_images(
  slide_id INTEGER REFERENCES slides,
  image_id INTEGER REFERENCES images,
  x REAL, y REAL, width REAL, height REAL
);
CREATE TABLE history(
  change_id INTEGER PRIMARY KEY,
  timestamp DATETIME,
  sql BLOB
);

Итог

SQLite превращает «кучу файлов» в реляционную базу: быстрее, надёжнее, экономнее.
Это не предложение переделать ODP, а идея для следующих форматов.

• SQLite как формат файла приложений: удобен для запросов, хранит всё в одном файле, но требует осторожности с безопасностью и сетевыми ФС.
• Ключевые советы: включать secure_delete, не хранить больше 2 ГиБ в BLOB, избегать работы по сети без надёжных блокировок.
• Плюсы: SQL-запросы, простота API, лёгкость инспектировать и мигрировать данные (пример — Anki).
• Минусы: сложно версионировать бинарные вставки, проблемы синхронизации/коллаборации, перезапись всего файла при малом изменении.
• Альтернативы: разделение текста и бинарников, JSON + Git, XML для обмена, CRDT-структуры для офлайн-редактирования.

Ada в действии: рисуем розетки

Создадим консольную утилиту, генерирующую SVG-файл с анимированными розетками (гипотрохоидами, как в Spirograph™). Проект показывает, что Ada 2022 — не только для безопасно-критичных систем, но и для обычных задач.

Зачем Ada?

• Жёсткая проверка типов и компилятор как «партнёр».
• Читаемость вместо краткости, минимум неопределённого поведения.
• Отлично подходит для встраиваемых, авиа-, железнодорожных и автомобильных систем.

Как работает программа

1. Принимает параметры из командной строки.
2. Вычисляет координаты точек кривой.
3. Записывает XML-совместимый SVG.
4. Открывается в любом браузере без сторонних библиотек.

Структура проекта

rosetta/
├── alire.toml          # зависимости Alire
├── src/
│   ├── rosetta.adb     # точка входа
│   ├── svg.adb/.ads  # генерация SVG
│   ├── curve.adb/.ads # математика кривой
└── Makefile

Ключевые типы

type Point is record
   X, Y : Float;
end record;

type Rosetta_Params is record
   R, r, d : Float;  -- радиусы и смещение
   Steps   : Positive;
end record;

Генерация кривой

function Hypotrochoid(P : Rosetta_Params) return Point_Array is
   Result : Point_Array(1 .. P.Steps);
   Angle  : Float := 0.0;
   Delta  : constant Float := 2.0 * Pi / Float(P.Steps);
begin
   for I in Result'Range loop
      Result(I) := (
        X => (P.R - P.r) * Cos(Angle) + P.d * Cos((P.R - P.r) / P.r * Angle),
        Y => (P.R - P.r) * Sin(Angle) - P.d * Sin((P.R - P.r) / P.r * Angle)
      );
      Angle := Angle + Delta;
   end loop;
   return Result;
end Hypotrochoid;

Создание SVG

procedure Write_SVG(Path : Point_Array; Filename : String) is
   File : File_Type;
begin
   Create(File, Out_File, Filename);
   Put_Line(File, "<svg ...>");
   Put(File, "<path d='M");
   for P of Path loop
      Put(File, Float'Image(P.X) & "," & Float'Image(P.Y) & " ");
   end loop;
   Put_Line(File, "' stroke='black' fill='none'/>");
   Put_Line(File, "</svg>");
   Close(File);
end Write_SVG;

Сборка и запуск

alr build
./bin/rosetta --R 100 --r 40 --d 80 --steps 360
# открыть rosetta.svg в браузере

Что дальше

• Добавить CLI-парсер GNAT.Command_Line.
• Анимировать через <animate> в SVG.
• Портировать на микроконтроллер и выводить на дисплей.

Полный код: github.com/AdaCore/rosetta-ada-demo

• Пользователи просят чёткий список возможностей Ada, доступных бесплатно в GNAT, и тех, что требуют лицензию AdaCore; ответ: весь язык доступен в FSF-GNAT, а проприетарный вариант лишь обновляется чаще и сопровождается коммерчески.
• Участники вспоминают, что писали на Ada ещё в 90-е, отмечают приятный «паскалеподобный» синтаксис и интерес к новым фичам Ada 2022 и SPARK.
• Ada применяется в высоконадёжных системах (NVidia, автопром, проект Muen), но в коммерческой разработке её доля снизилась, уступив C/C++.
• Появились ресурсы для старта: learn.adacore.com, ada-lang.io и репозиторий awesome-ada.
• Обсуждается, помогут ли LLM вернуть Ada в мейнстрим: одни считают, что строгость языка полезна для проверки сгенерированного кода, другие — что LLM сделают все языки нишевыми.

GNU Artanis — первый production-ready веб-фреймворк на Scheme. Лёгкий, быстрый, с поддержкой JSON/XML/SXML, WebSocket, i18n, MySQL/SQLite/PostgreSQL, кэширования, шаблонов и статики.

(use-modules (artanis artanis))
(init-server)
(get "/hello" (λ () "hello world"))
(run #:port 8080)

Скачать

• GNU FTP
• GitLab

Документация
Официальное руководство

Исходники

• Savannah: https://savannah.gnu.org/projects/artanis
• GitLab: https://gitlab.com/hardenedlinux/artanis

История
2013 — рождение на hack-potluck Guile; 2014 — награда «Lisp In Summer Projects»; 2015 — первая стабильная версия и вступление в GNU; 2021 — переход под крыло HardenedLinux.

Контакты
Почта: artanis@gnu.org
GitLab: https://gitlab.com/hardenedlinux/artanis

• Участники обсуждают фреймворк Artanis для Guile Scheme: кто-то хвалит простоту синтаксиса и встроенный веб-сервер, кто-то жалуется на отсутствие CSRF, 404-ссылок и слабое tooling.
• Почему Guile не стал популярен? Недостаток LSP, отладки, туториалов и узкая аудитория.
• Название «Artanis» — отсылка к Sinatra (Ruby) и палиндрому «Sinatra» задом-наперёд.
• Сайт без JS и шрифтов выглядит чисто, но кто-то считает текст слишком крупным и структуру странной.
• По безопасности: при грамотных разработчиках Scheme-системы могут быть безопаснее «обычных».

• Сделал блог-фреймворк на XSLT: демо, код.
• Зачем? Для себя. После пары «вайб-промптов» понял, что 20-летний стандарт покрывает всё, что надо.
• Хочу: писать чистый HTML, без WYSIWYG и Markdown; RSS «из коробки»; единый шаблон на все посты; немного JS для картинок и тем.
• XSLT = один файл-шаблон, XML-контент. Браузер сам превращает XML в HTML. RSS тоже XML, поэтому тот же индекс используется и для ленты.
• Публикация: создал пост, добавил в index.xml, залил — всё. Без сборок и бэкенда.

• Участники вспомнили XSLT как способ превращать XML в HTML прямо в браузере, но большинство считают технологию устаревшей и медленной.
• Предложено заменить RSS на Atom из-за более чистого формата дат и лучшей поддержки.
• Некоторые используют XSLT на сервере (PHP, SaxonJS), где он работает быстро и безопасно.
• Браузеры удаляют XSLT из-за рисков безопасности и низкого спроса; IBM предложила свой JIT-движок, но его вряд ли примут.
• SEO и кэширование вызывают сомнения: динамически собранные страницы могут быть плохо проиндексированы.

TL;DR
Claude Code (CC) радует, потому что максимально прост: один цикл, один контекст, минимум абстракций. Повторить магию можно, если:

1. Один цикл – без мульти-агентов, максимум один «дочерний» процесс.
2. Маленькая модель – для всего, кроме основной задачи.
3. claude.md – живой файл, где агент и пользователь договариваются о стиле и контексте.
4. Теги и примеры – XML, Markdown, куча примеров в промптах.
5. Инструменты
   • Поиск через сам LLM, а не RAG.
   • Высокоуровневые «умные» инструменты (edit, read, todo) вместо низкоуровневых команд.
   • Агент сам ведёт todo-список и отмечает выполненное.
6. Управление стилем – явные просьбы «ЭТО ВАЖНО» и алгоритмы с эвристиками прямо в промпте.

---

1. Цикл

• Одна история сообщений – легко дебажить.
• Подпроцессы – CC может вызвать себя же, но глубина = 1.
• Маленькая модель – подсчёт токенов, сводка diff, украшения UI – всё ей.

---

2. Промпты

• claude.md лежит в корне репо; агент читает и пишет туда же, чтобы «запоминать» договорённости.
• XML-теги (<thinking>, <result>) + Markdown + примеры кода – структурируют вывод и уменьшают бред.

---

3. Инструменты

• LLM-поиск – просим модель выдать до 20 релевантных файлов; быстрее и точнее эмбеддингов.
• Высокий уровень
  • str_replace_editor – редактирует блоки кода, а не строки.
  • todo – агент сам пишет / вычёркивает задачи; видно прогресс.
• Никаких низкоуровневых sed, grep и прочего UNIX-морока.

---

4. Управление

• Тон – «вежливый, лаконичный, не болтает лишнего».
• Капс и «ВАЖНО» – прямо в промпте, работает.
• Алгоритм – пишем в промпте: «если X → сделай Y, иначе спроси», + примеры.

---

Заключение

CC выигрывает за счёт самоограничений: один файл кода, один цикл, простые инструменты. Не усложняйте – дайте модели хороший каркас и позвольте «готовить».

• Критика: пост назван «Что делает Claude Code таким хорошим», но не сравнивает его с другими инструментами, а просто пересказывает документацию.
• Пользователи делятся опытом: кто-то на CC уже построил MVP с платящими клиентами, кто-то сталкивается с регрессиями и «ленью» агента.
• Безопасность: многие боятся давать CLI-инструменту полный доступ к системе, ключам и репозиториям.
• Альтернативы: советуют OpenHands CLI, aider и другие open-source решения; обсуждают, как подключить собственные LLM.
• Тезис «Claude хорош, потому что модель умеет разбивать задачи на шаги и работает в unix-окружении» повторяется как ключевой.

Репозиторий Evidlo/xsl-website
Публичный пример генерации сайта средствами XSLT: XML-документ преобразуется в полноценную HTML-страницу без серверной логики.

Ключевые файлы

• index.xml – исходные данные
• index.xsl – таблица стилей
• README.md – краткое руководство

Запуск

1. Откройте index.xml в браузере или
2. Примените XSLT-процессор: xsltproc index.xsl index.xml > index.html

Репозиторий демонстрирует, как обойтись без движков шаблонов, используя лишь стандартные XML-технологии.

• Обсуждение началось с демонстрации, как SGML/XML-entity можно использовать для «без-JS» сборки страниц, но напомнили, что браузеры никогда не реализовали полноценный SGML-парсер.
• Участники сравнили XSLT и CSS: CSS может вставлять контент, но лишь декоративно, тогда как XSLT позволяет полноценные преобразования, однако Google просит удалить XSLT из стандарта и уже прячет его за флагом в Chrome.
• Всплыли воспоминания о 2000-х, когда XML/XSLT активно применялись для документации, e-learning и CMS (Symphony), но сложность и отсутствие поддержки со стороны браузеров постепенно вытеснили технологию.
• Предложили альтернативы: серверная трансформация (PHP, CI/CD) или полный отказ в пользу современных сборщиков и SSR-фреймворков.

Кратко: стандартизировать в браузерах XSLT 3.0 нецелесообразно.
Технология мало используется, реализация сложна, а современные подходы (JS-шаблонизаторы, Web Components, SSR) решают те же задачи быстрее и проще.

• Пользователи мечтают о «навсегда-статическом» сайте без обновлений зависимостей; кто-то до сих пор использует PHP-include, кто-то — <template>+JS.
• Появилась фантазия «а вдруг браузеры вернут XSLT 3.0»; сторонники называют это разделением данных и представления, скептики — «громоздким XML-гипертекстом».
• Поддержка XSLT в браузерах всё ещё есть, но фактически мертва: Google убирает упоминания из спецификаций, а правительственные сайты жалуются на поломки.
• Основные претензии к XML/XSLT: чрезмерная многословность, сложность ручного редактирования, жёсткая типизация и «всегда есть пять способов записать то же самое».
• JSON и современные SSR-шаблонизаторы оказались проще и быстрее, поэтому даже ностальгирующие разработчики признают: «красивый, но неудобный» стандарт проиграл конкуренцию сетевым эффектам и эргономике.

• Удаление XSLT в браузерах разрушит работу правительственных и регуляторных сайтов по всему миру.
• Сотни порталов (Финляндия, Германия, США, Канада, Австралия и др.) используют XSLT для отображения XML-документов (законы, отчёты, статистика).
• Без XSLT эти ресурты станут недоступны для граждан, нарушатся юридические обязательства и процессы e-government.
• Предлагается сохранить поддержку XSLT как критическую инфраструктуру или предоставить механизм миграции.

• Участники спорят о предложении WHATWG исключить XSLT из HTML-спецификации: одни считают технологию мёртвой и опасной, другие — полезной для «без-JS» задач и госсайтов.
• Поднимаются вопросы безопасности (libxslt на C), обратной совместимости и «доктрины never break the web».
• Некоторые предлагают вынести XSLT в расширение или полифил, а также сравнивают судьбу XSLT с Flash, ActiveX и другими удалёнными технологиями.
• Отмечается, что процесс удаления может занять годы, а пока лишь начато обсуждение, а не принято решение.

POML — язык разметки Prompt Orchestration Markup от Microsoft.
Проект в открытом доступе на GitHub: microsoft/poml.

• Назначение: структурировать, версионировать и переиспользовать промпты для LLM.
• Формат: YAML-подобный, читаемый человеком и парсером.
• Возможности:
  – параметризованные шаблоны,
  – условные ветвления,
  – импорт фрагментов,
  – метаданные (автор, версия, модель).
• CLI: poml build → компиляция в чистый текст, poml test → прогон с примерами.
• CI/CD: экшены GitHub для валидации и деплоя промптов.
• Интеграции: Python SDK, VS Code-расширение, экспорт в OpenAI, Azure, Bedrock.

• POML — это XML-подобный DSL от Microsoft Research для «view-слоя» промптов, но выглядит как «JSX, только хуже» и заставляет писать код в строках.
• Участники сравнивают его с YAML-промптами GitHub, BAML (TypeScript-подобные схемы), Jinja и обычным XML, споря о необходимости новой библиотеки.
• Критика: один контрибьютор при $3T-спонсоре, нет SDK для .NET/C#, лишний tooling, «IP squatting», циклы в XML выглядят как костыль.
• Ирония: из-за потребности в точности неформальные LLM-промпты всё структурнее, как юридические документы.